1) Server migration
OJS needs to be offline to extract a dump from the database, copy files, etc. With a read-only mode, it could always be in the air, returning to its full functionality at the end of the migration.
Large OJS installs would benefit most from this feature.
2) OJS upgrades
The upgrade process is often time-consuming, and an OJS read-only mode would allow the public to continue viewing your journals.
3) Journal disabled
There is no more editorial flow and the writing mode just makes it less safe to keep the site up.
Perhaps it is interesting to think with this feature request:
I thought that there should be a way to do this already, but I can’t find a setting that sets the journal to read only.
Assuming I just didn’t look hard enough, I think you could effectively set a journal to read-only though by disabling new registrations:
Users → Users & Roles → User Registration - select “The journal manager will register all new accounts”
And then go to “Roles” and remove everyone’s submission privileges. This would disable new user registrations and new submissions, which would effectively make everything read-only.
But does OJS need to be offline to dump the database? I have used both mariabackup and mysqldump while the database is going. But then again, I am not running a large installation.
I thought that there should be a way to do this already, but I can’t find a setting that sets the journal to read only.
This option is not present in the OJS.
Assuming I just didn’t look hard enough, I think you could effectively set a journal to read-only though by disabling new registrations:
(…)
Removing the roles of all users and closing the records starts to become unviable in larger journals, or in installations with dozens of journals.
But does OJS need to be offline to dump the database? I have used both mariabackup and mysqldump while the database is going. But then again, I am not running a large installation.
To extract a dump for backup, for example, you can keep OJS running.
But if you need to migrate OJS to another server, or do an version upgrade, you need it to be read-only. Today, in fact, you need to make it totally unavailable.
What happens in these cases is that we cannot have a user registering, a review being made, an article submitted, etc. during this process, because if these data enter the database after the dump, they will be lost.
Hi… I upgraded ojs 3.1.1.four to the modern model 3.2.0. Suddenly the arabic text in TITLE, ABSTRACT and REFERENCE are missing and was query marks ??? assist please
As we have this mechanism implemented directly on the Web server, I didn’t get to test this plugin.
In any case, it just displays a message indicating that the OJS is under maintenance, while what is wanted is for readers to be able to continue reading the OJS content, without, however, having write permission.
Yep. I did the same, but would be nice to let readers keep reading… as far as the only information we will miss would be a few statistics (that you are also losing when you disable the full site).
But acording to Henrique’s description of the plugin, it’s implementing the feature as we request it.
I will try to find time to test it and come back with feedback.
Please, let me know if any of you test it before me.
For big version upgrades like from 3.2 to 3.4, we used a very expensive approach:
Remove all sessions from the database via the Administrator interface
Backup the users table.
Set all user accounts except the “admin” account to disabled with a message that we are undergoing maintenance.
Clone the database and files to a duplicate instance
Setup the instance (we use Apache2 site configuration for this) under a different port for example 8443 on the same domain
Upgrade the new instance to the desired version
Enable and setup all new plugins
Test the upgraded clone (BONUS: we can do a page by page comparison with the still running production version)
Selectively enable accounts for editorial teams to test
Wait for the OKAY from all involved people
Import the backed up user table data to restore the disabled state of the accounts
Switch the directories of the upgraded installation and old production installation via Webserver configuration
Notify all users, that the upgrade is finished and they can login again
Be happy and celebrate and brace for the storm of feedback depending on how well you communicated all the changes
This is a very expensive and time consuming process, but totally worth it for the readers so that the upgrade seems seamless from their viewpoint.
Very important is that all the involved people should be on board with this and be informed very early on to plan the publishing downtime.
This usually means one week of publishing stops and should be done during low output seasons.
Having a dedicated read-only-mode and upgrades running in the background would be very much welcome. But I see that its very involved and propably not worth the investment.
