Fatal error upgrade 2.4.8.0->3.2.0.3

Software Support
1

During upgrade we get the below listed fatal error:

[code: Installer Installer::convertEditorDecisionNotes]
PHP Fatal error: Uncaught Exception: DB Error: Data too long for column ‘contents’ at row 1 Query: INSERT INTO notes
(user_id, date_created, date_modified, title, contents, assoc_type, assoc_id)
VALUES(?, ‘2018-12-07 09:16:12’, ‘2020-05-07 09:23:22’, ?, ?, ?, ?)
in /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/db/DAO.inc.php:703
Stack trace:
#0 /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/db/DAO.inc.php(231): DAO->handleError(Object(ADODB_mysqli), ‘INSERT INTO not…’)
#1 /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/note/NoteDAO.inc.php(204): DAO->update(‘INSERT INTO not…’, Array)
#2 /var/www/editora.sepq/ojs-3.2.0-3/classes/install/Upgrade.inc.php(1700): NoteDAO->insertObject(Object(Note))
#3 /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/install/Installer.inc.php(417): Upgrade->convertEditorDecisionNotes(Object(Upgrade), Array)
#4 /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/install/Installer.inc.php(263): Installer->executeAction(Array)
#5 /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/class in /var/www/editora.sepq/ojs-3.2.0-3/lib/pkp/classes/db/DAO.inc.php on line 703

Without success we tried truncate the field length in classes/install/Upgrade.inc.php line 1695 with mb_substr():
$note->setContents(mb_substr(nl2br($row[‘comments’]), 0, 65500, ‘utf-8’));

Can you help with a workaround or indicate which register to edit in the original database?
Thank you.

2

Hi @lobo,

I wonder if MySQL/MariaDB think your content is a different length than PHP does, due to different character set configurations. What is the default character set for your database? (See MySQL :: MySQL 8.0 Reference Manual :: 10.3.3 Database Character Set and Collation for details.)

Regards,
Alec Smecher
Public Knowledge Project Team

3

In the old and new database the default database set is utf8_general_ci.
The funny thing is that no one of my tries to truncate the content length worked:

Changing line 1695 from: $note->setContents((nl2br($row[‘contents’]); to

  1. $note->setContents(mb_substr(nl2br($row[‘comments’]), 0, 65500, ‘utf-8’));
  2. $note->setContents((nl2br(strlen($row[‘comments’], 0 , 65500));
    crashed the script.

After turning sql debug on, the comment is really very long, but what made me wonder is that the \n
also have not been converted to br. There must be an unrevealed step before which I could’t realize.

I found a workaround solution that a least didn’t crash the script:
$note->setContents(‘No text available’);

In the database I can see now this text (‘No text available’) in table notes as comments for editors decisions, but is there a reason why my tries to truncate the comments didn’t work?

4

Hi @lobo,

Should strlen in your second attempt be substr?

Regards,
Alec Smecher
Public Knowledge Project Team

5

Of course. nl2br(substr(row['comments'],0,65500))
I reprocessed the upgrade sucessfully.
But now loking at the database I find this:

MariaDB [ojs]> select * from notes where note_id = 1;

| note_id | assoc_type | assoc_id | user_id | date_created | date_modified | title | contents |
| 1 | 1048586 | 1 | 83 | 2016-11-25 16:44:27 | 2020-05-13 19:06:13 | Editor Decision | r |
±--------±-----------±---------±--------±--------------------±--------------------±----------------±---------+
1 row in set (0.001 sec)

In the original text the comments starts with r.
The rest was cut off.
Shouldn’t it has been replaced by <p> or <br> with function nl2br?

Looking deeper in the same table for title “Comments for the Editor”:
MariaDB [ojs]> select * from notes where note_id = 766;

| note_id | assoc_type | assoc_id | user_id | date_created | date_modified | title | contents |
| 766 | 1048586 | 706 | 10191 | 2020-05-03 13:44:25 | 2020-05-13 19:09:22 | Comments for the Editor |

Caro Editor

remeto …

|
1 row in set (0.001 sec)

The comments here are OK.

6

Hi @lobo,

I wonder whether the comments being passed through PKPString::stripUnsafeHtml caused the truncation. Did this comment originally include HTML (or plaintext that could be interpreted as unsafe HTML)?

Regards,
Alec Smecher
Public Knowledge Project Team

7

In whitch table in the old database I can find the text of Editor Decision?