Unable to restore ojs2.4 from backup

Hi @Sergeiy_Sandler,

I suspect that you ran the upgrade with a version of PHP that’s to old for OJS 3.x. Double-check your version against the requirements.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, @asmecher,

This is unlikely. The hosting service has a recent version of php installed (7.2, I think), and requirements compatibility (including for php version) was one of the first things we checked with the hosting’s support staff (all the necessary requirements were met). I’ll communicate this to them nevertheless. But I’d be surprised if php version is the issue.

Thanks!
Sergeiy.

Hi @Sergeiy_Sandler,

Have them double-check that the command line PHP they are using is the same as the web based one. One common gotcha is to configure the web-based PHP version e.g. through CPanel – which doesn’t necessarily affect the command line based one.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, @asmecher,

So, first of all, let me relate what happened before I saw your most recent message, but after the hosting support staff proposed I check php versions for the two different domains on cPanel. It might be instructive:

  1. Initial conditions: php for the main site (the Society) domain was 7.2, but for the journal’s add-on domain it was 5.5.
  2. I changed both to 7.3 via cPanel
  3. The ojs2.4.7-0 site stopped working (back to the issue we had originally with the backup restoration)
  4. Nevertheless, I tried running an upgrade (using web interface, not command line), with exactly the same result as before: a blank page.
  5. I restored the old site from backup, but again it didn’t work.
  6. I had to downgrade php for the journal’s domain to (the deprecated) 5.6, and only then did the 2.4.7-0 site come back up. (My suspicion is that it was similarly downgraded in the first place a couple of days ago by the hosting’s support staff to solve the same issue).

I now forwarded your most recent message to the hosting support.

But basically, something remains unclear to me in all of this. Must the correct order of operations for the upgrade include a php version change, and then a change back to restore backup if it failed? That sounds strange. And then, why does the upgrade still fail, despite the updated php version?

Thanks,
Sergeiy.

Hi @Sergeiy_Sandler,

OJS 2.4.7-0 is not compatible with PHP 7.3. sometimes new versions of PHP introduce changes that break OJS and we have to release a new version that works around them.

OJS 3.2.x, conversely, needs something newer than PHP 5.6, which is quite out of date. This includes the upgrade script.

I would recommend trying the upgrade from the command line, if you can. This gives more information about where an upgrade failed. If a web-based upgrade failed, you can sometimes get information from the PHP error log. One common web-based upgrade failure is a timeout, if your server is configured with an execution time limit. The upgrade script can sometimes take a while. This generally isn’t a problem with the command line process, as there is rarely a time limit configured there.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, @asmecher,

So, here’s a full report on another failed attempt to upgrade (with errors and stuff). Let’s see if it teaches us something.

I was with one of my hosting’s support staff on livechat just now. I don’t have command line access (and the attempt to give it to me temporarily didn’t really work out), so he was doing the upgrade attempts, but I did get copies of outputs and logs.

Attempt #1: The support person tried to do the upgrade using github. That produced the following fatal error:

fatal: not a git repository (or any parent up to mount point /)

The second attempt followed the lines of previous attempts. I placed the file from the downloaded upgrade file in the right directory, and the upgrade command was executed from the command line. This time (following a suggestion from another support staff member in the hosting’s team), it was ran from the following path:

/opt/cpanel/ea-php72/root/usr/bin/php

The command ran successfully, without any errors in the command output. However, the following errors appeared in the error log:

======

[06-Jan-2020 07:46:16 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADODB_Cache_File has a deprecated constructor in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/adodb.inc.php on line 263
[06-Jan-2020 07:46:16 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADOConnection has a deprecated constructor in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/adodb.inc.php on line 359
[06-Jan-2020 07:46:16 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADORecordSet has a deprecated constructor in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/adodb.inc.php on line 2921
[06-Jan-2020 07:46:16 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADORecordSet_array has a deprecated constructor in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/adodb.inc.php on line 3939
[06-Jan-2020 07:46:16 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php:456
Stack trace:
#0 /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/adodb.inc.php(558): ADODB_mysql->_connect(‘localhost’, ‘’, ‘’, ‘’)
#1 /home/ludsocie/public_html/journal/lib/pkp/classes/db/DBConnection.inc.php(162): ADOConnection->Connect(‘localhost’, ‘’, ‘’, ‘’, false)
#2 /home/ludsocie/public_html/journal/lib/pkp/classes/db/DBConnection.inc.php(137): DBConnection->connect()
#3 /home/ludsocie/public_html/journal/lib/pkp/classes/db/DBConnection.inc.php(94): DBConnection->initConn()
#4 /home/ludsocie/public_html/journal/lib/pkp/classes/db/DBConnection.inc.php(53): DBConnection->initDefaultDBConnection()
#5 /home/ludsocie/public_html/journal/lib/pkp/classes/db/DBConnection.inc.php(238): DBConnection->__construct()
#6 /home/ludsocie/public_html/journal/lib/pkp/cla in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php on line 456

======

The site went as blank as usual (blank page; blank source code for that page).
After that, I restored the old site from backup. The support person at the hosting suggested perhaps some sever requirements need to be adjusted (nothing specific mentioned; just the general idea). So, maybe that also gives a lead.

So, that’s where we stand now. Any ideas what the matter might be?

Thanks!
Sergeiy.

PS: Regarding the PHP version compatibility of different OJS versions, perhaps it could be useful to include a word about that in your upgrade instructions page (especially for the chance that a user needs to downgrade back their php version to get a backup copy running again)?

If you want to upgrade your OJS 2.4.8 ti 3.1.2, you should:

  1. Upgrade your PHP to 5.6 and check your current OJS
  2. Upgrade your OJS to 2.4.8-5 ftom tar.gz (download section) and check your OJS
  3. Upgrade your OJS to 2.4.8 current ftom github and check your OJS
  4. Upgrade your PHP to 7.2+ and check your current OJS (still 2.4.8!)
  5. Upgrade your OJS to 3.2.1 from github or download section and check your OJS

I made this few days ago:

https://journals.urfu.ru - 2.4.8-5 from site + php 5.4
http://journals.ideafix.co - 2.4.8-5 from github + php 5.6 and upgrade to php 7.3
http://ojs3.ideafix.co - 3.2.1-4 from site + php 7.4

My editors are in panic. We will stay in 2.4.8 current from github and modern LAMP environment.

Hi @Sergeiy_Sandler,

On attempt #1:

 fatal: not a git repository (or any parent up to mount point /)

This just means you’re not working with a git checkout. Unless you want to introduce git, you’ll need to work with another set of instructions (e.g. “Full Package”, documented in docs/UPGRADE.md).

On attempt #2:

Can you give more information on what steps you followed? “I placed the file from the downloaded upgrade file in the right directory” might not be the right approach. (Refer to the “Full Package” instructions mentioned above.)

Also, what is the complete command line you ran to upgrade OJS, and what was the complete output? In the post above, /opt/cpanel/ea-php72/root/usr/bin/php is the PHP binary (I suspect you need to use this to work around the old PHP problem mentioned above – but you can’t just run this by itself, and the OJS upgrade script should definitely generate some helpful output that I don’t see mentioned here.

PS: Regarding the PHP version compatibility of different OJS versions, perhaps it could be useful to include a word about that in your upgrade instructions page (especially for the chance that a user needs to downgrade back their php version to get a backup copy running again)?

Unfortunately this issue is a reflection of the way OJS and PHP releases follow each other. At the time OJS 2.4.7-0 was released, it was compatible with the newest releases of PHP, and the system requirements in the README document reflect that. We didn’t know at the time that PHP7.3 would be incompatible because it hadn’t been released.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher,
On both the github attempt and the details of the command line commands, I can’t say more than I did already, cause I don’t have command line access. The hosting staff person did all of that, and I only got the output he sent me.

On the file system process, here’s what I did: I downloaded the archive from the PKP site, uploaded it to the server, unpacked into a folder, and then created a copy of that folder, where I replaced the /public subfolder and config.inc.php with those in the current (2.4) journal folder. I also copied in the files subfolder (/ojsvault). Finally, I moved the old journal folder to another location as backup, and replaced it with the folder I prepared as described above. That’s how I understood the instructions on the upgrade page :smiley:

Thanks,
Sergeiy.

@IdeaFix: And is it crucial to do stage 3 via github? (I’d need to bother the hosting support for that again :smiley:)

@asmecher: Any comments on these suggestions, or on the error messages I sent earlier today?

Thanks!
Sergeiy.

Hi @Sergeiy_Sandler,

There’s no need to use github, it’s just an option for those who prefer to manage their code that way. I suspect it’ll be a lot less complicated in your case if you avoid it, at least for now. It’s generally useful for users who manage a lot of OJS installs, or customize them heavily.

The operative error message above is this one:

PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /home/ludsocie/public_html/journal/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php:456

PHP 7.x removed the mysql driver and provides a driver called mysqli instead. You’ll need to edit your config.inc.php before running the upgrade script and change

driver = mysql

…to…

driver=mysqli

This is another PHP change that was introduced with PHP7.x.

Note that your post accidentally included your database credentials – I’ve taken them out of the post, but I’d suggest changing them ASAP.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, @asmecher,

Should I try to run the upgrade again with just this fix to the config file?

And as for the credentials, you mean the password? Will change it in a few minutes, and will take greater care in the future!

Thanks!
Sergeiy.

Hi @Sergeiy_Sandler,

Generally we recommend referring database/files directory before re-running an upgrade, but I’m this case I think the error occurred before any upgrade steps completed, so you should be good to run again after making the change.

Yes, I’d recommend changing your database password.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi, @asmecher,

So, I made that change in the config file, and asked the hosting support to run the upgrade command again. Again, it executed without error, but also without any output at all. And in the end of the process, the page is no longer quite blank (progress! :wink: ) But now it only displays the following text:

DB Error: Unknown column ‘context_id’ in ‘on clause’

I’m about to restore the backup again. Any suggestions on what to do next?

Thanks!
Sergeiy.

Hi @Sergeiy_Sandler,

I see a similar post over here: DB Error: Unknown column 'context_id' in 'on clause'

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks!
I’ll wait until I’m fresher in the morning, give myself a tutorial on permissions (:slight_smile:) and try again. I’ll keep you posted on the results.

Hi, @asmecher,

So, first of all, let me report the good news: after permissions were set to 777, the upgrade actually worked!!! There are still some minor issues (details of journal layout and the like that were not preserved properly), but these can be fixed manually.

My one serious remaining question is what to do with permissions now. We kept them at 777 for the time being, because I’d really want to have your input (or a link to another place where it’s explained) before these are reset to normal (755), possibly resulting in the site going down again.

Finally, just in case, here’s the command output for the upgrade command:

==============

#4462: Context navigation menu entries can be blank
#4478: Site-level browse block prevents display of other blocks
#4482: Web feed plugin includes untranslated copyrightStatement locale key
#4487: Rewrite phpMyVisites plugin for OJS/OMP 3.x
#4489: Paypal plugin missing link to settings modal
#4491: Navigation Menus - Custom Templates not available
#4495: Navigation menu - title missing when editing item
#4497: Distribution Settings do not save
#4503: [OJS] Update nl_NL locale
#4514: [OJS] Recoginze https URL to Creative Commons licenses
#4522: Correct missing escaping of template variable
#4542: Public URL Identifier breaks with a slash character
#4547: “Create Reviewer” reviewer selection option breaks email template
#4561: Fix Google Scholar plugin enabling on upgrade
#4562: Hide edit/delete/upload link actions for galleys from authors

Successfully upgraded to version 3.1.2.4

===============

Thanks!
Sergeiy.

1 Like

Minimally, you want your webserver to be able to write to the files in your data directory (files_dir) and your “public” and “cache” directories, and you want to deny the ability to write to everything else. If you want to be able to add, remove, and update plugins over the web, you will also need your “plugins” directory to be writable.

See:

You will get different errors in each step and it is easy to fix each part of errors on each step.

Also, upgrade to 3.1.2 oficially (am i right?) supported only from the last 2.4.8 version.

And 777 is not a very good way. Not all files should be executable, for example. It is very strange, that webserver (cpanel application) does not have permissions to the wwwroot, or console php in web hosting have different permissions than cpanel.

And one more question. There is your “files” dir stored? Is it in wwwroot?

The upgrade to 3.1.2 is supported from any 2.4.x installation. Versions earlier than 2.4.0 are unsupported.