Problem with upgrade from OJS 3.3 to 3.4 No Journal Sections after upgrade

Software Support
1

Describe the issue or problem
After a successful upgrade from 3.3.015 to 3.4.01, I got an error: PKPSection->getLocalizedTitle() returning NULL, while there was an actual string in the database. It strongly affected the whole system, since the Submissions list was failing to display.

Additional information
section_settings table looks OK, en_US and pl_PL were changed during the upgrade to en and pl, setting_type column disappeared. All sections do have titles in both languages.

2

Hi @TruePepe,

Did you update the locale setting in the i18n section of config.inc.php to the new two-letter style of code?

What do you have for the installed_locales and supported_locales columns in the site table?

What do you see in the primary_locale column of the journals table?

What do you get for the following query?

select * from journal_settings where setting_name in ('supportedFormLocales', 'supportedLocales', 'supportedSubmissionLocales');

And finally, have you tried flushing your data cache? (You can do this in the administrator’s interface, or manually by removing all .php files from cache/ and all files from cache/opcache. If your file permissions in cache/ are not set properly, the administrator interface cache clear may not work fully.)

Regards,
Alec Smecher
Public Knowledge Project Team

3

Ciao Alec,

Did you update the locale setting in the i18n section of config.inc.php to the new two-letter style of code?
Yes, now we have:
locale = it Instead locale = it_IT

What do you have for the installed_locales and supported_locales columns in the site table?
installed_locales = [“de”,“el”,“en”,“es”,“fa”,“fr_CA”,“it”,“ja”,“nl”,“pt_BR”,“pt_PT”,“ro”,“ca”,“cs”,“da”,“eu”,“hr”,“no_NO”,“ru”,“sv”,“tr”,“vi”,“zh_CN”,“zh_Hant”]
supported_locales = [“de”,“el”,“en”,“es”,“fa”,“fr_CA”,“it”,“ja”,“nl”,“pt_BR”,“pt_PT”,“ro”,“ca”,“cs”,“da”,“eu”,“hr”,“no_NO”,“ru”,“sv”,“tr”,“vi”,“zh_CN”,“zh_Hant”]

What do you see in the primary_locale column of the journals table?
primary_locale = it

in my server with linux i have this envronment:
LANG=it_IT.UTF-8
LC_CTYPE=“it_IT.UTF-8”
LC_NUMERIC=“it_IT.UTF-8”
LC_TIME=“it_IT.UTF-8”
LC_COLLATE=“it_IT.UTF-8”
LC_MONETARY=“it_IT.UTF-8”
LC_MESSAGES=“it_IT.UTF-8”
LC_PAPER=“it_IT.UTF-8”
LC_NAME=“it_IT.UTF-8”
LC_ADDRESS=“it_IT.UTF-8”
LC_TELEPHONE=“it_IT.UTF-8”
LC_MEASUREMENT=“it_IT.UTF-8”
LC_IDENTIFICATION=“it_IT.UTF-8”
LC_ALL=

I get from the query:

85 1
supportedFormLocales [it]
86 1
supportedLocales [it]
87 1
supportedSubmissionLocales [it]
188 2
supportedFormLocales [it,en]
189 2
supportedLocales [it,en]
190 2
supportedSubmissionLocales [it,en]
316 3
supportedFormLocales [it]
317 3
supportedLocales [it]
318 3
supportedSubmissionLocales [it]
454 4
supportedFormLocales [it]
455 4
supportedLocales [it]
456 4
supportedSubmissionLocales [it]
535 5
supportedFormLocales [it]
536 5
supportedLocales [en,it]
537 5
supportedSubmissionLocales [it]
673 6
supportedFormLocales [it]
674 6
supportedLocales [it,en]
675 6
supportedSubmissionLocales [it]

I have done the flushing of data cache…but the problem persists, If you need more information let me know.

Ciao Angelo

4

Hi @angelo.venera,

Hmm, I’m having trouble recreating this locally – I can make a fresh installation with Italian-only language configuration without trouble. (If it’s possible, could you try a fresh installation and see if that’s possible on your machine?)

Are there any directories anywhere in your installation called it_IT? For example in a 3rd-party plugin?

Regards,
Alec Smecher
Public Knowledge Project Team

5

Ciao Alec,

I did some further tests, in my opinion the problem focuses on the management of languages, I tried with Italian, English, French and German, every time I click on language or navigation or plugin of any magazine the error is generated, it generates even when I click at the top right where there is the alarm symbol (bell icon). As per your suggestion, I checked the third-party plugins and corrected the directory from it_IT to it but nothing changes.

Angelo

6

Hi everyone,

I also encountered this issue when upgrading from 3.3.0-14 to 3.4.0-3. My setting is very similar – multi-language setup with some journals in Polish and English (forms, UI and submissions) and some in English only. After the upgrade, OJS wasn’t able to fetch submissions for English-only journals.
“/journalname/submissions”, “/journalname/stats/publications/publications” and “/journalname/stats/editorial/editorial” are completely blank, and “/journalname/management/settings/context#sections” displays infinite loading spinner.

Enabling verbose database logging shows that OJS queries the database for information about two sections:

[Mon Nov 06 03:10:19.159480 2023] [php:notice] [pid 1552] [client 127.0.0.1:43402] Database query\nselect * from section_settings where section_id = ?\n[3], referer: http://localhost/index.php/import/management/settings/context
[Mon Nov 06 03:10:19.159658 2023] [php:notice] [pid 1552] [client 127.0.0.1:43402] Database query\nselect * from section_settings where section_id = ?\n[14], referer: http://localhost/index.php/import/management/settings/context

Problem is, while section 3 is the default section for this journal, I don’t remember setting up another section (14). All of our journals use only one, default section. There are no settings associated with section 14 in the section_settings table, which from my understanding is where the null passed to getLocalizedTitle() comes from.

Inserting into section_settings row with setting_name equal to 'title' and locale equal to the default locale specified in config.inc.php makes the journal work correctly again.

Unfortunately I wasn’t able to reproduce this issue in a clean OJS setup. Let me know if there’s any additional information I could provide to help identify the problem.