Portico Plugin / wrong data in 'fpage' element

James_Rice · September 14, 2021, 11:49am

The problem
I installed the Portico plugin (OJS 3.2.1.4) and have done a test XML export. It works OK but for some reason it puts the article ID (not the page numbers) in the XML elements called “fpage” and “lpage”. This seems wrong, and Portico agreed it should be the page numbers in those elements.

what I did beforehand
We downgraded our server to PHP 7.3 (from PHP 7.4) in order to allow the plugin to work. I then just opened the plugin and selected an issue and generated the export.

what I did to try to fix it
I have not done anything to try to resolve this, as I do not know how. I reported the issue to our technical provider (who maintains the server) and to Portico, and they advised me to check with PKP.

Application Version: OJS 3.2.1.4

Additional information, such as screenshots and error log messages if applicable:
I can provide a screenshot of the XML but have not attached it here as when I tried that the post failed to upload properly so I am not attaching it this time.

Thank you for any help!

Best,

James Rice

asmecher · December 3, 2021, 11:47am

Hi all,

Here’s the relevant code in the Portico plugin:

github.com

pkp/portico/blob/main/PorticoExportDom.inc.php#L349

    
      
          			// simple pagination (eg. "pp. 3-8")
          			[, $fpage, $lpage] = $matches;
          		} elseif (PKPString::regexp_match_get('/(e[0-9]+)\s*-\s*(e[0-9]+)/i', $pages, $matches)) {
          			// e9 - e14, treated as page ranges
          			[, $fpage, $lpage] = $matches;
          		} elseif (PKPString::regexp_match_get('/(e[0-9]+)/i', $pages, $matches)) {
          			// single elocation-id (eg. "e12")
          			$fpage = $lpage = $matches[1];
          		} else {
          			// we need to insert something, so use the best ID possible
          			$fpage = $lpage = $article->getBestArticleId($this->_context);
          		}
          		$parentNode->appendChild($this->_document->createElement('fpage', $fpage));
          		$parentNode->appendChild($this->_document->createElement('lpage', $lpage));
          	}
          }

Essentially the article ID is used when a numeric page range couldn’t be identified; looking at the code, it says that something is necessary to provide, though I haven’t confirmed this in the XML schema. If your articles don’t have page ranges entered, then you can resolve this by entering some; if they are entered but the plugin is not using them, then make sure they follow one of the forms that OJS expects (there are 3 forms listed in the code linked above).

Thanks,
Alec Smecher
Public Knowledge Project Team

James_Rice · December 6, 2021, 10:33am

Hi Alec
Thank you very much for this. I did already have page ranges entered; and they were in the simple format 59–63; but, thanks to your help, I have worked out that the problem arises from what character is used between the numbers. 59–63 with an en-dash does not work, whereas the plugin exports those elements correctly if it’s typed 59-63 with a hyphen. We had entered all of our ranges with en-dashes, not hyphens, in line with normal usage for number ranges (cf. e.g. Use a Dash for Number Ranges, though I note AP style does recommend hyphens whereas Chicago Manual does not). Anyway, it seems we got to the bottom of it and we can just use hyphens for our page ranges in OJS to circumvent the problem.
As this may be a pitfall for other users as well, I wonder if the plugin could someday be updated to tolerate en-dashes in page ranges, as well as hyphens?
Thank you for your help!
Best,
James Rice
WHP

asmecher · December 8, 2021, 12:00am

Hi @James_Rice,

This change should add support for en-dashes in page ranges:

I have added the equivalent change for other areas using page ranges, e.g. DOI exports:

Regards,
Alec Smecher
Public Knowledge Project Team

James_Rice · December 8, 2021, 11:09am

Thank you very much!

asmecher · December 20, 2021, 8:00am

This topic was automatically closed after 12 days. New replies are no longer allowed.