Export issues from 2.4.x to 3.3.x (Native XML?)

Software Support
21

Hi Jason,
point also taken regarding backups and playing with the DB.

I have recovered the database to an earlier save and tried importing from there.

I have several files that imported cleanly without any errors or problems. However there is a weird interaction that stops me from changing metadata later on:

In the issues I’ve imported, I would like to change metadata for the articles. e.g. correct spelling mistakes on Title and Subtitle, and add an abstract. (This is because the articles were created automatically from scans from ~150 year old journals, which aren’t perfect)

The way we would usually do this is:

  • Unpublish the Issue
  • Edit the issue and go to the articles Submissions from there
  • in the Submission go to “Publication” and edit Title, Subtitle, Abstract and other Metadata here.
  • Do this with all Submissions in the Issue
  • republish the Issue, leaving DOI etc. intact.

Now, when trying to change Title, Subtitle or Abstract in the “Title&Abstract” part in the “Publication” Tab in the Submission, I can’t save the changes I make as an error pops up:

"The form was not saved because 1 error(s) were encountered. Please correct these errors and try again. "

There is no error to be seen though, and I can’t correct anything. Is there some interaction in the background that I’m missing?

Thanks for bearing with me on this rabbithole of a bug hunt.
Karl.

22

Hi Karl,

When forms don’t save and there doesn’t appear to be anything wrong, the first thing I usually look at is whether or not I need to enable a locale for the journal. I’ve had situations in the past where content exported out of one journal was in a locale or more than one locale, and I needed to enable that new locale in the new installation so I could see that a field was empty or missing.

The other thing I would check is whether or not you need to enable other components in the workflow → metadata area of the journal settings. Some fields won’t appear at all unless they are enabled there. That’s probably not the culprit since I don’t think any of those are required but worth a shot.

Final thought: when you try to save, do you know if anything gets submitted at all (the Network tab in a web developer toolbar) or is the error being generated client side? The former could mean something getting logged in an error log, there might be a useful message there.

Best
Jason

23

Hi Jason,
thanks again for your answer.

  • locales: I checked the locales, they are setup the same in both journals. I tried activating a secondary language for “forms”, but it yielded the same results.

  • workflow components: I activated all of the metadata components, to try and see if anything trips the error there. These Metadata fields are listed in the “Metadata” part of the “Publication” Tab, and can be changed and saved. Only the fields in the “Title&Abstract” part pose a problem.

  • Network Tab: It seems data is submitted, as there is a post request, that is answered by a status 400. Now the error Message says there is no abstract submitted. I tried copypasting in a lot of lorem-ipsum to maybe overcome some minimum character count limitations, but to no avail:

{
	"prefix[de_DE]": "",
	"title[de_DE]": "Vorwort.",
	"subtitle[de_DE]": "",
	"abstract[de_DE]": "<p>Lorem+ipsum+dolor+sit+amet,+consetetur+sadipscing+elitr,+sed+diam+nonumy+eirmod+tempor+invidunt+ut+labore+et+dolore+magna+aliquyam+erat,+sed+diam+voluptua.+At+vero+eos+et+accusam+et+justo+duo+dolores+et+ea+rebum.+Stet+clita+kasd+gubergren,+no+sea+takimata+sanctus+est+Lorem+ipsum+dolor+sit+amet.+Lorem+ipsum+dolor+sit+amet,+consetetur+sadipscing+elitr,+sed+diam+nonumy+eirmod+tempor+invidunt+ut+labore+et+dolore+magna+aliquyam+erat,+sed+diam+voluptua.+At+vero+eos+et+accusam+et+justo+duo+dolores+et+ea+rebum.+Stet+clita+kasd+gubergren,+no+sea+takimata+sanctus+est+Lorem+ipsum+dolor+sit+amet.</p>"
}

The answer is:

{
	"abstract": {
		"": [
			"Geben Sie bitte ein Abstract Ihres Artikels ein."
		]
	}
}

Which is German for “please enter an abstract for your article”

I’m noticing the [de_DE] tags on the posted data. Could it be that the system expects a [en_US] or [en_GB] abstract, which I can’t enter through the form?

24

It certainly looks like there’s a missing locale. Maybe this submission is an outlier and the language the submission is in is different than the installed locales here. I’d probably turn on other locales and see what’s going on. Can you paste a screenshot of what the “languages” tab looks like in the Settings → Website area?

A 400 error is a “bad request”. That’s probably the OJS API doing that, and there might be a message in your server error log.

Best
Jason

25

I’ve controlled the input .xml and have found a pattern:
All the metadata is tagged with locale=“de_DE” while the submission_file and only the submission_file is tagged with locale=“en_US”
I haven’t changed the XML since exporting from another 3.3.0.6 installation, so it has to be a glitch while exporting, or even a problem inside the old installation.

I haven’t found an error message fitting the timestamp inside the errorlog. there was some talk of:

PHP Notice:  Undefined index: en_US in /var/www/ojs/lib/pkp/controllers/grid/settings/submissionChecklist/SubmissionChecklistGridHandler.inc.php on line 98, referer: http://..../management/settings/workflow

But at a time where I wasn’t trying around with the submissions.

26

Just so I understand, what locale should they be? de_DE?

Can you confirm if the locale is set correctly on the locale columns in the submissions and publications tables for those submissions? And perhaps on the publication_settings table for the submission in question.

27

Yes, the journal is in de_DE completely.

This is the languages tab:
grafik

I’m looking into the db to find the locales in the submission and publications tables.

28

I think I see the problem. It looks like English is installed and enabled but is not being used in the UI or interface. If you absolutely don’t need a locale, uninstall it. Essentially what this does is that it creates a situation where a locale is required but not available on the interface. That would almost certainly create the sort of problem you are seeing.

Best
Jason

29

Hello Jason,

sadly deactivating and uninstalling the locale did not fix the problem. Do I have to update the database in any way to change old locale settings etc. as well?

30

No, you shouldn’t, perhaps clear the data cache in the Administrator area?

The only other thing I can think of is that there are submissions or publications with either NULL or empty locale fields in the database.

31

Hey Karl,

Just revisiting this, because I have been doing some testing on my own. I’ve discovered that I get an error the same or similar to you if the locale field on the submissions table for the submission in question is null. Setting it to the primary locale for the journal allows me to save the form.

Best
Jason

32

Hello Jason,
sorry for the late answer and thank you very much for the testing.

I will check if I can get to the submissions table directly.

Cheers,
Karl.

Edit:
That seemed to do it!

update submissions set locale = "de_DE" where locale is NULL;

was sufficient. I’ll use this after importing, which should do the trick.

Something that was noticeable:
In the journal I was exporting from, there where no locales set to Null in the submissions table.
I didn’t find any locale = null in the xml, so I think this might be an import problem?

Thanks again!