I upgraded to 2.4.6 last week. My question comes at the end after the explanation.
A user now noticed that the custom block plugins don’t work anymore.
When as admin clicking System Plugins → Block Plugins and then Edit, some of the blocks have their original content there, and some have not. Instead they have the text “Array” in the field. The error message in the log is
WARNING: array_key_exists() expects parameter 2 to be array, string given\n In file: /usr/local/ojs/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php\n At line: 195
We have the version of plugins that came with the new release (2.4.6).
The old custom blocks are displayed on the journal page, but cannot
The new custom blocks (after upgrade) can be edited, but won’t show
on the journal page.
I have to admit that it’s not entirely clear to me how this could happen - could you maybe specify what you exactly meant by
Does this mean that you just upgraded this single plugin, before you upgraded your OJS installation to 2.4.6?
Anyway - let me explain how the upgrade mechanism works for this plugin and what you could do to solve this problem.
In the file …/ojs/dbscripts/xml/upgrade.xml you can see (nearly at the bottom of this file) the following code snippet:
This means that - when you upgraded OJS from 2.x to 2.4.6 - the function “localizeCustomBlockSettings” should have been executed, whereby the custom block texts in the database should have been transformed into the new (multilingual) format.
Unfortunately I can’t figure out why this didn’t happen when you upgraded to 2.4.6…
If you run the upgrade script again (in OJS 2.4.6), this function won’t be executed any more because of the maxversion=“188.8.131.52” limitation.
A possible solution could be:
Add the following lines
temporarily to this file (preferably beneath the above cited code snippet) and run the upgrade script again.
Thus the function “localizeCustomBlockSettings” should be executed again - after that, you can delete these added lines.
Also I noted that when I create a new block, it won’t be visible on the page. So everything is as before with the exception that we don’t get any messages in error_log.
About that I wrote that this plugin must have been upgraded ahead of OJS, I was thinking that perhaps the journal manager of the journal with this problem might have upgraded the plugin himself. Is there any way to see when it was done?
I have recently installed a new version of 2.4.6 using our old database. It’s only in English. However in the Custom Locale Plugin page no locale file is listed. It should have en_US listed there. I realized this when wanted to use Articles and Issues XML plugin when it complained about missing locales:
Error message: An issue title (X) was provided in a locale (“en_US”) that this journal does not support.
I had run upgrade script during the installation process.
Shall I do something like what was suggested above to resolve this?
I checked the log but nothing is reported as error. In the Custom Locale plugin page there is a table with the heading of “Available Locales” but nothing is listed in it.
I changed “installed” tag to off in config.in.conf. I noticed in install page English is listed in locale setting but not ticked. However the primary language is set to English. I was wondering if it is safe to install it again (selecting English this time) without losing any data. So maybe leave everything as it is, plus removing the tick for creating a new db, putting admin account detail back as it is at the moment and do another install. I’m concerned I lose the previous setting.
I checked the db entry for the site table. installed_locales and supported_locales are both set to en_US. This is while $journal->getSupportedLocaleNames() returns an array of length zero.
By chance I re-saved the setting of my journals in Administrator->Hosted Journals and then all the missing setting_value column of supportedLocales are back in db and also en_US is listed in the Custom Locale Plugin table.