OJS 2.4.5 log errors: Illegal string offset 'en_US' in DataObject.inc.php

After migrating from 2.3.6 to 2.4.5 now I finally found time to clean logs.

I found and apply a few patches that are included in 2.4.6… but I can find any reference to this one:

[Tue Jun 16 17:06:37 2015] [error] [client 200.129.20.3] ojs2 has produced an error\n  Message: WARNING: Illegal string offset 'fr_FR'\n  In file: /home/ojs/source/versions/git-ojs/lib/pkp/classes/core/DataObject.inc.php\n  At line: 133\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.4.39-0+deb7u2\n   Apache Version: Apache/2.2.22 (Debian)\n   DB Driver: mysql\n   DB server version: 5.5.43-0+deb7u1, referer: http://atheneadigital.net/

[Tue Jun 16 17:07:20 2015] [error] [client 158.109.236.45] ojs2 has produced an error\n  Message: WARNING: Illegal string offset 'es_ES'\n  In file: /home/ojs/source/versions/git-ojs/lib/pkp/classes/core/DataObject.inc.php\n  At line: 133\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.4.39-0+deb7u2\n   Apache Version: Apache/2.2.22 (Debian)\n   DB Driver: mysql\n   DB server version: 5.5.43-0+deb7u1

Any clue about what is this about?

Thanks for your time,
m.

Hi Marc,

This means that there is a mix of localized and non-localized content in some database field. The message itself doesn’t give enough information to debug, so I’d suggest adding an error_log call in the vicinity for when is_string($this->_data[$key]) is true, e.g. using error_log(print_r($this, true));

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Following your suggestion, I got this:

[Fri Jun 19 16:18:11 2015] [error] [client 79.147.95.132] Extended error Start:
[Fri Jun 19 16:18:11 2015] [error] [client 79.147.95.132] Author Object
(
    [_data] => Array
    (
        [id] => 1638
        [submissionId] => 1231
        [firstName] => Isabel
        [middleName] =>
        [lastName] => Jane Doe
        [country] => CL
        [email] => jane.doe@u.uchile.cl
        [url] =>
        [primaryContact] => 0
        [sequence] => 2
        [gs] => 
        [Fri Jun 19 16:18:11 2015] [error] [client 79.147.95.132] Extended Error End

        [Fri Jun 19 16:18:11 2015] [error] [client 79.147.95.132] ojs2 has produced an error
        Message: WARNING: Illegal string offset 'fr_FR'
        In file: /home/ojs/source/versions/git-ojs/lib/pkp/classes/core/DataObject.inc.php
        At line: 139
        Stacktrace: 
        Server info:
        OS: Linux
        PHP Version: 5.4.39-0+deb7u2
       Apache Version: Apache/2.2.22 (Debian)
       DB Driver: mysql
       DB server version: 5.5.43-0+deb7u1
               *     'en_US' => 'in English',

So, seams clear to me that the problem is in the Author’s metadata… that don’t include “fr_FR” information (IMHO, something quite normal in OJS jornals in live during years, because lang criteria change between Editors)

I will try to extend metadata info for this author to see what happens.

As always, thanks a lot for your help Alec.

Take care,
m.

Hi @marc,

I’d suggest exploring that user’s entries in the user_settings table. I suspect there’s something there that’s supposed to have a value in the locale column, but doesn’t.

Regards,
Alec Smecher
Public Knowledge Project Team

Plenty of them… :smile:

Some also include an Array with locale and google code.

This is one of our oldest journals, so I suspect this is from former migrations.

Only 5 authors added their google code so I export those rows, and I did…

DELETE FROM user_settings WHERE setting_value LIKE "gs"

and job done. The error disappears.

Now, the issue is that you can not add a new GoogleCode from authors article’s metadata, but my guess is that I need to add an empty “gs” for each user because OJS code UPDADES does not insert and expects to find and existing row.

It will be fixed on Monday.

Thanks for your help Alec,
m.

Hi @marc,

Not all entries in user_settings are supposed to be localized – in OJS 2.4.6, it’s biography, signature, gossip, and affiliation entries. The others should have a blank locale column.

Regards,
Alec Smecher
Public Knowledge Project Team

Removing and inserting the few GS that are real did the job… now the error disapears in log.

Thanks Alec for your help,
m.