OJS Journal Migration

Exporting journals from OJS: tips and a pitfall

OJS offers various approaches for export; database dump and zip of config files, otherwise known as the direct and brutal approach, or an XML export approach.

Checklist for an OJS move

Step 1. How old is it?
Step 2. How different will the new install be?
Step 3. Is it worth upgrading it or should we do that after migration?
Step 4. Do we have an existing OJS install to add this journal to?
Step 5. Ought we to put in the effort to sort out DB clashes (historically OJS uses not very unique IDs internally, so the first journal on any system will have largely the same IDs).
Step 6. Either yes: which opens you up to some DB wrangling or no: which means you can just get on with it, calling this database the sole DB of your OJS install.
Step 7. Install. Say to yourself: “Great, it might work! I will test it using etc/hosts or windows equivalent to sidestep the need to update DNS before checking” – you need to do this because you almost certainly have it set up as one of several virtualhosts, so it won’t answer the phone until you request the right hostname from that server.
Step 8. It works? Say to yourself: “Great, it works. Now, what am I doing with DNS? Is there a safe, stable place for me to host that?”
Step 9. OK. Now let’s move DNS. Stay attentive for problems, bug reports.
Step 10. Now, is the new ownership slash management correctly identified on the site? Who knows who to contact when it breaks?

Important tip

As with any migration process, if you’re not sure whether you’re looking at the right copy of the website – yes, it sounds silly, but it happens all the time: web browsers cache, DNS caches, host files fail – then check at each stage. Using wget to download the page or typing ‘nslookup thedomaininquestion.com’ will tell you where you’re really retrieving the page.

And a pitfall

Those looking to export larger journals from OJS may fall over the memory limit in their PHP configuration. The exportIssues method seems to eat a lot of memory, resulting in most cases in PHP returning a blank page.

To find out whether this blank page is a result of running out of memory add this to the top of your OJS main index.php file:

ini_set ('display_errors', E_ALL);

This tells PHP to display all errors rather than suppressing error output (which would be more usual on a production server). Run the export again. You may well see PHP’s ‘fatal error, allowed memory size exhausted’ error. This results in a blank screen if your install has display_errors switched off.

Fortunately it’s very easy to resolve. You can fix this just by sticking a larger memory allocation in at the top of OJS’s main index.php file, as in:


//ini_set ('display_errors', E_ALL); // (good for debugging)
ini_set("memory_limit", "64M"); // set higher memory limit
/**
* @mainpage OJS API Reference

* etc.

In fact 64M wasn’t big enough by some distance for the relatively large journal we were hoping to export – 640M did the job in our case.

Leave a Reply

Your email address will not be published. Required fields are marked *

*