As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved. Please note that this FAQ is OJS-centric, but most issues are applicable to both platforms.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OCS Conference Support and Discussion subforum; if you have a development question, try the OCS Development subforum.

While working on migrating to the newest version of OCS, we ran into several...PHP Notice: unserialize(): Error at offset...errors. Looking through older PKP forums, this problem was described as a problem with php changing the way it performed serialize and unserialize over php releases. I don't believe that is the problem.

The problem, for us, was seen when special characters were input into OCS forms and stored into mysql. On our older system, php, mysql, and the php mysql library all were using UTF-8 encoding. So special characters were stored as (potential) multi byte characters. This can be demonstrated by the following php code:

echo strlen('héllö'); // will return 7 in UTF8 encoding

(side note: php.net says "serialize() output should generally be stored in a BLOB field in a database, rather than a CHAR or TEXT field.")

Now we build a new system for our updated OCS, mysql dump the old database-> reload to new mysql database, keeping the UTF-8 encoding.

When we run the update script,we get several: PHP Notice: unserialize(): Error at offset... for any mysql value that contains special characters because....The newer version of php mysql defaulted to latin1 encoding rather than utf-8, so the special characters were now one byte long, rather than 2 bytes, and the unserialize command complained that the string count was off.

The problem is not with php's implementation of serialize and unserialize. It's when you change encoding schemes in mid stream.

The fix:

If there is a way to force php 5.3.* mysql to default to UTF-8 encoding by some configuration file setting, I could not find it. So in the file: