Problem with characters in version 3.1.0.1

Hi all,

The version of OJS is 3.1.0.1, upgraded from 2.4.X.X.

There’s a problem in Submissions area: an error message opens up few times, and when it’s closed (3-4times), nothing happens and when any of the options is clicked (Unassigned, All active, Archives), nothing appears.

I got everything working by swithing connection & database charset to utf8 BUT simultaneuosly I lost all the special characters. We run our paper in English, but since the authors are around the world, and some of them from Scandinavia, their names often has those characters like ä, å, ö, ø, ü.

The PHP-version is 5.5.38, Apache version is 2.4.6 on a Linux server.

AAny further ideas? Thanks in advance!

  • tinde

Please upgrade php to at least 5.6.32. Check in database are all tables set to utf8.

Thanks

Hi @tinde123,

Ideally your character set configuration in config.inc.php should be:

client_charset = utf-8
connection_charset = utf8
database_charset = utf8

The inconsistency is intentional.

OJS 3.1.x requires at least PHP5.6, so make sure you upgrade your PHP.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,
now the php-version is upgraded to 5.6.32 and here’s printscreen of our config.inc.php, as well as the problematic characters. So it didn’t work. BUT still the Submissions work properly.

kuva

Any further ideas?

Thanks in advance

  • tinde

Is your database encoded in latin1?

Basically the scandic letters are possibly now strored as utf8 characters, but in latin1 format. So basically you have a latin1 database table and for example letter ä is saved there as ä.

If your database is encoded as latin1, then you could try:
client_charset = utf-8
connection_charset = Off
database_charset = Off
charset_normalization = Off

If you turn on for example the connection_charset to utf8, the system will possible fetch the latin1 encoded data, for example ä and instead of showing the letter ä, will encode both of those character à and ¤ as utf8 => thus showing you the letters you see now.

After changing the settings, you need to empty the OJS cache. Instructions are here in the forum if you search. Also test the settings by doing a new submission.

But be careful that you do not get mixed encodings in the database. I mean, it would be best to try these on a different server and not on a server where you are receiving manuscripts.

And finally, if your data is strored in latin1 encoded tables, then I would suggest you convert the tables and the data to actual utf8. This is a bit tricky, but there are some instructions on how to do it online. We have data in latin1 tables and are preparing to convert it during our next maintenance break.

1 Like

I have had situation that on new server hosting company made as default utf8mb4_general_ci. My database was utf8_general_ci.

When I changed server connection from utf8mb4_general_ci to utf8_general_ci everything was fine.

Dear All,

We are still in trouble with our www.sjlas.org site.

If we configure the default locales in configuration file the international chars are not shown correctly

We still have problems with our site configuration.
We have tried several different setups but could not get it fully working.

If we make the following changes in configuration of the site’s config file, the international character sets are broken.
client_charset = utf-8
connection_charset = utf8
database_charset = utf8
charset_normalization = Off

In this case, on the maintenance side, the Submission share starts to work.
Instead, if we change the config file to the default settings, the maintenance side site the Submission partition will be broken.

Can you please help us. I Wonder if there is way to set up locales only to the admin site but not in actual journal side?

  • tinde

Hi @tinde123,

Changing the config.inc.php file won’t change existing content in the database; to do that, you’ll need to transcode our database. It’s outside the scope of this forum – you might find some useful information on e.g. StackOverflow.com. Have a look at e.g. Fixing Double Encoded Characters in MySQL – trog's haus.

Regards,
Alec Smecher
Public Knowledge Project Team

I have had similar situation in one journal. Since they did not have too much articles I corrected that manually.
However, you must involve someone who is really skilled in database management and administration.