AC reported another bug when editing poems in the database. It turned out to be virtually identical to the bug we fixed the other week, which affected authors. I made the same fixes, with minor variations:

Editing and saving an author was throwing the following error:

Could not successfully run query (UPDATE `poems` SET `po_title` = 'Ode to Labour (From Tait\'s Magazine)x' , `po_translator` = '' , `po_date` = '1839-10-12' , `po_organ` = '1' , `po_vol` = '1' , `po_num` = '3' , `po_pages` = '12' , `po_anonymous` = '0' , `po_unsigned` = '0' , `po_pseudonym` = 'An Industrious Englishman' , `po_text` = '' , `po_origLang` = '' , `po_images` = '' , `po_illustrator` = '' , `po_illustrations` = '' , `po_links` = '' , `po_notes` = ''  WHERE `po_id` = 1) from DB: Incorrect number of arguments for PROCEDURE vpn.related_poem_lookup_loop; expected 3, got 2

I looked at the db backup, and found the following:

DROP TRIGGER IF EXISTS `vpn`.`related_poem_update`;
DELIMITER //
CREATE TRIGGER `vpn`.`related_poem_update` AFTER UPDATE ON `vpn`.`poems`
 FOR EACH ROW BEGIN DECLARE related_poem_content text;  CALL related_poem_lookup_loop(new.po_id, related_poem_content, -1);  
END
//
DELIMITER ;
DROP TRIGGER IF EXISTS `vpn`.`poem_delete`;
DELIMITER //
CREATE TRIGGER `vpn`.`poem_delete` BEFORE DELETE ON `vpn`.`poems`
 FOR EACH ROW BEGIN DECLARE related_poem_content text;  CALL related_poem_loop(old.po_id, related_poem_content, old.po_id); DELETE FROM poem_search WHERE id = old.po_id;  
END
//
DELIMITER ;

The first trigger calls related_poem_loop with only two arguments; the second uses three, and the function signature expects three (although I couldn't find the function itself in the db backup file -- that's worth looking into). On the analogy of the other error we fixed, the third argument is presumably "exclude_id", which is passed to the related_poem_loop function, where its function seems to be to allow you to avoid processing a poem which you're actually in the process of deleting. When we're doing an update rather than a delete, presumably this does not apply, so following our logic of last time, we decided to pass -1, which would not match any poem_id. Accordingly, we modified the trigger. We did that at the MySQL command line: ssh hcmc@mysqldev, then mysql -u hcmc -p vpn, which logs you into that db. Finally, this is what we ran:

DROP TRIGGER IF EXISTS `vpn`.`related_poem_update`;
DELIMITER //
CREATE TRIGGER `vpn`.`related_poem_update` AFTER UPDATE ON `vpn`.`poems`
 FOR EACH ROW BEGIN DECLARE related_poem_content text;  CALL related_poem_lookup_loop(new.po_id, related_poem_content, -1);  
END
//
DELIMITER ;

This appears to have solved the immediate problem -- we can now save changes to poem -- but we should watch out for any other issues that might have arisen out of the re-introduction of triggers.