Problem upgrading to OJS 3.4.0.3

Yesterday I attempted to upgrade my institution’s OJS installation to version 3.4.0.3 (from 3.3-something), and the upgrade failed. I tried to get help from our ITS Systems Administrator, and with help from the PKP forum he was able to figure out fixes to some of the error messages we were getting, but we are getting stuck at one error message in particular. Here are the steps that he is taking:

• Signed into https://www.wittprojects.net:2083/cpanel
• Selected Backup
• Under Download a MySQL Database Backup, selecte wittproj_ojs873
• Saved the download as wittproj_ojs873-20231109-1130.sql.gz
• Clicked CPanel to go back to the CPanel main screen
• Selected File Manager
• Navigated to public_html / ojs
• Highlighted config.inc.php
• Selected Edit
• Updated the following entry

• Clicked Save Changes
• Clicked Close
• Selected MySQL(R) Databases
• Under Current Databases found wittproj_ojs873
• clicked the Delete button to its right
• Clicked Delete Database
• Clicked Go Backup
• Under Create New Database, entered in wittproj_ ojs873
• Clicked Create Database
• Clicked Go back when it was finished
• Under Add User to Database, set User to wittproj_ojs873
• Set Database to wittproj_ojs873
• Clicked Add
• Checked All Privileges
• Clicked Make changes
• Clicked CPanel to go back to the cpanel main page
• Selected Backup
• under Restore a MySQL Database Backup clicked Choose file
• uploaded the wittproj_ojs873-20231109-1130.sql.gz
• Clicked Upload
• Clicked CPanel to go back to the cpanel main page
• Selected PhpMyAdmin to bring up the phpmyadmin page
• Navigated to wittproj_ojs873 / email_template_settings / columns
• Clicked Change next to locale
• Checked the box to allow Null
• Clicked Save
• Navigated to wittproj_ojs873 / user_settings
• Located the ROW that was user_id 1, en, familyName, blank
• Clicked the delete button to remove that line
• Navigated to wittproj_ojs873 / journal_settings
• Located submissionChecklist
• Clicked Edit and set it from

to

• Repeated for the other two submissionChecklist
• Opened the web page https://wittprojects.net/ojs/index.php/index/install/installUpgrade
• clicked Upgrade Open Journal Systems
It goes to a blank screen, and when we reload it and click the upgrade button again it gives us the error:

Additionally, I just saw that a new error message is showing up today:

Errors occurred during installation:
• A database error has occurred: There are unprocessed log files from more than 1 day ago in the directory /home/wittproj/ojsdata/usageStats/usageEventLogs/. This happens when the scheduled task to process usage stats logs is not being run daily. All logs in this directory older than 20231109 must be processed or removed before the upgrade can continue.

Thank you in advance for any help you can provide!

1 Like

Hi @maxfieldk29,
the last error message, that there are unprocessed log files, means:
In 3.4 there is a huge overhaul of the usage statistics. Among other things, the usage statistics log file format changed. Thus, before upgrading to 3.4 all old usage stats log files must be processed before the upgrade. Depending on the settings and journal website usage, the log file processing happens automatically, mostly every day.
Thus, before doing an upgrade I would suggest to do this:

  • Check if there is any old (older than the current day or the day before the current day) log file in the following folders usageEventLogs/, reject/, stage/, processing/ in the folder /home/wittproj/ojsdata/usageStats/.
    If there are some files there:
  • Check when the scheduled task – the task that automatically processes the log files – was last run: see the last_run column in the DB table scheduled_tasks where class_name = plugins.generic.usageStats.UsageStatsLoader.
    Delete that DB table raw, and then visit the journal home page. Visiting the journal home page should run that task again.
  • Check if there are still some older log files in those folders mentioned above.
  • If everything OK, start the upgrade. If there are still some older log files there – older than the current day – maybe report that here again.

But, I am not sure that this is the real problem of your upgrade – I think it just happened during you have tried to fix the upgrade… but… lets see/investigate further…

Actually, I do not know why you/your colleague would need to edit something in the DB – somehow I would say this should not happen…

Could you please tell us what exact OJS version you are using, 3.3.0.?
And could you try a new clean start:
Restore all the backups – DB and files, so that your 3.3.0.? is working correctly. Then double check the log files, as said above. Then start the upgrade. Watch for errors, e.g. in the php error log file. Report here what is happening.

Best,
Bozana

Based on the information in the versions table, for core it is 3.3.9.9 which also says it was installed 2023-11-09 1100. Which was the first attempt at the upgrade from 3.3.0.5.

We restored the SQL table from a back up prior to the upgrade.

We checked the folders in usageStats. reject/, stage/, processing/ were all empty. usageEventLogs had two files from the 8th, and two files from the 9th, which we removed from that folder.

We then went to the scheduled_tasks table, and found the plugins.generic.usageStats.UsageStatsLoader values was 2023-11-08 23:16:45 .
I’m not sure what you mean by delete that DB table RAW.

But when we go to the Journal page it takes us to the OJS Install page, and not the journal.

In the error.log for the system we have the following errors

[17-Nov-2023 02:15:21 America/New_York] Server host “www.wittprojects.net” not allowed!
[17-Nov-2023 02:15:21 America/New_York] ojs2: 400 Bad Request

Also not sure why the times are off by 9 hours in the error log file.

Attempt 1: at upgrade provided us the following error
"Errors occurred during installation:

A database error has occurred: A row with “user_id”=“1” and “setting_name”=“familyName” found in table “user_settings” which will conflict with other rows specific to the locale key “en” after the migration. Please review this row before upgrading."

we deleted that offending row form the DB and restarted the upgrade process again.

This time we received the following error:
"Errors occurred during installation:

A database error has occurred: SQLSTATE[23000]: Integrity constraint violation: 1048 Column ‘locale’ cannot be null (SQL: insert into email_templates_settings (email_id, locale, setting_name, setting_value) values (2, ?, name, COPYEDIT REQUEST), (3, ?, name, LAYOUT REQUEST), (4, ?, name, LAYOUT COMPLETE), (11, ?, name, EDITOR ASSIGN SUBMISSION), (14, ?, name, EDITOR ASSIGN REVIEW), (17, ?, name, EDITOR ASSIGN PRODUCTION))"

we went and changed that column in the email_settings table to allow it to be null, and clicked the upgrade button again.

now we have a different error
"Errors occurred during installation:

A database error has occurred: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘at.assoc_type’ in ‘where clause’ (SQL: select distinct at.type_id from announcement_types as at left join journals as c on at.assoc_id = c.journal_id where c.journal_id is null or at.assoc_type <> 256)"

Not sure how to correct that one so we stopped at this point.

Note the folders in usageStats are still empty as well.

Hi @maxfieldk29,

I’d recommend stepping back and walking through your upgrade process a bit at a time – it’s a bit hard to follow what’s already happened here. I’m happy to communicate with your tech resources if they’re willing to join us here.

First, let’s establish the baseline. Are you attempting to upgrade a test copy of the system, or are you working with your production installation?

If you’re working with production, let’s get it back a working 3.3.0-x status first. To do that:

  • Restore your installation codebase (where the .php scripts live) to 3.3.0-x code;
  • Restore your database to a backup taken before you attempted to upgrade to 3.4.0-x;
  • Restore the contents of your files_dir (see config.inc.php) to a backup taken before the attempted upgrade to 3.4.0-x.

Once those are done, you should be back in business with a 3.3.0-x installation, and everything should work as it did before you attempted the upgrade.

With that done, what version does OJS report in Administration > System Information?

Once that’s established we can look at trying the upgrade again. Note that we’ve just released a new build of OJS 3.4.0-x, which includes some upgrade fixes, so I’d recommend looking at that as a next step. And I’d also recommend using a test environment to upgrade, rather than your production environment! It’ll make this a lot lower risk.

Thanks,
Alec Smecher
Public Knowledge Project Team

I have this error, I use OJS version 3.3.0-16, php7.4, mariadb, please help:

PHP Fatal error: Uncaught Error: Call to a member function getId() on null in /var/www/html/erevista/plugins/generic/webFeed/WebFeedBlockPlugin.inc.php:85
Stack trace:
#0 /var/www/html/erevista/lib/pkp/classes/template/PKPTemplateManager.inc.php(1319): WebFeedBlockPlugin->getContents()
#1 /var/www/html/erevista/lib/pkp/classes/plugins/HookRegistry.inc.php(107): PKPTemplateManager->displaySidebar()
#2 /var/www/html/erevista/lib/pkp/classes/template/PKPTemplateManager.inc.php(1540): HookRegistry::call()
#3 /var/www/html/erevista/cache/t_compile/65bfc3e024c2e9104f46e23b73376a9455e3df0e^4dffb64063bb972c37e05619a2ccd9d0ea7473ac_0.app.frontendcomponentsfooter.tpl.php(29): PKPTemplateManager->smartyCallHook()
#4 /var/www/html/erevista/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_656f516c238477_45291596()
#5 /var/www/html/erevista/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()
#6 /var/www/h in /var/www/html/erevista/plugins/generic/webFeed/WebFeedBlockPlugin.inc.php on line 85

After our OJS said it successfully upgraded to 3.4.03 one of the journals on the site no longer works, instead reporting an error 500 when you try to access the journal.

The apache logs from the server hosting site, do not provide any indications as to what the issue might be. But the /ojs/error.log file repeats the following two error messages when someone tries to access the particular journal:

Exception: Plugin pln expected to inherit from PLNPlugin, actual type NULL in /home/wittproj/public_html/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203
and
Exception: Plugin authorRequirements expected to inherit from AuthorRequirementsPlugin, actual type NULL in /home/wittproj/public_html/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203

This error does not appear when accessing the other journals, which all work, it is just this particular one that is not at the moment.

Any ideas of how to fix these exceptions, and maybe the overall error 500 with this specific journal?

Thanks for your time and help with this!

Hi @maxfieldk29,

Those messages (“Plugin … expected to inherit…”) shouldn’t cause OJS from continuing to work. I’d suggest re-checking the error log to see if there’s something that appears at the moment when you get a 500 error on that journal; I suspect there’s another message that explains it.

Regards,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 13 days. New replies are no longer allowed.