OJS 3.6 Patch fails with malformed patch at line X

Thank you Alec,

Going to give this a go.

Regards

Julian

Alec,
Some feedback on this issue.
We followed the guidelines in the UPGRADE doc as you suggested for doing a full package upgrade.
Everything fine up until the part where we upgrade the DB.
The doc says to use the CLI like so
php tools/upgrade.php upgrade
Did that and received a bunch of deprecation warnings relating to features removed in PHP 7. The Download page specifies that PHP 7 is a requirement, however the script fails on named constructors and the tools seems to want to use the mysql lilbrary instead of the mysqli or PDO.
I then tried running the script with PHP 5.6 and got
DB Error: Unknown column ‘domain’ in ‘field list’
I then followed the instructions to do the upgrade through the Web client - proceed to the Upgrade page - clicked upgrade - white screen of death.

In desperation tried renaming the mysqli to mysql lib and tried the CLI again - no joy.

We really could use some help here. We have been trying for nearly 18 months to update this site and we seem to be blocked at every turn.

Regards
Julian

Just a follow up on this (we are working the problem)
The white screen was caused by the config mysql driver not being set correctly. Changing to mysqli - that is working.

However, when we run the upgrade now we get

Upgrade unsupported. See docs/UPGRADE-UNSUPPORTED for details.

That seems to suggest we cannot upgrade directly from our version to 3.1 - we fist have to go to 2.4

So that is what we will be doing next.

No need to respond to either of the last two pots - if we get stuck I will post back her.

1 Like

Hi @marcorpsa,

Just to clarify a couple of points – yes, when using PHP7, you’ll need to choose the mysqli driver. (The mysql driver is deprecated and often not available in PHP7.)

The deprecation warnings are to be expected, and we gradually work to fix these. Many/most will be fixed with the release of OJS 3.2. However, these are just cosmetic and won’t stop the system from working.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,
Installed 2.4.8 - tried the update - that failed because default on our system is PHP7
Used the command line to run the upgrade tool using 5.6.4 - that seemed to work nicely until it got to the reviews.xml file then it bombed out.
This was while it was trying to add the following to review_rounds
<field name=“review_round_id” type=“I8”>
<KEY />
<AUTOINCREMENT/>
</field>
Error: Incorrect table definition; there can be only one auto column and it must be defined as a key
I trashed the DB and restored from backup - manually added the auto increment and tried again - this time the review.xml passed.
However, the upgrade bombed again with this

[code: Installer Installer::removeAuthorRevisedFilesFromSignoffs]
[note: docs/release-notes/README-2.3.7]

[code: Installer Installer::installEmailTemplate]
<h1>DB Error: Incorrect string value: ‘\xD8\xB3\xD9\x84\xD8\xA7…’ for column ‘body’ at row 1</h1>

I tried digging around to find out where that string is but it is not clear which table it is in. I dumped the schema for the updated database and searched for all tables with a body field which returned this
comments
email_log
email_templates_data
email_templates_default_data
I checked each of these with a query to try and find the issue - but nothing came up.

Any ideas on where to look?

Trying very hard to not bug you too much but spent almost an hour on this one issue with no resolution so hoping you can point me in the right direction.

Hi @marcorpsa,

The most likely cause for that is a muddle character set configuration (e.g. mixing Latin1 and UTF-8 or something similar). Did you inadvertently change your character set configuration in config.inc.php in the process of trying the upgrade?

Regards,
Alec Smecher
Public Knowledge Project Team

No, what I did was I did a file diff (windiff) on our config and the config that came with the 2.4.8 install. I then changed (in the 2.4.8 version) the values that were set in our config file - so in essence I am using an updated 2.4.8 config - not our original. I thought that would be the best approach to ensure no issues with moving to 2.4.8
I checked the default_charset in both original config files and 2.4.8 - both set to UTF-8 - however in the schema dumps for our 2.3.x db and the 2.4.8 (after running the upgrade) - all are charset=latin1 but after the upgrade there are some tables with a UTF-8 charset - none of them however have a body field.

Hi @marcorpsa,

If your config.inc.php character set configurations are the same, then perhaps the problem is in the database creation itself. Check to see that the database character sets are consistent (e.g. if you’re working with a test database loaded from a dump).

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

Created a new DB with charset UTF-8 same problem - same place.
Is there a way I can at least find out which table / row is causing the issue?

Hi @marcorpsa,

The problem is more likely that your old database has a misconfiguration, e.g. it’s storing UTF-8 content in a Latin1 database, but that your new database has it right. If that guess is correct, you have two options:

  1. Make sure that your new database mimics the same (potentially wrong) configuration as your old one, or
  2. Figure out your old database’s misconfiguration and transcode it.

Either way, I’d recommend inspecting the character set configuration of your old database to see whether it matches the options set up in config.inc.php. (Checking the character set configuration of your old database is more of a MySQL admin question than an OJS question – there should be lots of guidance on Stackoverflow.)

The body field probably refers to email_templates_data and/or email_templates_default_data.

Regards,
Alec Smecher
Public Knowledge Project Team

I am about to give up this.
I recreated the DB by doing a full dump from the source with create database - used that to create on my side.
Tried the install again and I got this
[pre-install]
[load: upgrade.xml]
ERROR: Upgrade failed: ##installer.installFileError##

No matter what I do - I get the same result. I have removed the folder twice and extracted the 2.4.8 code - updated the DB, tried to go in with the web browser That gives me this
Fatal error : Call to a member function getVersionString() on boolean in E:\Projects\SAJG\website\cache\t_compile%%73^736^73609D70%%install.tpl.php on line 55
The I try an upgrade check
I get this
Failed to load version info from http://pkp.sfu.ca/ojs/xml/ojs-version.xml

Running out of options

Hi @marcorpsa,

The installer.installFileError message suggests that a file (e.g. dbscripts/xml/upgrade.xml) is missing or contains a typo that prevents parsing. Double-check that extracting the .tar.gz file was successful, and that there are no accidental changes to the files.

You say you’re trying the install process, but with your old database in place. Are you perhaps using the installation script instead of the upgrade script?

(Rather than jumping between processes and getting frustrated in the bargain, I’d suggest sticking with the command-line upgrade process. It’s the most reliable and provides the most information if something isn’t working properly.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,
Apologies or my last post - it was late and I was getting frustrated.

I have been through the process of unzipping the tar multiple times - same result.

Sometimes a fresh start is needed.

I did a complete new everything. New folder, unzipped archive.
I then imported the DB script exactly as it is from our server - with create database etc.

I started php 5.6.4 local server in the folder in question and used the Web interface to initiate the update process.
It failed on the same \xD8… issue.
I then did a search and replace on the SQL dump of the db changing all the charset’s of the table to UTF8.

Did a complete install again and then ran the updated SQL script.
Repeated the update - this time it completed successfully so we are now at version 2.4

Going to try the 3.1 update.

Hi @marcorpsa,

Not a problem, sometimes the best solution is to put it down for a few hours. I’m glad you’re making progress and good luck with the 3.x update. (OJS 2.3.6 to 2.4.8 is already a big step.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

Still not done 3.1 is crashing now.
One thing I don’t understand. 3.1 requires PHP 7, yet the config.inc.php mysql driver defaults to mysql - which has been completely removed from PHP 7
Not only that - if you run the tools\upgrade.php script with PHP 7 it throws hundreds of warnings - if you try and run the upgrade.php script with PHP 5.6.4 it won’t run saying it needs PHP 7.

Something seems not right here - what am I doing wrong?

Can’t get passed this

[code: Installer Installer::provideSupplementaryFilesForReview]

PHP Fatal error: Uncaught Error: Call to a member function getFileId() on null in lib\pkp\classes\file\SubmissionFileManager.inc.php:184

I have tried three times now.

Any ideas?

This thread references that same error message (Call to a member function getFileId() on null in lib\pkp\classes\file\SubmissionFileManager.inc.php:184), and suggests that there were missing supplementary files as cause:

We had to remove files from the files repository due to a malicious attack - is that the cause? The files are not there but the entry is still in the DB?
If so how do we resolve? Do we need to remove those submissions from within the software first?

If the files were simply removed from the filesystem, then yes, I would suggest logging in with the UI in 2.x and either deleting the supplementary file record or replacing the missing file with a stub file (for example, containing text “This file has been removed”).

Thank you - will give that a go.