What Citeable does: today, and next.

The journal opens to a home built for editors, not WordPress. A shared Tasks inbox lists each waiting submission as its own item — a new paper, a returned review with its recommendation, an overdue reviewer, a piece ready for an issue — each with the one action it needs; the same inbox greets you on the main dashboard. The page itself is rearrangeable panels you drag, collapse or hide — the forthcoming issue taking shape, outcomes, turnaround times and a readership summary — and WordPress remembers each editor’s layout.

See the editor’s overview →

Because Citeable runs on WordPress, the journal’s whole appearance is a theme — change the look without touching the content, the workflow or the indexing. The same EJLE front page is shown here in three completely different themes; the whole WordPress design ecosystem, and the designers who already know it, is open to you — where OJS gives you one look and a specialist job to change it.

See one journal in three themes →

Volumes, issues and articles are first-class content types. Articles carry structured authors — affiliation, ORCID, corresponding-author — alongside pages, DOI, licence and an access level. Issues have covers and a configurable article order.

Authors submit in Word or PDF, and the file is served back in its real format throughout — reviewers download a Word document as Word, open a PDF inline. Editors can replace the manuscript file on the card to anonymise it before review.

Articles emit Google Scholar metadata, expose an OAI-PMH endpoint for harvesters and libraries, and can deposit CrossRef DOIs (dormant until the journal holds a prefix and membership). Readers get one-click citation export in BibTeX, RIS and OSCOLA.

Each article carries an access level — open, or restricted to a tier the journal names (members, subscribers). The restriction maps onto a capability rather than a hard-coded role, so it fits whatever a site already uses for membership.

Issue and article layouts are built on WordPress's block editor, so the design stays the journal's own and editors can adjust it without touching code. Classic PHP templates are kept as a fallback for non-block themes.

Every article has an expandable in-browser PDF reader beside its download, and an issue's whole-issue, contents and editorial documents each open as a readable page of their own rather than a forced download.

An issue can sit as forthcoming while early articles go live as advance access — Online First — then publishing the whole issue is a single action that stamps the date and makes it the current issue at once.

When a paper is accepted, the author can prove it straight away. On a forthcoming issue each article is held, listed as an accepted-in-production placeholder — title and authors, on the public issue page, no full text — or already live as advance access. That listing is an authoritative record an author can cite at promotion or grant time, something OJS doesn't really offer, and it stays out of OAI, Scholar and CrossRef until the article is genuinely live. And “published” now means published: the author's notice fires when the article actually goes live, not the day it was accepted.

See the forthcoming issue page →

Every article carries a copy-ready citation with BibTeX and RIS download and Google Scholar tags, and a Creative Commons licence shows as proper CC marks plus its label, linked to the deed.

Link an author to their account by email or ORCID — a manager confirms each suggested match, nothing is merged automatically — and their work gathers under it. Each paper keeps the affiliation it carried at the time, so a person’s history reads straight off their publications; the public author page shows their current affiliation and each article’s as-published one together.

On the submission form and on profiles, entering a university email suggests the author’s affiliation — and, where there’s a country field, their country — filling it only when it’s empty, always editable. The list is fetched and cached on the site rather than shipped in the plugin, with a manual upload for hosts that block outbound connections.

Build the masthead on a drag-and-drop team screen: drop role chips onto people, set each shown-as title and whether it’s public, and reorder by dragging. Roles are yours to define — editor-in-chief, journal manager, section editor and more — and each member fills their own profile (photo, affiliation, country with flag, biography, ORCID). A public board block then lists the team by role, naming the editor-in-chief for DOAJ. See it →

Create a special issue from the Issues screen and appoint guest editors, who each get a self-contained, walled-off account that runs only their issue — a bespoke submission link, their own queue and scoped review. The journal’s own editors see everything, clearly tagged as the special issue.

See the special-issue workflow →

A capability system that maps onto a site's existing roles, with optional Citeable-owned roles, so it works on any WordPress install. You define each role and exactly what it can do, and can grant or deny one person's permissions on top of their role. Non-destructive by design: nothing strands a user or overwrites a role.

An Import screen in the admin takes a CSV of article metadata with their PDFs — back catalogue included — with a downloadable template so a bulk upload starts from a known-good file.

Gentle nudges to reviewers as deadlines approach, and — with no account — a private link where an author follows their submission's progress, plus a signed-in dashboard listing all their papers and the stage each has reached.

Articles readable as HTML, not only PDF — and, while reading, a panel that surfaces just the footnotes whose markers are on screen, updating as you scroll. It adapts to the window: margin sidenotes when it's wide, a slim panel when it's tall, plain endnotes when space is short, with a reader's-choice toggle.

Try the reader prototype →

Bring an existing journal’s read and download history across from OJS or COUNTER reports.

Reader-facing pages that gather a journal’s work by topic, across every issue, so a reader can follow a subject and not just an issue. The editorial side already tags articles by subject area; this turns that into pages readers can browse.

A complete export of a journal’s content and metadata, so a journal is never locked in: it can be moved, backed up or handed on entirely on its own terms.

Images and equations carried into the in-browser reader, building on the HTML reading version that already sits beside the canonical PDF.

Authors signing in with ORCID so an iD is confirmed as genuinely theirs, rather than typed in. Profiles already carry ORCID iDs; this authenticates them — and turns the hollow iD solid.

When an editor asks for changes, the author revises and resubmits through the journal rather than over email, and the paper carries on from where it was.

A simple stage between acceptance and publication to prepare the final version — kept deliberately small for arts, humanities and social-science journals, not a full typesetting pipeline.

A recommendation plus the specific questions a journal wants its reviewers to answer, rather than one fixed form.

WordPress’ own search is generic; a journal wants something that knows its own shape — across articles, issues, authors, keywords and subject areas, with filters for year, subject, type and access. The open questions are appetite and form: how much do readers search rather than browse by issue? Are faceted filters worth it, or is a clean single box enough? And how much should lean on an existing search plugin versus something journal-aware built in?

Running several journals from a single installation. Citeable is built one-journal-to-a-site by design; whether a multi-journal “press” mode is worth doing is an open question, and I’d value views on it.