We’ve just upgraded ojs2.4.7 to ojs3.2.1.1. The upgrade was difficult but finally resulted in the no-error code.
However, there is a big issue with character encoding. All special characters throughout the website are not displayed properly. We can return the characters by setting connection_charset=off but this action causes many other serious problems which make ojs not functional. Some of the problems include a blank page on article submission pages, the impossibility of processing the submitted articles, email templates do not load and so on.
Unfortunately, neither solution is good for us. I’ve seen there is some solution to manipulate the database but I am not able to find information in more details. Without it we are stuck and we cannot proceed.
I suspect the database you’re working with is not correctly configured for UTF-8, and the data may be double-encoded. Make sure your database is set up with a default character set of UTF-8 (see Multiple languages in ojs3.2 - #13 by asmecher) and that your data is properly loaded into it in UTF-8 format – you can use e.g. MySQLAdmin to check. Correcting this is more of a database administration task than an OJS task, so you might find some good general guidance on StackOverflow.com.
Try to keep things consistent – e.g. don’t start manually correcting characters unless you’re sure you want to do the whole thing that way. It’s a lot tougher to work with once encodings are mixed.
Regards,
Alec Smecher
Public Knowledge Project Team
But it is indeed strange. We performed a step-wise upgrade. We went from 2.4.7 over 2.4.8 to 3.1.2.4 and finally to 3.2.1.1. In all instances the database was properly configured with ut8-encoding. Only the upgrade from 3.1.2.4 to 3.2.1.1 resulted in the database problems. I suspect the upgrade 3.2.1.1. process does not work properly.
We settled to 3.1.2.4 version for now and will see later how to upgrade.
Hello, just to add that I have this issue also, after upgrading from 3.2.1-1 to 3.2.1-2. Our server’s character set is UTF-8. It appears to be an issue with this specific release, or with the upgrade process, unless there’s something I am missing.
in our case, it was a database problem which persisted through all installations. A database was apparently ok at lower versions but actually, it contained errors which became obvious at 3.2.1 version and which could not be easily solved. As Alec pointed out in his post it was a database administration problem which we solved at the end by hiring a professional who corrected the issue.
You might try to do it by yourself but if you are not familiar with the handling of the database it might take too much time.
Thank you @zmandic for your kind reply. I’m in the lucky position of having very little in my database, so I could also wipe it and recreate it from scratch if need be. And also, I can ask the dedicated IT team to take care of the database if need-be. Nevertheless, I wouldn’t know what sort of problems to look for, since there’s no apparent issue with it. Could you please tell me roughly what you did / what the issue was? From a superficial look there are no obvious issues with my database.
There was a character encoding problem. Since our installation was relatively old it looks like we had a mix of different encoding in the database. This brought unexpected problems in the operation and workflow of the website. It needed to be unified. However, I do not know more details since we hired a guy who did that.