Moving to new VPS AND OJS 3.x

Looking for some system admin advice.
We need to move to a new VPS as they are going to retire the old server running that VPS. We also want to upgrade to OJS 3.x.

So the questions are:

  1. Should we move to a new VPS and install 3.x on that and then run a migration?
  2. Should we move to the new VPS and copy over the 2.4.x install? Then run a 3.x upgrade?
  3. Some other method?

I also assume that any upgrade to 3.x will mean that all the article links will change. Is that true? e.g. will change?

Thank you!

Hi @radjr,

I would recommend taking a copy of your 2.x files and database from the old server, putting them on the new server along with the 3.x code, and running the upgrade on the new server. That way you will simultaneously migrate servers and move to the new code. Your old server will remain a backup.

It’s up to you whether the links change or not – I would recommend against doing anything that changes the links, but I would also have recommended against having the OJS version number in your URL.

Alec Smecher
Public Knowledge Project Team

Alec, It seems to me that as long as we re-post all DOI/Crossref data to Crossref, our DOI links should point to the new path without an OJS version reference. Is that correct? Can we force 3.x to re-submit Crossref data or do we need to export the file and use the crossref upload too on their servers? Thanks!

Hi @radjr,

I’m not sure about the Crossref question specifically – @AhemNason might be able to answer – but if I were doing this, I’d look into Apache’s Redirect directive (e.g. mod_alias - Apache HTTP Server Version 2.4), or whatever equivalent is available for your web server. Make your new URLs “clean”, and redirect to them from the old URLs. Most crawlers etc. will take the hint and replace the old URLs with the new ones in their knowledge bases, and readers will not lose access to content at the old links.

Alec Smecher
Public Knowledge Project Team

Hey there @radjr,

If you change any URLs you will absolutely need to update the metadata with Crossref or your DOIs will no longer resolve. How you do the update is really up to you. If you’re moving to OJS 3.1.2, you’ll find that the Crossref plugin included is quite good. You don’t need to export manually and update via You can just update your DOIs using the plugin, assuming it’s properly configured.

Additionally, if you set the plugin up to automatically mint and register DOIs, you won’t have to really think much about your DOIs moving forward.

Mike Nason
PKP|PS & UNB Libraries

Alec, seems that OJS 2x and 3.x need two different versions of PHP. 2.x needs PHP 5.x and ojs 3.x needs php 7.x. Many providers do not like running both versions.

Will OJS 2.x run on php 7.x?

Thanks! radjr

The latest release of OJS 2.4.8-5 should support PHP 7.

Thanks Clinton! That makes it easier!

Is there a better way to restore from an active old server to a new server then this?

I did the OJS install of on the new server. Is there no restore selection in the journal manager’s section of OJS?


The built-in import/export tools (articles/issues, users) within OJS will not migrate everything. There is a plugin fullJournalTransfer which comes closer, but still can’t cover everything.

Copying the OJS data files, OJS database, and OJS source code (as described in the link to the user guide) is the only way to migrate everything. Do you have any specific questions with the process?

Thanks Clinton. Does this imply that the backup utility in OJS does NOT backup all the required files for a complete backup as listed in the administrative functions menu?

We do want to move from /var/www/vhosts/ to /var/www/html/ojs
I am a bit unclear as to how to move that.

And we are upgrading to from

It is also unclear from Alec’s suggestion above how OJS2.x and OJS3.x can live in the same folder.


What “backup utility in OJS” are you using? I’m not aware of anything built in for OJS 2.x, but I might be missing something.

I think Alex was describing copying the OJS 2.x files from the old server to the new server, and then upgrading the new server to OJS 3.x. I don’t think he was describing having OJS2 and OJS3 live in the same folder.

If you really wanted to, you could have an OJS 2.4.8-5 and an OJS 3.1.x install on the same server. Presumably this would be for testing. To have OJS2 and OJS3 live side-by-side, you would have two copies of each of:

  • the OJS source code
  • the OJS private files
  • the OJS database

This might look like:

/var/www/html/ojs (ojs 3.x source files)
   with files_dir pointing to "/var/www/ojs-data"
   and database name pointing to "ojs"
/var/www/ojs-data (ojs 3.x data files)
/var/www/html/ojs2 (ojs 2.x source files)
   with files_dir pointing to "/var/www/ojs2-files"
   and database name pointing to "ojs2"

If you just want to move OJS 2.4.8-1 to OJS 2.4.8-5 on a new server, what you would do is:

  • Install OJS 2.4.8-5 source code in /var/www/html/ojs .
  • Copy the old files_dir from the old server to the new server (probably /var/www/ojs-data)
  • Copy the public files from the old server (/var/www/vhosts/ to the new server (/var/www/html/ojs/public/)
  • Reinstall any non-standard plugins on the old server (/var/www/vhosts/ within the new server (/var/www/html/ojs/plugins/)
  • Copy the settings from your old into your new Note that any setting which references server paths will possibly change. Certainly files_dir, probably others in the [search] and [cli] sections. If changing hosting providers and using SMTP, these settings will also change.
  • Export or backup the old database to a file, and then import it to the new server. This may require adding a new database user on the new server, and changing settings in
  • Double check all file permissions for your new host.
  • Run the tools/upgrade.php upgrade command (or run the upgrade in the browser).

Thanks I will read it completely in a second. The Backup utility is in the Site Administration
Home > Site > Site Administration under the Administrative Functions list. The last option is “Download Backup” and it lets you download the Database, Files and Code.

Looks like the documentation on this page has an errror:

tar czf /root/ojs-files.tar.gz

should be

tar czf /root/ojs-files.tar.gz *

Interesting enough, the virgin site I just installed does NOT have a backup option!

I think the restore link in
is wrong for mariaDC and should be GRANT ALL PRIVILEGES ON database_name.* TO ‘username’@‘localhost’;

Clinton, it seems that there are some other paths that are embedded either in the database or somewhere else. For example http://x.x.x.x/ojs-2.4.2/index.php/jem/issue/view/283 is embedded in the block plugin.

Also, all the journals come up on this site except which is particularly odd.

Thoughts? thanks!

Debugged it to a dead plugin. How do I kill the plugin so the site will work?

Fatal error : Uncaught Error: Call to undefined function eregi() in /var/www/html/ojs/plugins/generic/roundedCorners/ Stack trace: #0 /var/www/html/ojs/plugins/generic/roundedCorners/ RoundedCornersPlugin::_getDivs(’<div class="blo…’, ‘block’) #1 /var/www/html/ojs/lib/pkp/lib/smarty/Smarty.class.php(1276): RoundedCornersPlugin::roundOutputFilter(’<div class="blo…’, Object(TemplateManager)) #2 /var/www/html/ojs/lib/pkp/classes/template/ Smarty->fetch(‘file:/var/www/h…’, NULL, NULL, false) #3 /var/www/html/ojs/lib/pkp/classes/plugins/ PKPTemplateManager->fetch(‘file:/var/www/h…’) #4 /var/www/html/ojs/plugins/blocks/subscription/ BlockPlugin->getContents(Object(TemplateManager), Object(Request)) #5 /var/www/html/ojs/lib/pkp/classes/plugins/ SubscriptionBlockPlugin->getContents(Object(TemplateManager), Object(Request)) #6 /var/www/html/ojs/ in /var/www/html/ojs/plugins/generic/roundedCorners/ on line 86

Well, I found the plugsin table and disabled the rounded corners plugin. Is this broken in 2.4.8-5?


This is actually a function of the Backup Plugin in the Generic category. I wasn’t familiar with this previously. It does appear to make a full system backup.

Yes, tar czf /root/ojs-files.tar.gz * or tar czf /root/ojs-files.tar.gz . would work.

Both mysql documentation and mariadb documentation seem to indicate that the “PRIVILEGES” keyword is optional, but your formulation is correct.

Yes, anywhere that an external link references the full URL to you site will need to be updated if the base_url changes. An “internal” link (such as one embedded in a custom block) is really effectively an external link, if an absolute URL is used instead of a relative URL. It is generally best if relative URLs are used when possible, as this allows for easier restructuring of the site.

The PHP function eregi was removed in PHP7. This plugin will not be able to be used in PHP7 without a change to the code to use a different regex replacement function.