XML native import/export fails on journals with different configurations

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?

@marc, can you describe an example where the export and import behaves unexpectedly?

I would have expected the import to:

  1. Match an XML section tag to any existing OJS section by title or abbreviation.
  2. If no matching section is found, create a new section from the XML

Are you seeing failures where unwanted sections are created, or where sections are incorrectly matched?

1 Like

This is usually the main issue.

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.

The translation of the section abbreviation also surprises me. Is it exposed somewhere human-readable in the public interface?

Can you retry an import with the master codebase to see if it still aborts the import? I converted each of the $deployment->addError() calls to $deployment->addWarning() calls in a recent PR.

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. :rolling_eyes:

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. :frowning:

If no one else can send feedback about this, I promise I’ll be back to this post as soon as I can.

Thanks again for all your work Clinton.