I am doing the tests to update the portal ojs 2.4.8-2 for version 3.1.1-2.
After the update, the administrative page displays loading constantly.
By analyzing the php logs, I see the messages below:
PHP Warning: mb_internal_encoding(): Unknown encoding "" in /web/ojs-3.1.1-2/lib/pkp/classes/core/PKPString.inc.php on line 70
PHP Warning: mb_internal_encoding(): Unknown encoding "" in /web/ojs-3.1.1-2/lib/pkp/classes/core/PKPString.inc.php on line 70
PHP Warning: mb_internal_encoding(): Unknown encoding "" in /web/ojs-3.1.1-2/lib/pkp/classes/core/PKPString.inc.php on line 70, referer: http://xxxx.xxx.xxx.xxx/index.php/xxxx/submissions
Malformed UTF-8 characters, possibly incorrectly encoded, referer: http://xx.xxx.xxx.xx/index.php/xxx/submissions
I tried to change the policies in the “Localization Settings” section of the config.
The operating system is FreeBSD, charset iso-8859-1.
How can I fix this problem?
Regargs,
Renato L. Sousa
Hi @rensousa,
What does your config.inc.php look like with respect to character set configuration?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I made several possible combinations.
At the moment I changed the config.inc.php to the default that is the original site (2.4.8-1):
[i18n]
locale = pt_BR
client_charset = iso-8859-1
connection_charset = utf-8
database_charset = utf-8
charset_normalization = On
The errors displayed in the apache log are:
Invalid argument supplied for foreach() in /web/ojs-3.1.1-2/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 1578
The top of the administration page continues to display Loading …
Regards,
Renato L. Sousa
Hi @rensousa,
Where did the connection_charset and database_charset settings of utf-8 come from? These settings should be utf8, not utf-8, in my experience.
I haven’t worked with a client_charset other than utf-8 for a long time (the dash here is intended!), so it’s possible that there has been some regression in the handling of non-UTF-8 content. Generally speaking I’d suggest getting everything going with UTF-8 if at all possible; this might mean transcoding your database.
Regards,
Alec Smecher
Public Knowledge Project Team
HI @asmecher,
Where did the connection_charset and database_charset settings of utf-8 come from? These settings should be utf8, not utf-8, in my experience.
The connection_charset and database_charset settings are the ones that are in effect in version 2.4.8-2. I confess that there must be some errors in the current ojs portal from an earlier update …
haven’t worked with a client_charset other than utf-8 for a long time (the dash here is intended!), so it’s possible that there has been some regression in the handling of non-UTF-8 content. Generally speaking I’d suggest getting everything going with UTF-8 if at all possible; this might mean transcoding your database.
In the last attempt I left the locale directive configured with “pt_BR” and left all other commented settings (default value). I also changed the default_charset value to “UTF-8” via apache configuration.
I still sometimes get the following error in the update script:
PHP Warning: xml_parser_set_option(): Unsupported target encoding “” in /web/ojs-3.1.1-2/lib/pkp/classes/xml/XMLParser.inc.php on line 272
Administrative pages continue to load constantly. The version registered in the portal is still old (2.4.8-2).
I’m getting expert on unsuccessful migrations 
Regards,
Renato L. Sousa
Hi @rensousa,
If OJS is still reporting that it’s running version 2.x, then the upgrade script didn’t complete successfully, and I’d recommend debugging that first.
Regards,
Alec Smecher
Public Knowledge Project Team
