Hi,
We have upgraded our installation from version 3.1.1.2 to 3.1.1.4 and post the upgrade we are facing the following issue:
Whenever we try to upload file or update any object content as metadata of record in ojs, this error appear in the error log
[Tue Dec 11 12:56:58.024985 2018] [:error] [pid 4488] [client 10.60.51.7:54188] PHP Notice: unserialize(): Error at offset 368 of 2232 bytes in /var/www/html/lib/pkp/classes/db/DAO.inc.php on line 352
I am not sure what does this error indicate ?? any help please
Thanks for your reply
Yes this file has been changed, here are the changes
;;;;;;;;;;;;;;;;;;;;;;;;;
; Localization Settings ;
;;;;;;;;;;;;;;;;;;;;;;;;;
[i18n]
; Default locale
locale = en_US
; Client output/input character set
client_charset = utf-8
; Database connection character set
; Must be set to "Off" if not supported by the database server
; If enabled, must be the same character set as "client_charset"
; (although the actual name may differ slightly depending on the server)
connection_charset = utf8
; Database storage character set
; Must be set to "Off" if not supported by the database server
database_charset = utf8
; Enable character normalization to utf-8 (recommended)
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to "utf-8" for this to work, as characters are stored in utf-8
charset_normalization = Off
What were the original values of these settings prior to the upgrade? If no new data has been added with the changed settings, you’ll want to revert to these original settings for consistency. If new data has been added, you’re looking at the difficult work of converting the old data to the new settings, or the new data to to old settings.
Well actually the configuration in the previous thread presents the original values of these settings prior to the upgrade. I didn’t change anything, that’s why I assumed that it should work with these settings since it was working fine before the upgrade.
Yes, if the values are unchanged (including no change in whether the configuration variable were commented / uncommented), I would have expected this to continue working as before.
This message presents as an notice (rather than a warning or error or fatal error). Do you see any functional issue associated with the user interface? If you want to continue debugging just based on the notice, your next step is probably to identify what data is causing this unserialize() message. This would involve getting into the PHP code. Do you have access to a development environment? Are you comfortable making PHP changes?
That particular line of code in DAO.inc.php is used to convert PHP objects that were first serialized (converted to string representations) back to objects when they are fetched from the database. Does the error only happen when you upload/edit metadata records? There are other places where objects are stored in the database, and if the notice only appears in certain cases it may not be a character encoding issue but perhaps rather something that didn’t quite go according to plan during the upgrade process. Did you get any errors or warnings when you did the upgrade?
Yes there are some functionalities get affected by this error. Mainly, the Unserialize DAO.inc.php issue appears in the following scenarios:
Trying to add DOI suffix to an item. This error appears in the error logs and the form keeps spinning
Open an existing metadata form and hit save without updating anything.
Adding references metadata to an existing item is not saved. And in the browser console, attached error (error#1) appears in the console.
Adding the “a” html tag with href attributes that contains ‘#’ sign, caused system error. Basically, the system doesn’t allow to add any href tag with ‘#’ sign and the save button keeps spinning as shown in error attched (error#2).
I just did a source comparison between the -2 and -4 branches and I don’t see any changes that would have broken encoding like this. When you did the upgrade, how did you migrate your config file? I think @ctgraham may be right in that it is sounding like a weird i18n issue.
Are any characters displaying incorrectly on the site, like when metadata is simply viewed for a submission?
