I have a strange problem with our OJS system. I am working on migrating our OJS data to a new server, including two journals. The .xml export plugin worked fine for one journal, but not the other. At first I thought it was a size issue, but it persisted after we had increased our limit to 100MB (to exceed the existing journal size). This is the error:
The only reason I can think of that the export would work for one journal and not the other is if there was some setting or background metadata that was giving it trouble. Whatever the cause, the .xml files the plugin outputs are very slow to open even in a text editor, and fail to upload. Here is a sample of the file when it did finally load in Notepad:
Has anyone seen similar issues before? Our current site is at http://journals.wsulibraries.org
We are trying to migrate from 2.4.6.0 to 2.4.8.0, but that doesn’t seem to be the issue since it worked for one of our journals. Any guidance would be appreciated!
Can you describe your migration? Are you changing servers, or changing OJS versions, or trying to bring content from one OJS installation into another that already has journals in it? Unless you’re in the last situation, the XML import/export tools might not be the best solution.
The export files can be quite large (hence Notepad choking on it, and uploading to OJS taking quite a while). One work-around that might be useful is to export only a few issues at a time, rather than all your content. There are several configuration directives in your web server and PHP configuration that might prevent large uploads; the FAQ mentions a few.
Regards,
Alec Smecher
Public Knowledge Project Team
Some of your PDFs seem to be huge, at least the one of the article 162. Maybe you could check the size of your PDFs and try to decrease it for those huge ones? – this way they are also slower to load for the reader. Else, maybe to export/import article-by-article…
Thanks for getting back to me so quickly. We are changing servers and minor OJS versions at the same time (2.4.6.0 to 2.4.8.0). So far, the content would be identical; there were no journals on the new server until I began importing. What might be a better solution? Should we clone the database? I was afraid that them being different versions might cause issues with that.
Regarding the size of the export files, I have tried exporting single issues and even single articles. The article “Bloodied Kansas” from Volume 7 outputs an xml file that is over 800,000 characters long – the vast majority of which is in the tag. The PDF itself is only 43,000 characters! I suspect there is something wrong with the way we got our PDFs embedded. We used the quick submit plugin in our initial setup, in case that helps.
I appreciate your advice! I will take a look at the configuration directives mentioned in the FAQ.
A better solution would be to clone the database, copy the contents of the files (per files_dir in your config.inc.php) and public directories, then run the upgrade script to bring your database up to the new version. The import/export tools don’t capture a lot of important things, such as peer reviews and editorial workflow.
Regards,
Alec Smecher
Public Knowledge Project Team
