Installing native import plugin or charset while updating from OJS 3.2.1.4 to OJS 3.3.0.7

Moin,
due to hacking attacks from Indonesia I want to update from OJS 3.2.1.4 to OJS 3.3.0.7.

I would prefer to export the articles and import them into a completely new installation, because then I can be sure that there is no backdoor lurking anywhere.

Unfortunately the export function (native xml) does not work and shows a blank page.
I can’t update it because the SharedHosting server says it won’t let me upload tar.gz. Directly overwriting the plugin files didn’t work either.

With the update it unfortunately smashes the umlauts (ü->ü ). The database old is on “latin1_swedish_ci” and if I install the update or copy the data into a new database then the umlauts are lost. :frowning:

I tried to install the plugin update on a specially set up XAMPP (Windows 10, XAMPP 7.4.1) but it was missing the tar extension. So unfortunately that didn’t work either.

Is there another trick to get the export function for articles and issues to work when you don’t have the option to upload tar.gz? Do the IDs of the articles remain during the export-import?

Thanks for the help and best regards
Frank J.

OJS 3.2.1-4 and OJS 3.3.0-7 are at the same patchlevel with regard to known security issues, but OJS 3.3.0-7 will include newer features, so upgrading is always encouraged.

Can you describe a bit more about the specific attack which has raised your concern?

If you have any concerns about the integrity of the original site, I would encourage you to redeploy the database and public and private files to a fresh download of the original version (3.2.1-4) first, whether in a new server, or in XAMPP. You should use antivirus software to scan the public and private files, being especially skeptical of any php files or server executable scripts in the public or private files directories. For extra measure, also search for common PHP injection attempts in the database, but this is an edge case.

The original internal ids of the articles will not be retained through an export/import process via the Native Import/Export plugin. Also, the original journal configuration and submission/review workflow for articles will not be retained. On the other hand, if your submission files themselves have been compromised, the Native Import/Export plugin will carry those files forward.

The question of character encoding is probably best as an independent thread. You can retain the latin1 encoding, or upgrade to a unicode encoding with some decent mysql skills.

1 Like

Hi,
yes, I installed it on a shared hosting service and when I did (in 2010 or so) there was no option to store the files folder, not in the public web user folder. That’s why we had problems, because someone uploaded php scripts and then uploaded 1000s of those in all the files folders. I hope I cleaned all of those and I moved the folder.

So I would love to update to 3.3.0.7 and keep our article numbers. So I have to figure out the character encoding somehow. Should I start a new thread for that?

Thank you for your help
Frank J.

There are a number of existing posts regarding database character encoding. If a search and review of these doesn’t solve your problem, a new post would be appropriate. Be sure to describe:

  • What the original / current character encoding is:
    • at the database level, and
    • within config.inc.php
  • Any changes which have been made to this over time
  • What you have tried and what you are seeing in the upgrade

Thank you. I solved it using: Converting mysql string data form latin1 to utf8 for utf8 data stored in utf8 tables via latin1 connection · GitHub
Now I just wonder if it is the new design or if something is missing:
Is the new navigation on the left in the backend just blue text on the background color?
Best
Frank J.

You can login to the Testdrive site to see what a typical install of the current version looks like:
https://pkp.sfu.ca/ojs/ojs_demo/