[SOLVED] Native Export/Import not working?

[mbria]

Recently I wanted to export the full article issues&archive from OJS 2.3.7 to my production site (in OJS 2.3.6).

When I export looks like everything is going well, and the xml generated looks fine (with embed PDFs and so on) but when I import, OJS claims some basic fields are not included (for instance "DB Error: Column 'email' cannot be null") and the importation fails.

I other words, seams to me that at least 2.3.7 doesn't complains with 2.3.6 DTD, is it possible?
Then I DIFFed 2.3.6 and 2.3.7 DTD and they are exactly the same (the only change is in the copyright) so I

Then I took a look to the bugtrack and I only found a couple of issues not much related:
http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=6929
http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=6942

Does any body found a similar issue? Any idea about how to deal with it?

I'm surprised so the only idea that make sense to me it's an issue with the DB of the OJS source (2.3.7).
If the DB is not consistent and don't include (for instance) emails, OJS can not generate the exportation correctly
Does it make sense? I will contact the OJS sysadmin to take a look to the DB.

Cheers,
m.

[springday]

Hi m.,

probably there are e-mail addresses missing for at least some of your authors in your OJS 2.3.7. When exporting issues and articles, that is no problem. You will then just get some empty <email/>-elements in the exported XML file. However, the import process is checking and does not allow empty <email>-elements, that's where your error message comes from.
There are two possible solutions:
Option 1: Ensure that all your authors in OJS 2.3.7 have e-mail-addresses stored before you export the issues. You can either check in this in the metadata overview when you login as a journal editor or in your database table "authors".
Option 2 (this is actually the workaround that I'm using, too, for cases where I just don't know the author's email-address): In the XML file you can edit the <email/>-elements. Just write a dummy e-mail-address between the <email> </email> elements. You can do this with a single search & replace function in a text editor. I think a single normal space is not accepted by the import module. Usually therefore I am using the protected no-break-space character. So my import XML files for unknown author's email addresses look like this:

Code: Select all

<email>&#160;</email>

I think your problem has nothing to do with version issues, OJS 2.3.7 and OJS 2.3.6 should behave just the same - as do later versions of OJS (I'm working with 2.4.1 now).

Best wishes,
Kai Weber

[mbria]

Thanks springday for the fast and detailed answer.

The point is that my 2.3.7 exported XMLs don't include any email field.
I can add this by hand or with a sed/awk/perl magic but it didn't happen to me before.

I don't have much control over the source OJS (the one with 2.3.7) so I tried an import/export from my own 2.3.6 sites and it works like a charm.

Before following digging I will install a brand new 2.3.7 to see if the issue is related with the installation or with OJS.

BTW, you point two solutions but I curious about a third one:
What about touch the DTD to remove the email requirement?
Does it makes sense?

Cheers,
m.

[springday]

Hi m.,

I think changing the DTD wouldn't help. As far as I can tell (short look at the code of plugins\importexport\native\NativeImportDom.inc.php in my OJS 2.4.1) the XML file is not validated against the DTD during the import process. What might help though is something else:
You could turn off the constraint in the authors table of your database, which defines "email" as a data field that is not allowed to be NULL. If you change your database and allow those fields to be NULL, your import might be working even without the email addresses in the XML file. However, I have not tested this, and you should certainly always make a database backup before you fiddle around with it...

btw, sorry for misunderstanding your problem. To make sure I get it now: You have ensured that the authors table in the database of your 2.3.7 installation does contain the email addresses of authors, but they just don't come out in the XML, right? Then, that really looks like a bug to me. I'll try to have a look at the export code of 2.3.7 soon.

Best wishes,
Kai

[springday]

Hi again m.,

I've compared the code of NativeExportDom.inc.php of OJS 2.3.7 and OJS 2.4.1: Both are handling the export of the author's email address in the same way:

Code: Select all

XMLCustomWriter::createChildWithText($doc, $root, 'email', $author->getEmail(), false);

However, the last argument passed as "false" means: If - for whatever reason - there's no email address returned by $author->getEmail(), then don't create the email element. You could turn the "false" into "true" (you have access to the code on your 2.3.7 installation, right?) and then you would get empty <email/> elements in the export, instead of no <email>-elements at all. However, I don't think that would help you with the import, because your database would still demand author emails...

Best regards,
Kai

[mbria]

Kai, thanks a lot for the tip.

I don't have direct access to the source OJS (2.3.7) but I will negotiate.
Sounds like a perfect solution for me.

Just curious, wouldn't be better creating empty <email> tags?

Cheers,
Marc.

[asmecher]

Hi all,

Author emails are currently considered "required", so if you've got articles in your system without author emails, then you're running slightly out of spec. That's why you're seeing problems in the import/export process. We've received a number of requests to relax this requirement (e.g. for old content where author emails are unlikely), but haven't done it yet. In the meantime I'd recommend inserting a placeholder in the XML before importing, as Kai has suggested.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Hi Alec,

I didn't explain myself. I understand why I'm getting those errors and it's clear to me that it's not OJS fault.

My dubt is: Won't be better exporting with the old empty "<email></email>" xml tag (that could be easily seded/awked...) than with the new "no email" tag?

Both solutions accomplish with the "email required", isn't it?

Sorry for my primitive English and thanks for your help.

Cheers,
m.

[asmecher]

Hi Marc,

That makes sense to me (and your English is fine). I've committed the change at http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8009.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Thanks Alec.