OJS Updater released on GitHub

We proudly announce the release of the OJS Updater Tool on GitHub. It was created in a collaboration between the Specialised Information Service Biodiversity Research (BIOfid) and the Specialised Information Service Linguistics, both located at the University Library J. C. Senckenberg.

The tool allows a fast and easy upgrade of OJS journals to a newer version. While it normally takes about 20 to 30 minutes to upgrade a single journal, the OJS Updater reduces this time to only 2 to 3 minutes, without a necessary human intervention. Furthermore, it automatically backups the journal directory and database before the upgrade, so you can revert to a previous version of your data in case something might have gone wrong during the upgrade process. Last but not least, the OJS-Updater is a highly configurable tool, with several features that make the updating process quick and easy.

For a closer look see: GitHub - ubffm/ojs_updater.

10 Likes

Wow, that’s amazing @GrazingScientist! I’ll share this in our next developer newsletter, so hopefully you’ll get some feedback from there.

1 Like

Hi @GrazingScientist,

Your project looks really promising. Thanks a lot for sharing.

Some questions rise to me:

  • Is ojs_updater able to upgrade directly from 2.x to the last 3.3 version? (without an stop at 3.2 upgrade)
  • How did you test the application? Even with multilang journals? Any know issues?
  • Is the script upgrading config.inc.php? What values are asumed?
  • How do you deal with DB inconsistencies? Is the app able to apply common DB curations?
  • How did you manage to reduce the upgrade time from 20 to 2 minutes?
  • How do you show the upgrade errors? Are you tracking the original ojs ones?

I’m asking to evaluate if make sense to integrate your project in the docker-ojs project (if you are fine with this).

Thanks for your time,
m.

1 Like

Thank you, @NateWr . That would be great! :smiley:

@marc :

Is ojs_updater able to upgrade directly from 2.x to the last 3.3 version? (without an stop at 3.2 upgrade)

Yes and no! The updater can update your journal up to 3.3, but you have to make the recommended stops inbetween. In the end, the ojs_updater is only upgrading your journal to the latest version available to it (in the versions folder) and we did not want to put in any “intelligent” behaviour. The latter also because systems vary so vastly that this behaviour would probably break something most of the time.

How did you test the application? Even with multilang journals? Any know issues?

We tested the ojs_updater with both multi-language journals and single-language journals. The ojs_updater only replicates all the manual steps you would do when updating your journal. We use the ojs_updater for our production system and did not run into any issues yet.
However, this is also the downside of the ojs_updater. Although we tried to make the tool highly configurable, we do not know the server configurations of other people. There may be issues, we do not know (as it is always with software).
So, first thing you can do to make sure that everything works, is to run the tests of the ojs_updater (using pytest). Furthermore, we recommend to simply try it with a dummy journal that has comparable configurations to your production journals.

Is the script upgrading config.inc.php? What values are assumed?

No, the script only copies the config.inc.php from the old version to the new one. The ojs_updater does not touch your files at all (except for switching the installed attribute in your config.inc.php from on to off and back again after the upgrade). The ojs_updater leaves it to YOU to make sure that any (!) of your files are correct and compatible to the new version after the upgrade. This is because between OJS version so much stuff can change (I am thinking e.g. of the template version upgrade) that we would be very busy making the ojs_updater compatible to each new OJS version. We did not want this. The ojs_updater should just work with any foreseeable OJS version that has the same upgrade routine.

How do you deal with DB inconsistencies? Is the app able to apply common DB curations?

The ojs_updater does NOT check your database consistency or validity! It only makes a database dump. It assumes that your journal would not run with an inconsistent database. However, if OJS can handle the database inconsistency, the ojs_updater will (probably) work, because it does not touch the database. Hence, there is also no database curation in any way!

How did you manage to reduce the upgrade time from 20 to 2 minutes?

Perhaps it is only me, but when I manually upgrade my journals, I work very slow to make sure I make not mistakes. Make a backup of database and directory, create a new copy of the newest OJS version, copy over the public folder, copy over the config.inc.php, check that the permissions are set etc. . All these tiny things the ojs_updater does for you. It just walks along the OJS update “recipe” and puts in all the ingredients. After the OJS upgrade.php script ran, the ojs_updater is done.

How do you show the upgrade errors? Are you tracking the original ojs ones?

The on-screen logs of the ojs_updater are quite verbose (and that is only the INFO setting). Nearly every step has its own log. And yes, the OJS logs, when calling the upgrade.php, are also printed on screen.

When you integrate the ojs_updater in the docker-ojs, this would be really awesome! Please let us (either me or @thf ), when you need support.

2 Likes

Thanks a lot for your detailed answers @GrazingScientist

Some comments under your comments:

So… how it will work? I mean, if I like to upgrade from 2.4.8 to last stable (3.3.0-7) I will need (at least) a “pit stop” in 3.2.1-4 (or stable-3.2.1 if you like). If ojs_updater is “upgrading your journal to the latest version available”, does it means that I need to manually upgrade from 2.4 to 3.2 before running the script?

Adding an “upgrade path” sounds like a nice addition to the script. :wink:

Sure. It’s impossible to cover all the scenarios.
Nobody can ask for it… and this is where the community can help more: reporting issues.

Well… I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion and C-beams glitter in the dark near the Tannhäuser Gate. Some examples of errors here.

Based on my experience (partial and biased), the most common errors appear due to missing files or inconsistencies in the multilang data columns.

It’s not only you. I did the same to manage the upgrade of my journals (from 2.x to 3), but my bash script was so ugly to be shared. :slight_smile:
Again, thanks for sharing!

This is why I made all those questions… to to discover if really makes sense.

Please, help me thinking here: As far as I understand, ojs_updater will work great to automatice the upgrade process in host installations (backup all stuff > replace code with latest > set permissions > run the upgrade).

In the other hand, docker-ojs includes it’s own upgrade process (described here) that is also really simple…so, right now, I don’t see much benefit for docker users in adding ojs_updater to the docker image.

Do you agree? What do you think?

Adding an “upgrade path” sounds like a nice addition to the script.

Totally, agree! This was already implemented at one point, but was discarded again, because it was buggy. But it will be back, because we also see a lot of use cases for it. Thanks for confirming this! :slight_smile:

Based on my experience (partial and biased), the most common errors appear due to missing files or inconsistencies in the multilang data columns.

As I said, as long OJS can handle the errors, the ojs_updater does not care.

In the other hand, docker-ojs includes it’s own upgrade process (described here) that is also really simple…so, right now, I don’t see much benefit for docker users in adding ojs_updater to the docker image.

Do you agree? What do you think?

Currently, I think that the upgrade process with your approach is even easier (less configuration) than with the ojs_updater. :slight_smile:

1 Like

Probably you are right, but you need to install docker first and understand a little it’s logic.
While your script is easier to install and you don’t need a deamon.

I think, right now, both solutions cover different scenarios and this is good for the community.

But the docker-ojs project is not targeting the upgrade part, while your project has some room to grow in this sense (upgrade-path, db-curations, config wizard…), so I see benefits in mixing both projects in the near future.

Thanks a lot for sharing Ardian. I will be following you. :wink:

1 Like

@GrazingScientist it’s amazing I’ll share with my friends and get feedback from them.

2 Likes

Thanks @aricroy ! We appreciate any kind of constructive feedback! :smiley:

1 Like