Coverage Metadata 2.x-3.x migration

In our prior (original) 2.4.x install of OJS, Journal Setup->Submissions-> 3.4 For Authors to Index Their Work provided three entry boxes for “Coverage” metadata:

Provide examples of relevant geo-spatial or geographical terms for this field:
Please indicate any geographical areas that are relevant to, or described or depicted in the submission, e.g., Philadelphia, Pennsylvania; Onondaga County, New York.
(E.g., Iberian Peninsula; Stratosphere; Boreal Forest; etc.)

Provide examples of relevant chronological or historical terms for this field:
Please indicate any dates, eras, or other chronological periods relevant to the submission, e.g., 1970s; 21st century; 2007.
(E.g., European Renaissance; Jurassic Period; Third Trimester; etc.)

Provide examples of research sample characteristics for this field:

In our testing 3.1.2 install, on the Settings->Workflow->Submission page, one can activate only “Coverage.” Data from our prior (multiple) coverage fields did not successfully migrate into the single coverage field in 3.1.2.

This is very important for us not only for indexing, to have the past data properly migrated, but we drive visualizations of journal content off of chronological and geographical coverage independently, and need to have access to these prior coverage fields.

Has anyone else encountered this, and/or what might our solution path be?

Hi @blonsway,

Have a look at – that reviews the discussion and motivation that led to the changes between the OJS 2.x and 3.x Coverage fields.

Alec Smecher
Public Knowledge Project Team

Thanks for the link.

Drat, I wish I were there in Feb 2016! I would have argued against consolidating the two coverage fields…but not only because our front end data-viz/search relies on them being distinct.

From a data architecture standpoint, spatial and chronological data (not to mention the third (sample characteristics) field that was once present in 2.x) is taxonomically very distinct: I can’t format geospatial data using chronological data formatting and vice versa; each has native structures for search (on a map, for example, or on a calendar); and their value as metadata is autonomous (I may care about things from the 20th century, regardless of whether they reference the US; I may want to identify things from the 20th century specifically about the US; or I may want to identify things about the US from any time). It is a real information loss to have these distinct fields merged.

As I mentioned, a central part of our journal’s interface is a data visualization where one can filter by chrono or geo coverage, so this is a drastic loss for us.

I guess what I care most about is what happened to the data in the db that was originally in the chronological and geo-spatial coverage fields. It isn’t displayed in our OJS dashboard in 3.x after upgrade. Is is still in the db somewhere? If it is, we can extract it with a REST API extension (which is how we populate the viz).

Hi, I know some time has expired, but could you share some info on what happened to the data that was in those fields during the 2.x to 3.x migration? Our IT team has reported that it didn’t come across into the new single “Coverage” field.

Hi; our IT staff dug into the db, and found the data in the submissions_settings table. For anything created in 2.x, it made it through the migration.

I now have two questions:

  1. @NateWr, can we grab this data via the REST API?
  2. What would it take to add these two fields back into the interface so we can continue to use them going forward?


Hi @blonsway,

The data won’t be provided through the REST API by default, which means you’ll need to write some code to get it out of the database and into the REST API. This should be do-able and easier to do than writing your own API code as you’ve done in the past – which should make maintenance of this work easier over the long-term.

What does your timeline look like for having this running and working on a live site? I ask because we expect to release v3.2 in January and there are some significant changes coming in how you would solve this problem.

The good news is that v3.2 is introducing a more extensible data model for submission data that should make it much easier to extend the data attached to a submission and add input fields to the forms where this data needs to be entered.

The bad news is that if you can’t wait until January, you’ll probably need to do this work once now and again when you’re ready to upgrade to 3.2. :sob:

If you let me know what your timeline looks like, I can provide some guidance for your IT staff.

Hi, @NateWr,

So, slowly but surely we’re getting back into a number of issues that we’ve had on the back-burner…thank you for your prompt reply, and apologies for the delayed one on our end!

At any rate, our timeline for this issue is extended, but we would still like to incorporate it. I see that 3.2 is not yet out, but if things are changing for this, it would be best to build what we’re doing around 3.2 What do you expect that release’s timeline to look like?

We’re now aiming for end of February and I’m cautiously optimistic that we will hit it. The current master branch of the OJS repository is pretty stable and going through testing now. I think your IT folks could start working from that now with minimal disruption.

As I understand your needs, here are the things that will need to happen to retain your coverage data and add fields for OJS 3.2 to add/edit this data.

  1. Create a test instance of your site and upgrade it to 3.2 using the master branch of OJS.
  2. You’ll need to migrate the coverage data from submission_settings to a new publication_settings table. A publication is connected to a submission through the publication’s submission_id column. So if your coverage data has a setting_name of geoSpatial in the submission_settings table, you should move the row over to publication_settings and use the same setting_name.
  3. You’ll need to extend the publication schema to add the new setting:
HookRegistry::register('Schema::get::publication', function($hookName, $schema) {
	// Instead of geoSpatial, use whatever the setting name is
	$schema->properties->geoSpatial = json_decode(
			"type": "string",
			"apiSummary": true,
			"validation": [
  1. You’ll need to extend the metadata form to include your new setting.
HookRegistry::register('Form::config::before', function($hookName, $form) {

	// Add a field for your setting. Instead of geoSpatial, use whatever
	// the setting name is.
	$form->addField(new \PKP\components\forms\FieldText(
			'label' => __('your.field.label.locale.key'),
			'description' => __('your.field.description.locale.key'),
			'value' => $publication->getData('geoSpatial'),

You can see an example plugin which does something similar for the context (journal) here: GitHub - NateWr/institutionalHome: An example OJS plugin demonstrating how to extend a schema and form.

And you can learn more about plugins from our plugin guide.

Thank you! This seems pretty straightforward in the end; we greatly appreciate the guidance!