Article Numbers for OJS — from print-era page range to article number e0001

Scholarly publishing is quietly leaving the page behind.

For centuries an article’s address was its page range: pp. 245–260. That made sense when a journal was a physical object — paper had to be bound, and binding meant every article started somewhere and ended somewhere. But the page range was never really about the article. It was about the paper.

The paper is going away. Journals increasingly publish each article the moment it clears review — sometimes while later revisions are still in flight — rather than holding it for a quarterly issue. “Continuous publishing” is becoming the norm; the volume/issue/year container, itself a relic of print scheduling, is loosening and in some venues disappearing. Output is shifting from PDF (a print imitation) to native HTML. An article, in other words, is starting to behave much more like a web page than a page in a book.

When there is no issue to sit inside, “starts on page 245” stops meaning anything. What identifies the article instead is an article number (also called an elocation-id): PLoS ONE 15(4): e0231470, Electron. J. Combin. 27 (2020) P2.16, J. Vac. Sci. Technol. … 051101. The death of the page number isn’t a fashion. It’s the unavoidable consequence of the medium changing (paper to screen) and the rhythm changing (batched issues to continuous flow).

That is the gap this plugin was built for.

The problem in OJS today

Open Journal Systems has no dedicated field for an article number. So editors do the only thing they can: they type it into the Pages field. That single workaround quietly corrupts metadata everywhere downstream.

  • Google Scholar reads the value as both citation_firstpage and

citation_lastpage — a fake one-page range, and a broken bibliographic record.

  • Crossref expects the value in a dedicated <item_number>, not in

<pages>; a page-field value is deposited in the wrong place.

  • PMC / PubMed require either a first page or an <elocation-id>; a number

buried in page text can’t produce a valid one, and the deposit risks rejection.

  • Citation styles format article numbers specially — “Article e298”,

“Art. no. e298” — which a page-field value can never trigger.

PKP has known about this since 2019 (issue #4695). The core defined an internal property for it but left the export, citation, and editorial pieces unfinished. This plugin completes the chain — and does so in a way designed to hand back to core cleanly if core ever finishes it.

The Pages-field workaround breaks metadata everywhere
With no article-number field, editors put it in Pages — and the metadata breaks in four places at once.

What it does

A single generic plugin covers the article number end to end:

Where What happens
Editor An “Article Number” field on the publication form and in QuickSubmit. Uniqueness is enforced per journal; a published article’s number is locked so a deposited coordinate can’t change silently.
Reader The number is shown on the article page, in any theme.
Google Scholar The fake firstpage/lastpage pair is suppressed when a number is set.
Crossref <item_number item_number_type="article_number"> is injected and <pages> dropped; the output validates against Crossref’s schema.
JATS (PMC/SciELO) <fpage>/<lpage> is replaced with <elocation-id>, JATS4R-safe.
Citations Style-aware mapping across the ten bundled CSL styles — e.g. APA “Article e0001”.

The standards, mapped honestly

An article number is carried differently by every downstream system, and getting that mapping right is the work:

System Correct carrier
Crossref <publisher_item><item_number item_number_type="article_number"> — mutually exclusive with <pages>
JATS (PMC, SciELO) <elocation-id> — replaces <fpage>/<lpage>
PubMed / PMC first page or elocation-id must exist
Google Scholar (no tag) — so don’t emit a fake page range
CSL / citeproc the number variable
One article number mapped correctly to every standard
The plugin carries the same number into each system through its correct field — read-only against your data.

An engineering stance, not just a feature

We treated this as structural infrastructure, and made a few promises we don’t break:

It never touches your data. The plugin only ever writes its own value. It never writes to the Pages field or any other core field — that’s a hard architectural guarantee, independently verified, not a convention.

It never forks anything. Crossref, JATS, Scholar and citation output are amended by attaching to existing extension points — no export plugin, and no CSL style file, is ever copied or edited.

It’s opt-in, per journal. Off by default. When off, OJS behaves exactly as before.

It’s built to hand off to core. The value is stored under PKP’s own internal property name, workNumber. If a future OJS core ships the field natively, the plugin detects it, steps aside, and your data is already in the right place under the right name — a zero-migration hand-off. The plugin is designed to be always usable, or cleanly transferable. Either way, the journal’s data is safe.

Honest about the edges

Good tools are honest about what they don’t do. Two limits are worth stating plainly, because both come from the ecosystem, not from cutting corners.

Citation styles. Of the ten bundled styles, seven render the article number cleanly (ACM, ACS, APA, Chicago, Turabian, Vancouver — and MLA, after we fixed a double-printing bug). Three — ABNT, Harvard and IEEE — never expose the CSL number variable for journal articles and force a “p.” (page) label onto the value. The number is present and correct in those styles, but shown with a page label. Removing that would mean forking the bundled CSL files, which we don’t do.

RIS / BibTeX downloads. The article number is present and correct in both, but in a page field (RIS SP, BibTeX pages) rather than a canonical machine-readable one. Writing it to BibTeX’s eid would require forking a CSL file. For RIS we actually found a fork-free way to write the C7 (“article number”) tag — and chose not to ship it, because C7‘s round-trip isn’t guaranteed across reference managers, and an uncertain gain wasn’t worth a permanent maintenance burden. The canonical, standards-compliant path is already covered where it matters most: Crossref and JATS.

We’d rather tell you exactly where the line is than pretend there isn’t one.

Independently reviewed

Before release the plugin went through a full pre-release security and compatibility review: no Critical or High findings, clean on PHP 7.4 and 8.1, zero core-file changes, no export-plugin forks. The full test matrix ships with the plugin.

Moving your existing archive — safely

If your journal has been storing article numbers in the Pages field for years, there’s a migration tool — available both from the plugin’s settings panel (for one journal) and as a command-line tool (for large archives or every journal at once).

It’s a derivation, not a move. The tool reads the Pages value and copies it into the Article Number field; it never modifies Pages, in any mode. Genuine page ranges like 245–260 are never treated as candidates, ambiguous values are flagged for review, and an “undo” removes only what the tool itself created. Your source data is never at risk.

See it live

The same plugin, two very different themes — proof that display is theme-independent:

  • OJS default theme: [an issue where every article is identified by an

article number](https://ojs-services.com/ojsdemo/index.php/pub/issue/view/24) · example article

  • Atlas premium theme: [the same, in a premium

layout](https://themes.ojs-services.com/index.php/atlas/issue/view/83) · example article

Open the “How to Cite” box on any of them: the citation reads Article e0001, not a page range — and the article’s Crossref and JATS metadata carry it in the correct field.

Availability

The plugin is free and open source (GPL v3), targeting OJS 3.3 (PHP 7.4–8.1), with ports to 3.4 and 3.5 planned. It’s on GitHub at github.com/ojs-services/articleNumber.

↗ View the plugin on GitHub — github.com/ojs-services/articleNumber

If you’d like help deploying it — or migrating an existing archive of page-field article numbers — that’s what we do: OJS-Services.com.

Page numbers described where an article sat in a stack of paper. As that stack disappears, journals need a way to identify an article on its own terms. This plugin is a small, careful piece of that infrastructure — built read-only against core, mapped to the standards, honest about its edges, and ready to hand back to OJS core the day core is ready for it.

We didn’t want to follow where publishing is going. We wanted to build for it.

Categories:

Comments are closed

0
    0
    Your Cart
    Your cart is emptyReturn to Shop