OJS version 3.3.0.16
PHP 8.0.30
Good day, we are having problems with publication in our journals since the affiliation metadata of some submissions appears with characters of: a:1:{s:5:”affiliation-name”;}, How can we address this problem?
Thank you
Hi @alexpineda,
I suspect this is related to the RoR plugin. Are you actively using it? Did you previously use it but then remove it?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, thanks for the prompt response
We are not using the ROR plugin and it has not been used either, we have had this problem even before the migration to the version from OJS 3.2.1.1 to OJS 3.3.0.16. Doing tests we found that the error is being generated from the very creation of the user since the “affiliation” section is completed but when the profile is validated this section is loaded with an “array” as shown in the image. When this user initiates a submission, the author’s “affiliation” field is left with an inappropriate structure as shown in the image and this is reflected at the time of publishing.
Hi @alexpineda,
I’d suggest looking in the user_settings table where setting_name = 'affiliation' to see what the difference between the working and not-working accounts is. I suspect there was an upgrade hiccough many versions ago, and this is what resulted.
You should be able to check how many problem entries there are with a query like:
SELECT COUNT(*) FROM user_settings WHERE setting_name = 'affiliation' AND setting_value LIKE 'a:%';
Regards,
Alec Smecher
Public Knowledge Project Team
hi @asmecher
Validating the “user_settings” table does not find ‘a:%’ but does find 18 ‘setting_value’ with ‘array’.
The same search was performed in the “author_settings” table last week after the migration, finding 2648 elements with ‘a:{’, these were corrected and with this all publications to date were adjusted; In less than 15 days there are already 29 new ‘affiliation’ in the “author_settings” table with errors of ‘a:%’, visually affecting the publications.
select * from author_settings where setting_name like ‘affiliation’ and setting_value like ‘%a:1%’;
Hi @alexpineda,
That’s very odd – the affiliation entries are supposed to be one row per language, with the locale column indicating the language, and setting_value containing just the text for that language. It appears that yours has a PHP array packed into setting_value instead.
If I were fixing this, I’d probably throw together a short PHP script to fix the bad data. I’m not sure how it would’ve gotten that way – perhaps operating on a database with a new codebase after a failed upgrade, or some kind of customization?
I suspect the values that simply contain Array are what happens when you continue to operate the system with the bad data in place – eventually it gets cast from an array to a string, and the actual content gets clobbered with just the value Array.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher I’m reviving this topic with a very similar problem, which includes seeing “Array” in the affiliation field of the frontend profile view. What concerns me is that it’s a recent problem (2023+) and not related to a long-past migration.
OJS v3.3.20
PostgreSQL 12
Theme bootstrap3 v3.2.0-6
Here is what we’re seeing on the front end
“user_settings” look the same for both first and second author.
en_US | affiliation | 0 | 0 | {"en_US":"Bradley University"} | object
en_US | affiliation | 0 | 0 | {"en_US":"Bradley University"} | object
The only difference I’ve found is the affiliation row in “author_settings”
en_US | affiliation | a:1:{s:5:"en_US";s:18:"Bradley University";}
en_US | affiliation | Bradley University
I ran the COUNT(*) query and it looks like we only have 1,485 authors with a serialized locale in the affiliation field out of a total of 45K authors.
What concerns me, though, is that these users registered within months of each other in 2023 and are back-to-back in the “author_settings” table. Yet why does one have serialized data in the affiliation field and the other doesn’t? (We are not using the ROR plugin.)
Richard Higgins
Indiana U Libraries
Hi @Richard-Higgins,
Are there any relevant differences in how the affected submissions were brought into the system? For example, did some of these make use of QuickSubmit or another import/export process rather than the regular workflow?
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher In this particular instance: No. Submission went through full editorial workflow. Paper first submitted Feb 2023, published March 2025.
i noticed a patch of an affiliation issue in “bootstrap3” that was committed in 2024 Affiliation should not be localized on registration form · Issue #159 · pkp/bootstrap3 · GitHub. But this doesn’t seem to coincide because these users both registered in 2023, and the data problem is in “author_settings.” The affiliations would have been added later to “author_settings”? It doesn’t look like the “user_settings” table interacts in any way with “author_settings.”
Hi @Richard-Higgins,
I think there must have been some kind of intervention in your system when those entries were created – a custom plugin, or a modification of the schema file for author entries (lib/pkp/schemas/author.json), or something similar. I don’t see any data like that in any of the large databases that I have handy here, and it hasn’t come up elsewhere on the forum that I can spot.
Sorry I can’t be more help!
Regards,
Alec Smecher
Public Knowledge Project Team
No problem, @asmecher! Thanks for responding. At least it’s fairly isolated. I’m going to test a manual remediation of the 1,400 entries with serial data in “author_settings.” And we’ll keep an eye on things.
Following up with separate psql queries that clear up both problems we’re seeing. Since these issues are related to a small subset of users/authors intervening directly in the database seems reasonable.
user_settings table) UPDATE user_settings
SET setting_value = 'Any University', setting_type = 'string'
WHERE setting_name = 'affiliation' AND user_id = 11111;
author_settings table) UPDATE author_settings
SET setting_value = 'Any University'
WHERE setting_name = 'affiliation' AND author_id = 99999;
