Archive issues give http 500 error after upgrade to OJS 3.4

(Original post marked for deletion because the title did not reflect the problem and can’t be edited.)

First the problem:

For all but one journal any issue older than 2020/2019 gives an http 500 error even though they are visible on the archive page and can be edited in the dashboard (for instance I can change the cover image and the change is reflected on the archive page). The last journal, which is no longer actively published and only has issues dating back from 2016 is not accessible at all (this journal is also accessible in the dashboard and all back issues can be edited).

I have looked at the database and can’t see any obvious difference between an issue that does work and one that does not.

Here is an example of one that works from 2020: http://r539837.website.c3lqi88hb.service.one/index.php/CM/issue/view/233

And here is one that does not from 2019: http://r539837.website.c3lqi88hb.service.one/index.php/CM/issue/view/219

Details:

The upgrade from 3.3.0.9 to 3.4.0.3 finished without errors after deleting a couple of log files.

After the upgrade the backend seems to work as expected. Yet to find anything that does not work here.

Using latest healthSciences theme (but the problem is the same in standard theme).

Maybe related and maybe not: The Archive page no longer displays the issues in lines of four (or less depending on browser width), rather a bit random. Some times with padding on the left and some times with 0 padding. Not sure if this is connected to the problem or if it is just a theme thing. Looks messy.

I don’t get it.

1 Like

Hi @geirrosset
I hope you are doing fine. After I upgraded to 3.4.0-3, I got the same error as well.
Please see:

I hope OJS team can help us with this issue and I will let you know if I solve and let me know if you will be able to solve it too

Many thanks,
-Salam

Hi @geirrosset,

Are you able to check your PHP error log to find out what the specific error message is? Watch for something to appear at the same time as you see a 500 error delivered to the browser.

Regards,
Alec Smecher
Public Knowledge Project Team

@Salam_Al-Khammasi I saw you got help with your issue. The same did not work for us.So the two errors are probably not related. For us it is only back issues past a certain dat/year, for you, as I understood your post, it was all issues/articles.

@asmecher Turned on display errors and got this:

Fatal error: Uncaught Error: Call to a member function getDisplayName() on null in /lib/pkp/classes/galley/Galley.php:160

Followed by a 28 step stack trace that is mostly the same with or without the modifications to RecommendBySimilarityPlugin that you suggested to Salam above (which resultet in 29 steps). I included the trace with the original unmodified plugin below:

#0 /cache/t_compile/62db40a58450975d215414057ce5369d0501eb8b^9190456890661656c2db668fc3c363ee4354c517_0.app.frontendobjectsgalley_link.tpl.php(71): PKP\galley\Galley->getGalleyLabel()

#1 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_6530dc5b01f504_33444509(Object(Smarty_Internal_Template))

#2 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))

#3 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(384): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))

#4 /cache/t_compile/62db40a58450975d215414057ce5369d0501eb8b^7cf1cd52b8ba8108de77f197078de34b733dd394_0.app.frontendobjectsarticle_summary.tpl.php(128): Smarty_Internal_Template->_subTemplateRender(‘app:frontend/ob…’, NULL, ‘62db40a58450975…’, 0, 3600, Array, 0, true)

#5 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_6530dc5b06a767_04114008(Object(Smarty_Internal_Template))

#6 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))

#7 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))

#8 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render()

#9 /cache/t_compile/62db40a58450975d215414057ce5369d0501eb8b^26de9c47ced54328a8eb56e39bb4d4079aa049c6_0.app.frontendobjectsissue_toc.tpl.php(48): Smarty_Internal_Template->_subTemplateRender(‘app:frontend/ob…’, NULL, ‘62db40a58450975…’, 0, 3600, Array, 0, true)

#10 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_6530dc5b0334c9_48846696(Object(Smarty_Internal_Template))

#11 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))

#12 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))

#13 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render()

#14 /cache/t_compile/62db40a58450975d215414057ce5369d0501eb8b^fcbc2cabc0d4dff6219d7e4b5d36c1363533cfd8_0.app.frontendpagesissue.tpl.php(144): Smarty_Internal_Template->_subTemplateRender(‘app:frontend/ob…’, NULL, ‘62db40a58450975…’, 0, 3600, Array, 0, false)

#15 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_6530dc5aea7183_31223773(Object(Smarty_Internal_Template))

#16 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))

#17 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))

#18 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render(false, 1)

#19 /lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute(Object(Smarty_Internal_Template), NULL, ‘62db40a58450975…’, NULL, 1)

#20 /lib/pkp/classes/template/PKPTemplateManager.php(1325): Smarty_Internal_TemplateBase->display(‘frontend/pages/…’, NULL, ‘62db40a58450975…’, NULL)

#21 /pages/issue/IssueHandler.php(138): PKP\template\PKPTemplateManager->display(‘frontend/pages/…’)

#22 [internal function]: APP\pages\issue\IssueHandler->view(Array, Object(APP\core\Request))

#23 /lib/pkp/classes/core/PKPRouter.php(334): call_user_func(Array, Array, Object(APP\core\Request))

#24 /lib/pkp/classes/core/PKPPageRouter.php(277): PKP\core\PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(APP\core\Request), Array, false)

#25 /lib/pkp/classes/core/Dispatcher.php(165): PKP\core\PKPPageRouter->route(Object(APP\core\Request))

#26 /lib/pkp/classes/core/PKPApplication.php(387): PKP\core\Dispatcher->dispatch(Object(APP\core\Request))

#27 /index.php(21): PKP\core\PKPApplication->execute()

#28 {main} thrown in /lib/pkp/classes/galley/Galley.php on line 160

At the same time there seems to be errors with just about every plugin regardless of trying to view an issue that works or one that does not:

[19-Oct-2023 08:35:47 UTC] Exception: Plugin referral expected to inherit from ReferralPlugin, actual type NULL in /lib/pkp/classes/plugins/PluginRegistry.php:203
Stack trace: …

etc.
etc.

Whay could all these plugins be trowing up errors like this?

Hi @geirrosset,

I deleted the other response on this thread – it was AI-generated spam. (These look like helpful responses but are not at all.)

Looking at this error message:

Fatal error: Uncaught Error: Call to a member function getDisplayName() on null in /lib/pkp/classes/galley/Galley.php:160

…it looks like this is related to a line of code that gets information about the language of the galley.

Can you try the following SQL query?

SELECT DISTINCT locale, COUNT(*) FROM publication_galleys;

Regards,
Alec Smecher
Public Knowledge Project Team

Yes. Does not mean much to me, but this is the result:

no_NO 2084

Btw the same as the number of lines in the publication_galleys table.

While I am waiting I am just browsing the database looking for differences between issues that work and ones that don’t.

The two screenshots are from the database and shows the last of the issues that do work (issueId 233 all issue newer than this work), and the first of the issues that don’t (issueId 219 anything older does not work) for a given journal.

I assume that the differences in rows is due to different versions of OJS, but I thought I’d put this here.

Issue 233 has two rows for prefix, abstract, title and subtitle. I’m guessing it could have something to do with adittional language packs which were active for a period but caused more grief than anything else so now we are back to just one language for submisssions.

Why there is a big jump from publication_id 1813 to 2053 I do not know.

All issues are published using quickSubmit. I see ##common.fil.namingPattern## several places where the file name should be, but it is the same in 3.3 which works, so that seems unrelated.

To me it looks as if nothing published in 2.4.7 or older works. We upgraded to 3.2.x in January 2021, and some issues were probably published then and back dated to 2020 which is why they still work. Anything older than 2019 does not work for any of our journals.

@asmecher Any of this mean anything to you? Could it be something from 2.X that is breaking things?

While we are waiting for this I can say that we have tried the 3.4.0.3 upgrade again on a working 3.3.0.15 installation upgraded from the same database as in the OP on a different server. Gives us the same error on any issue published in what we believe is 2.4.X. Anything more recent works.

Hi @geirrosset,

It’s weird that you’re seeing contents in the database with a locale of no_NO – are you maintaining your own translation or something? Starting with 3.4.0 we moved most translations from locale codes like xx_YY to two-letter locale codes like xx. But no_NO isn’t part of our known translation set, so it’s possible this content didn’t get migrated.

Regards,
Alec Smecher
Public Knowledge Project Team

Not at all. All we have done, and this is true as far back as 2.4.x is add some missing translations to the locale files where needed. Nothing custom in any of our deployments.

I say again. These journal issues/articles have all worked starting from 2.4.x all the way up to and including 3.3.0.15. (Current OJS deployed at https://ojs.novus.no) Suddenly in 3.4.0.3 nothing submitted in 2.x (it is the only common factor as far as I can see) works. Anything submitted in 3.x works. And it is not about the galleys, we never get as far as trying to download the pdfs.

Hi @geirrosset,

I think this is related to your language data.

The Norwegian locale code used to be no_NO in OJS 2.x, but was changed with OJS 3.0 to nb_NO to be more correct and standard-compliant. The upgrade from 2.x to 3.x should have adapted all no_NO data to nb_NO – but it looks like that didn’t happen in your case. (Are you sure the 2.x to 3.x upgrade completed successfully?)

Then, in OJS 3.4, we moved most locales to two-letter codes, so it should have become nb instead of nb_NO. But because your locale data was still no_NO, it didn’t get adapted.

It’s not the end of the world, but it’ll take some database work.

Essentially, you’ll have to update any table with a locale column so that the no_NO values are changed to nb instead. Then there are a number of additional settings that will need adaptation – I would recommend searching a database dump for no_NO to find these.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @geirrosset,

I think this is related to your language data.

The Norwegian locale code used to be no_NO in OJS 2.x, but was changed with OJS 3.0 to nb_NO to be more correct and standard-compliant. The upgrade from 2.x to 3.x should have adapted all no_NO data to nb_NO – but it looks like that didn’t happen in your case. (Are you sure the 2.x to 3.x upgrade completed successfully?)

Then, in OJS 3.4, we moved most locales to two-letter codes, so it should have become nb instead of nb_NO. But because your locale data was still no_NO, it didn’t get adapted.

It’s not the end of the world, but it’ll take some database work.

Essentially, you’ll have to update any table with a locale column so that the no_NO values are changed to nb instead. Then there are a number of additional settings that will need adaptation – I would recommend searching a database dump for no_NO to find these.

Make sure to take a complete backup before trying any of this!

Regards,
Alec Smecher
Public Knowledge Project Team

As this is currently a working site I don’t want to rush it.

To be clear:

Should I change all instances of “no_NO” to “nb_NO” and have the 3.4 upgrade change it to “nb” OR should I change them all straight to “nb” in the database before attempting an upgrade to 3.4?

Any query that will give me a list of all tables that have locale? Not well versed in SQL queries.

A backup is a given :slight_smile:

Geir

Hi @geirrosset,

If you’re in production with 3.3, then you’ll need to change no_NO to no_NB.
If you’re in production with 3.4, then you’ll need to change no_NO to nb.

You can list all SQL tables having a locale column using…

SELECT DISTINCT table_name FROM INFORMATION_SCHEMA.COLUMNS WHERE column_name IN('locale') AND table_schema = 'my_database_name';

…replacing my_database_name with the name of the database from config.inc.php.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello

That got us a lot further, but the site still does not work as it should. Here is what I found:

  1. Using Norwegian as primary (and only) locale there now seems to be a lot of translations that are missing, which were not missing in 3.3.0.15. But that is not a deal breaker as we could add missing translations ourselves, and it is mostly in the back end.

  2. I brought up and old journal issue, which did not work at all before changing over to nb_NO as instructed by you above. By chance one article in the issue I checked had a title that had some missing characters. I Unpublished that article, but now there is no button to schedule publication so I cannot get that article back online. Under “Copyediting” above where the file is listed there is a “spinning wheel of death”. Never finishes loading. There is no way to send it to Production in the workflow either. There is no “Participants” column to the right in any of the tabs for old issues.

  3. For new issues (published in 3.X) I can unpublish and republish.

Hi @geirrosset,

Great, that sounds like progress.

Can you say a little more about the missing characters in the title? It’s possible that there is something changing in your database configuration while you’re trying this, and it’s a very good idea to get that figured out before moving your upgrade into production, since it’s very hard to disentangle character set problems once you’ve mixed two kinds of encodings together.

When you get the spinning wheel of death, does anything show up in the PHP error log? I expect there will be something.

Regards,
Alec Smecher
Public Knowledge Project Team

Two steps forward, one step backward. We’ll just have to deal with one question at a time until things work.

From the error log:

Error on sending request(POST /index.php/DIN/$$$call$$$/grid/users/stage-participant/stage-participant-grid/save-participant HTTP/1.1); uri(/index.php/DIN/$$$call$$$/grid/users/stage-participant/stage-participant-grid/save-participant) content-length(1145): ReceiveAckHdr: timeout 300 is exceeded, referer: https://test-ojs.novus.no/index.php/DIN/workflow/index/2006/5

Seems the reason I could not re-publish the article once unpublished was that my site manager user was both author and editor. When I chose to view the submission in the editorial workflow I could re-publish it.

Now the main problem is, apart from all the missing translations, that old issues keep telling me I do not have “access to this part of the workflow” when trying to edit them. That is probably also related to user roles, but if I can’t access the workflow for the article I can’t assign me (or anyone else) as editor, or even see who is surrently assigned (if anyone).