Custom Block Plugin not working after upgrade to 2.4.6

Software Support
1

I upgraded to 2.4.6 last week. My question comes at the end after the explanation. :slight_smile:

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).

Problem

  • The old custom blocks are displayed on the journal page, but cannot
    be edited.
  • The new custom blocks (after upgrade) can be edited, but won’t show
    on the journal page.

Now this problem is supposed to be because of the change to the custom block manager plugin to become multilingual ([OJS] CustomBlockManager-PlugIn localised · Issue #277 · pkp/pkp-lib · GitHub), and that we seem to have upgraded the plugin ahead of upgrading the rest of the code, and upgrading the database has not run the upgrades for this plugin.

My question now is: How can I have the database upgraded for the CustomBlock Plugin now even though I already ran the upgrade.php script?

2

Hi,
I hope, I can help you in this case…

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:

<upgrade minversion="2.0.0.0" maxversion="2.4.5.9">
	<code function="localizeCustomBlockSettings" />
	<code function="removeCustomIdentifierSuffixOption" />
	<note file="docs/release-notes/README-2.4.6" />
</upgrade>

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=“2.4.5.9” limitation.

A possible solution could be:
Add the following lines

<upgrade minversion="2.0.0.0" maxversion="2.4.6.9">
	<code function="localizeCustomBlockSettings" />
</upgrade>

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.

Best regards,
Felix

3

Hi Felix,

Thanks for your help.

I did the changes to upgrade.xml and ran the upgrade.php script successfully.

This helped in one way. The newest custom blocks are now visible on the web page.

We still have a problem. Now all custom block in edit mode show just the string “Array”.

No message is written in the error log. Do you have any idea of what could be wrong?

Kind regards,
Maria

4

Hi again,

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?

Kind regards,
Maria

5

Hi Maria,

I’ve just sent you a personal message (it would be good for me to have a dump of your database).

Best regards,
Felix

6

Problem solved.

After first running upgrade.php for only the plugin, then removing cache files, the plugin works perfectly reports our user.

Thanks to all who helped me.

/ Maria

7

Hi,

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?

<upgrade minversion="2.0.0.0" maxversion="2.4.6.9">
	<code function="localizeCustomBlockSettings" />
</upgrade>

Thanks in advance
Ghazal

8

Hi @salehig,

Can you double-check and re-save the Languages settings page, first under Site Administration, then under Journal Management?

Regards,
Alec Smecher
Public Knowledge Project Team

9

Thanks for your reply @asmecher.

I had re-saved English as Primary and supported locale in administrator, didn’t help. I un-clicked, saved. Then clicked and saved also.

In Journal Manager->Languages there is no language to set. I get this message:

“Sorry, no additional languages are available. Contact your site administrator if you wish to use additional languages with this journal.”

Regards
Ghazal

10

Hi @salehig,

It sounds like your language settings are OK. What do you see when you go into the Custom Locales plugin? Can you check your PHP error log to see if anything relevant is there?

Regards,
Alec Smecher
Public Knowledge Project Team

11

Hi Alec,

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.

I did a query from db on journal_setting table. I have three journals with id’s 1, 11, 12:
±-----------±-------±---------------------------±-----------------------±-------------+
| journal_id | locale | setting_name | setting_value | setting_type |
±-----------±-------±---------------------------±-----------------------±-------------+
| 1 | | supportedLocales | a:0:{} | object |
| 11 | | supportedLocales | a:0:{} | object |
| 11 | | supportedFormLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 11 | | supportedSubmissionLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 12 | | supportedFormLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 12 | | supportedSubmissionLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 12 | | supportedLocales | a:0:{} | object |
| 13 | | supportedFormLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 13 | | supportedSubmissionLocales | a:1:{i:0;s:5:“en_US”;} | object |
| 13 | | supportedLocales | a:1:{i:0;s:5:“en_US”;} | object |
±-----------±-------±---------------------------±-----------------------±-------------+

P.S. the version is 2.4.6.

Regards
Ghazal

12

Hi @salehig,

Can you post a screenshot of your Site Administrator’s Languages page?

Regards,
Alec Smecher
Public Knowledge Project Team

13

14

@asmecher

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.

Thanks anyway.

Regards
Ghazal

15

Hi @salehig,

OK, glad to hear you got it going.

Regards,
Alec Smecher
Public Knowledge Project Team