Upgrade to OJS 3.3.0-5 - plugin settings error


after upgrading my OJS installation containing several journals I lost all custom blocks. I looked into the plugin_settings table. Many settings_values in the table seem to be wrong. Not only regarding the custom block plugin, but also others. For instance the entry
turns into something like

I got the same error with another fresh installed OJS
It seems to be a bug. Can someone help?

Many Regards

OK in OJS 3.3. it should be json.

As a workaround I inserted this into the setting_value of journal_id 5 (first line):

Screenshot from 2021-04-13 16-55-21

This seems to work, the custom blocks of the upper journal (context_id 5) are displayed.

The error was: All setting_values regarding the customblockmanagerplugin were in a wrong format (no counting ids) and all contained the (wrong) same names of the custom blocks of journal_id 9.
I’m a little worried whether the other plugin settings are correct.

Thanks for reporting @ohilbig01. Does this sound like the same bug as this report? Would you be able to show us what the blocks settings looked like before the upgrade?

Hi @NateWr ,

this seems to be the same error.

Before upgrade:

SELECT * FROM plugin_settings WHERE plugin_name LIKE 'customblockmanagerplugin'

The “after upgrade” is what you see in my post above, except for the first line, which I already modified.
Do you also need the entries of the respective custom blocks?
I would have to upgrade the whole thing again, because I already tried to fix the wrong entries.
But I could do it with another installation I’m maintaining.

Before you modified it, did it look like the other entries?

["license", "kindlySupported", "printVersion", "diniCertificate", "openAccess", "twitter", "identifier", "indexing"]

That’s what it should look like and you shouldn’t need to reset it to an object. It might even cause problems if it’s in object form like {"0":"license","1":"kindlySupported"...}.

Yes it did look like the other entries.
I turned all of the entries into arrays and that works. Thank you!

But there is still another problem:

If I save the sidebar settings and reload the page, the view in the frontend is correct, but the order in the settings is wrong again. Every time after saving, I lose the order.
So if save the settings a second time (maybe after editing the footer), the blocks in the sidebar would be in the wrong order. I always have to rearrange the blocks in the backend.

I’ve managed to find and fix the upgrade bug. You can find out more about that here.

Thanks, this sounded familiar and it looks like it was filed a while ago but the fix never got merged in. You can follow the status of that at Ordering of sidebar blocks changed upon visiting the settings form · Issue #6683 · pkp/pkp-lib · GitHub.

Thank you very much. Yes I know, the other bug is older. I always forgot to report it.

Hi @NateWr ,

I built my own metadata field containing DDCs, which are stored in OJS in the publication_settings as


After upgrading to OJS this entry still looks the same. When depublishing the article and saving it again, the entry converts to


So it seems to work this way, OJS3.3 still understands this syntax. But is it safe to leave it that way, or would it be better to write a script which converts all the entries?

If it’s in the publication_settings table and you’ve added it to the publication schema, then I’d recommend converting all of the entries.

Yes, I added it to the schema. Thank you!

1 Like