During the last years some journals arrive to our OJS from other OJS installations. Sometimes applications are in the same version, but when we try to import/export an external ojs journal to/from our service the process fails because configurations are different.
For instance, if your destination lang configuration (enabled langs, defaults), and sections are different, importation fails and you need to import issue by issue, setting configuration to avoid errors, etc.
It’s a tricky situation because journal’s settings could change during the journal live (adding sections, adding journals…), so in the real world, full journal native import/export between OJS is not possible and most of the times we finish importing with QuickSubmit.
I was thinking in a plugin to import/export journal settings, but it won’t help much.
Did you ever fall in the same hole? What did you do when you import/export between OJSs?
I was expecting ojs to work as you suggest but looks like it requires identical sections (not only abbreviation) and when you add different langs the scenario is more complex because some times title translations don’t fit…
I’m also unsure about why we translate abbreviations. If we do that, we will need another field to be the section uniqueID.
This was because previously, issue errors were described as being ignored. Based on this code, I would not have expected a failed import based on partial section matches. If it still does cause an error based on section mismatches, please post the error messages here.
Sorry a lot @ctgraham, but not till the end of the year or so.
I’m not ringing the bell and running like hell here… it’s just I’m in the middle of the server reinstallation (probably moving to docker, btw) and other urgent stuff and I’m kind of overcome.
If no one else can send feedback about this, I promise I’ll be back to this post as soon as I can.