Upgrade OJS 2.4.2.0 to 3.2.0.3 - several errors and problems

Jorge · June 3, 2020, 4:02pm

Hello,

I’m working on a “sandbox” upgrade of a 2.4.2 install to the latest version. I’m running into a lot of problems which I’m trying to solve sequentially. Of course, every time it breaks I need to rebuild the files directory and the database and start from scratch.

First off, to avoid what looked like a potential encoding problem, I run the database through a script that converts everything to UTF-8 and marks the collation of the tables as utf8_general_ci. I can see via phpMyAdmin that the text is correctly encoded, so I think that part is ok.
Then I need to create the tables “usage_stats_temporary_records” and “submissions” because they don’t exist in the 2.4.2 database. I’m taking them from a clean 3.2 install. If these tables don’t exist, the upgrade breaks.
Then I need to empty the citations table as per this: Upgrade error: Duplicate entry 'xxx-yyy' for key 'citations_publication_seq' · Issue #5626 · pkp/pkp-lib · GitHub. If I don’t, I get this error: “Upgrade failed: DB: Duplicate entry ‘0-45’ for key ‘citations_publication_seq’”. I suppose if I ever get the upgrade to finish I can get the citations rebuilt.
I’ve also needed to copy usageStats plugin to lib/pkp/plugins/generic/ because the upgrade breaks looking for GeoLocationTool.inc.php here.

After this many fixes, I wonder if I’m on the right path or not, with the database problems being the most concerning. This is a very delicate project and I really need to get this right.

I hope somebody can tell me if I’m doing right by following these steps, or if I’m setting myself up for trouble down the line.

I’m getting some PHP errors and warnings, like “unserialize()” errors.

My last attempt after all I’ve explained above has crashed with this:
PHP Fatal error: Uncaught Error: Call to a member function getContextId() on null in /home/USERNAME/public_html/v3clean/lib/pkp/classes/submission/reviewAssignment/ReviewAssignment.inc.php:542

I’ll be thankful for any help!

Jorge · June 3, 2020, 5:38pm

I made a bit of progress I think: I updated to 2.4.8.5 following the instructions here:

github.com

pkp/ojs/blob/ojs-stable-2_4_8/docs/UPGRADE

Upgrading an OJS Installation
-----------------------------

Note: backing up your current data files and database is strongly recommended
prior to upgrading OJS.

If you are using PHP Safe Mode, please ensure that the max_execution_time
directive in your php.ini configuration file is set to a high limit. If this
or any other time limit (e.g. Apache's "Timeout" directive) is reached and
the upgrade process is interrupted, manual intervention will be required.


======================
Upgrading from OJS 2.x
======================

Upgrading to the latest version of OJS involves two steps:

    - Obtaining the latest OJS code
    - Upgrading the OJS database

This file has been truncated. show original

This included finding a copy of the Maxmind database. I think this will fix part of the problems with the upgrade. I’ll try again now starting on 2.4.8.5.

I still don’t know if I should convert the database encoding or not.

asmecher · June 3, 2020, 10:39pm

Hi @Jorge,

Generally I think you’re on the right track. However, can you describe…

What are the database errors you make if you don’t copy the schema for usage_stats_temporary_records and submissions? It shouldn’t be necessary to copy these.
What message do you get with the usageStats plugin?

For both of these, please turn on the stack trace option in config.inc.php and include the complete output of the upgrade script.

Thanks,
Alec Smecher
Public Knowledge Project Team

Jorge · June 4, 2020, 12:25pm

Hi @asmecher,

Thanks for the prompt reply! The upgrade from 2.4.8.5 to 3.2.0.3 seems to be going a lot smoother. All of this is on a “sandbox” upgrade by the way.

I redid the upgrade from 2.4.2.0 to 2.4.8.5 to make sure I didn’t miss anything, it went well. Then I went very carefully with a diff over the v3 config file to make sure I wasn’t missing anything.

And I got “Successfully upgraded to version 3.2.0.3” message!!!

Now I need to check the upgrade. I got an error_log full of stuff.

Best regards,
Jorge

Jorge · June 4, 2020, 12:35pm

Ok, so I’m not sure if I need to do anything about the error_log created by the upgrade. It’s 10MB long

I have:

-5 PHP Warning that don’t seem like show-stoppers.
-About 15 “WARNING: Unable to find a match for”, with 7 affected articles.
-A lot of PHP Deprecated, PHP Notice. I think these are safe to ignore?
-And lastly, about 15-20 “unserialize(): Error at offset 0 of 27 bytes”

What should I do about these? Thanks a lot again!

Best regards,
Jorge

asmecher · June 5, 2020, 12:32am

Hi @Jorge,

You should be able to ignore the deprecation warnings – we’re gradually working to resolve these (and various other warnings) with each successive release.

The unserialize warnings might need attention. Are you seeing any issues with special characters? If so, you may have inadvertently mixed your character set configurations. Make sure your database is configured with a default character set of utf-8, and that encoded characters look OK. (PHP serialized objects include string lengths, and if the string appears to be a different length than the number in the serialization, you’ll see warnings like this. Misconfigured character sets can make the same string appear to be different lengths depending on how it’s read.)

Regards,
Alec Smecher
Public Knowledge Project Team

Jorge · June 5, 2020, 8:56am

Thanks, I might try to convert the database to UTF-8 as I was doing in my first try and upgrade again. I don’t see any problems with characters though, but the database contents are definitely in Latin1.

The WARNING about not finding a match for some documents is strange too, those documents seem to behave correctly. Any ideas what to look for?

asmecher · June 5, 2020, 5:53pm

Hi @Jorge,

Converting from Latin1 to UTF-8 is definitely recommended!

The WARNING: Unable to find a match for… messages are cases where the upgrade process goes through the database table listing article files, and looks for the files it specifies in the files_dir area of your server’s filesystem, but the file doesn’t exist there. I would take note of these, but not worry about them overmuch – if they weren’t a problem in 2.4.2, they won’t be a problem in 3.2.0-3; the worst that’ll happen is you’ll click a link to download a work-in-progress file from the submission workflow and get a “file not found” message. It’s likely that these files didn’t upload in OJS 2.4.x in the first place.

Regards,
Alec Smecher
Public Knowledge Project Team

Jorge · June 6, 2020, 12:01pm

Thanks @asmecher! Well, for some reason the regular upgrade without trying to convert the database works flawlessly, and my conversion attempt generated a lot more unserialize warnings and it does indeed display broken characters here and there.

So I’m going with the original database in Latin1, and hope it doesn’t cause problems in the future. Unless you have a different suggestion.

Best regards,
Jorge

asmecher · June 8, 2020, 7:43pm

Hi @Jorge,

OK, as long as it’s “consistently misconfigured”, you shouldn’t have too much trouble – but note that some things will behave weirdly, such as anything requiring a conversion between upper and lower case involving text containing accented characters. Off the top of my head, searching would be an example.

Regards,
Alec Smecher
Public Knowledge Project Team

Jorge · June 8, 2020, 8:52pm

Thanks @asmecher! Well, the only solution I can think of is to go table by table, look at the data to see its encoding, export it, convert it and reimport it in UTF-8. That could prove time consuming…

Is there any automated approach I could take? Or at least a least of tables that could contain text strings?

Best regards,
Jorge

asmecher · June 8, 2020, 9:16pm

Hi @Jorge,

I think dumping the database using mysqldump, processing the dump file to correct the encoding etc., and then re-loading into the database would do it.

Regards,
Alec Smecher
Public Knowledge Project Team