We’ve recently updated to the newer version of OJS and noticed duplicate fields in our settings, see image:
The fields are duplicate and won’t save any changes. Our installation runs 40 journals and this’s only happened in a few of them. I’m assuming this has something to do with the idioms/translations, as you may notice by the “199/4 languages completed” text bubble, but haven’t been able to pinpoint what exactly.
Has anyone else come across this issue?
Thanks!
What does the setting_name='privacyStatement' entry in the journal_settings table look like for that journal?
Regards,
Alec Smecher
Public Knowledge Project Team
You appear to have a data error; there should be a valid locale column (e.g. en_US, es_ES, and pt_BR) for all journal_settings where setting_name IN ('privacyStatement', 'readerInformation'). I see a few invalid entries. Removing these should correct the problem. Just be sure to take a good backup before working with the database manually, and delete cache/*.php after working with the database to ensure that OJS uses the newest data.
Regards,
Alec Smecher
Public Knowledge Project Team
I’m afraid not – it’s probably something particular to your upgrade history – but I’ll watch for others to encounter it, and hopefully that will narrow it down.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi, @asmecher
I have update OJS 3.2.1.1 but it gives some error during the submission on step 4 and step 5
The system told me I have used an updated system
But I have received an upgrading message.
I see on Error log file
PHP Fatal error: Uncaught Exception: DB Error: Table '**************.subeditor_submission_group' doesn't exist Query: SELECT u.user_id, COALESCE(ugl.setting_value, ugpl.setting_value) AS user_given, CASE WHEN ugl.setting_value <> '' THEN ufl.setting_value ELSE ufpl.setting_value END AS user_family FROM subeditor_submission_group e JOIN users u ON (e.user_id = u.user_id) LEFT JOIN user_settings ugl ON (u.user_id = ugl.user_id AND ugl.setting_name = ? AND ugl.locale = ?) LEFT JOIN user_settings ugpl ON (u.user_id = ugpl.user_id AND ugpl.setting_name = ? AND ugpl.locale = ?) LEFT JOIN user_settings ufl ON (u.user_id = ufl.user_id AND ufl.setting_name = ? AND ufl.locale = ?) LEFT JOIN user_settings ufpl ON (u.user_id = ufpl.user_id AND ufpl.setting_name = ? AND ufpl.locale = ?) WHERE e.context_id = ? AND e.assoc_id = ? AND e.assoc_type = ? ORDER BY user_family, user_given in /lib/pkp/classes/db/DAO.inc.php:703
Best Regards
Shahid Asghar
Hey @asmecher
Doing that solved the issue for the most part, but the fields are still duplicates (and we get the 3/4 languages completed which is odd because our sites have only three languages).
Thanks!
The duplication of fields is very strange! Are there any modifications or plugins that might be affecting this part of the form? (In particular, that field is implemented in lib/pkp/templates/management/website.tpl.)
Regards,
Alec Smecher
Public Knowledge Project Team
Hey @asmecher
We’re not using any customized plugins that could cause this issue, that we know of anyway. Only “standard” plugins, available from the gallery, such as Language Toggle Block, Usage Statistics, Publons Plugin, ORCID Profile Plugin, and so on.
Hi @asmecher
Turns out, we had two different issues.
The first problem was causing the duplicated fields: for some reason there was a “phantom” portuguese form, which was fixed when we deactivated and reactivated the Portuguese forms. We had to uncheck the form option twice.
The second problem was causing the “xxxx/x languages completed” issue, which had to do with the invalid entries. It’s also happening in the Descriptions (on the Information tab). We were wondering if we could run a query in our entire installation (basically an installation-wide find and replace) to fix this or if we’d have to do it in a case by case basis. If you could shed some light on this it’d be great!
Thanks!
The language settings are serialized PHP objects, which will be difficult to work with directly in SQL. However, I’ve never heard of this happening before, so hopefully it’ll be a rare one-off quirk.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
Could you please help us with the names of the fields for the Author, Reader, and Librarian descriptions?
Thanks for all your help!
I’m not sure I understand – are you looking for the setting names in the database corresponding to the “For Readers”, “For Authors”, and “For Librarians” setup fields?
Regards,
Alec Smecher
Public Knowledge Project Team
See:
SELECT * FROM journal_settings WHERE setting_name IN ('authorInformation', 'readerInformation', 'librarianInformation');
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you, that solves it for good!