A practical guide for journal editors navigating the format transition in scholarly publishing

Over the past year, our team at FullTextCreator has been building a system that converts academic article PDFs and Word documents into full-text HTML and JATS XML. We built it because the demand was there — and it keeps growing.

Journals want to publish in multiple formats. Indexing databases increasingly require structured content. Authors expect their work to be discoverable, readable, and citable across platforms. And yet, when we process hundreds of articles from dozens of journals, we keep seeing the same reality: most academic content is still locked inside PDFs designed for a printer that doesn’t exist anymore.

This post is about why that matters — and what to do about it.

If you’re looking for practical guidelines on how to prepare a well-structured academic PDF, we’ve already written a detailed guide on creating machine-readable academic PDFs. Consider that a companion piece to this one.

PDF: A Tool Designed for Print

The PDF format was created in the early 1990s to solve a very specific problem: how do you ensure a document looks exactly the same on every screen and every printer, regardless of operating system or software? The answer was to freeze the layout — to treat the page like a photograph.

For print publishing, this was revolutionary. For digital-first academic publishing, it’s increasingly a limitation.

A PDF is a visual container. It knows where every word is on the page. It does not know that a bold centered line is a section heading, that a superscript number is a citation, or that a block of indented text is an abstract. Machines can see a PDF, but they cannot easily understand it.

This matters more than ever. The academic ecosystem now includes:

• Search engines that need to parse and rank your content
• Indexing databases (PubMed, Scopus, Web of Science) that need to extract metadata
• AI-powered research tools (Semantic Scholar, ResearchRabbit, Perplexity, Elicit) that need to read and summarize full text
• Reference managers (Zotero, Mendeley) that need to extract citations
• Accessibility tools that need to serve content to readers with visual impairments
• Translation pipelines that need clean, structured text

PDF can serve some of these purposes — but only if the PDF itself is carefully structured. In most cases, it serves none of them particularly well.

We Are in a Transition Period

Let’s be honest: PDFs are not going away. And for good reasons.

Many indexing requirements still mandate a PDF full-text submission. TR Dizin, for example, requires a PDF. Several EBSCO and DOAJ policies are built around PDF availability. Authors are accustomed to downloading and sharing PDFs. Peer reviewers expect them. Citation managers import them. Institutions archive them.

More importantly: the habits of a generation of academics are built around the PDF paradigm. You cannot simply replace it overnight, even if you wanted to.

What we are seeing — across PKP’s Open Journal Systems community, among Scopus-indexed journals, and among publishers preparing for PubMed Central submission — is a gradual shift toward multi-format publishing. The PDF stays, but it is no longer alone. Alongside it:

• A full-text HTML version optimized for browser reading
• A JATS XML file for databases and long-term interoperability
• Sometimes an ePub for mobile reading apps

This is not a radical proposal. It is what Nature, PLOS, eLife, and virtually every major academic publisher already does. The question for smaller and mid-sized journals is: when do we start, and how?

The Case for Full-Text HTML

HTML is how the web was built. It is what browsers read natively. And it has specific advantages for academic content that are easy to underestimate.

Readability without a download. A reader on a mobile phone can open an HTML article directly in their browser. No app needed, no 5MB file to download, no PDF viewer struggling to reflow text for a small screen. On mobile — which now accounts for a significant portion of academic reading — HTML wins by a large margin.

Better indexing by search engines. Google Scholar, Bing Academic, and general web crawlers index HTML content more accurately and more completely than PDFs. Headings, keywords, abstracts, author names, and citations embedded in structured HTML are more reliably extracted and ranked.

Accessibility. Screen readers, browser zoom functions, contrast settings, and dyslexia-friendly fonts all work seamlessly with HTML. PDF accessibility requires additional tagging work that most journals skip entirely.

Linking and interactivity. HTML enables clickable reference lists, internal section links, embedded figures with captions, supplementary material expansion, and DOI links that work inline. A PDF is static; HTML is alive.

Compatibility with AI research tools. Tools like Elicit, Consensus, Semantic Scholar, and even general-purpose LLMs process text far more accurately when it is clean HTML than when it is extracted from a PDF. As AI-assisted literature review becomes standard in academic workflows, HTML-published content will have a measurable advantage in discoverability and citation.

The Case for JATS XML

JATS (Journal Article Tag Suite) is the XML standard used by PubMed, PMC, Crossref, and most major academic databases for structured article exchange. If HTML is the format for readers, JATS XML is the format for machines and systems.

PubMed Central requires it. If your journal is applying for or maintaining PubMed/PMC indexing, JATS XML is mandatory. There is no workaround.

Metadata richness that PDF cannot match. A JATS XML file can encode author ORCID IDs, funding information with Funder Registry identifiers, contributor roles (CRediT taxonomy), structured reference lists with DOIs, figure descriptions, license terms, and dozens of other metadata fields — all in a machine-readable, standardized way. This is the difference between having metadata and communicating it to every system that touches your content.

Portability and long-term interoperability. JATS XML is format-agnostic. From a single well-formed XML file, you can generate HTML, PDF, ePub, or any future format. It is the master record from which everything else can be derived. This is why major publishers maintain JATS XML as their canonical content format.

Future-proofing for AI and data mining. Academic data mining — the large-scale analysis of scientific literature for trends, systematic reviews, and AI training — operates almost entirely on structured XML. Journals that publish JATS XML contribute to and benefit from this ecosystem. Journals that publish only PDF are largely invisible to it.

Crossref metadata deposit. When you register a DOI with Crossref, the metadata you deposit determines how well your article is matched in citation indexes. JATS XML enables richer, more accurate Crossref deposits than manual metadata entry.

What About Metadata? The Invisible Foundation

One pattern we see repeatedly in our conversion work: journals that are eager to publish HTML or XML, but whose source PDFs are missing the very metadata that makes structured publishing possible.

No ORCID IDs for authors. No clear received/accepted dates. No DOI on the first page. References without DOIs. Keywords buried in the abstract text without a clear label.

Structured formats are only as good as the data that goes into them. Before investing in HTML or XML publishing, it is worth auditing your current PDF production workflow against a basic metadata checklist. We wrote that checklist here: Creating Machine-Readable Academic PDFs.

A Practical Path Forward

For most journal editors reading this, the question is not philosophical — it is operational. You have a small team, a limited budget, and a backlog of articles to process. Here is a realistic framework:

Step 1: Fix the PDF first.
A well-structured PDF with complete metadata is the foundation. If your PDF production is inconsistent, HTML and XML outputs will inherit those problems. Use the checklist linked above.

Step 2: Add HTML for current issues.
Full-text HTML for new articles is achievable with existing tools. OJS supports HTML galley uploads natively. Even a basic, clean HTML version is a significant upgrade over PDF-only publishing.

Step 3: Pursue JATS XML for indexing goals.
If your journal is targeting PubMed, pursuing higher Scopus standing, or preparing a Plan S compliance statement, JATS XML is the path. This is more complex, but the infrastructure exists to support it.

Step 4: Don’t do it manually.
Manual conversion of PDFs to HTML or JATS XML is slow, expensive, and error-prone. Automation — whether through your own typesetting workflow, a conversion service, or a platform like FullTextCreator — is the only scalable approach.

Why We Built FullTextCreator

This is not a theoretical discussion for us. We built FullTextCreator precisely because we saw how much friction existed between a journal’s content and its full digital potential.

The service accepts PDF or Word document uploads and produces clean full-text HTML and JATS XML — structured, metadata-rich, and ready for OJS galley upload or database submission. The demand since launch has been consistent and growing, particularly from journals in Turkey, Eastern Europe, and Southeast Asia that are navigating indexing requirements for the first time or preparing PMC applications.

The problem we keep solving is the same: a journal has years of well-written, peer-reviewed content, but it is locked in PDFs that no database can properly read. Format conversion is the bridge between the content that exists and the visibility it deserves.

Conclusion

The academic publishing format question is not PDF versus HTML versus XML. It is PDF plus HTML plus XML — a multi-format strategy that serves readers, machines, indexing databases, and AI tools simultaneously.

PDF remains essential for the foreseeable future. But journals that publish only in PDF are leaving discoverability, accessibility, and indexing potential on the table. The transition is already underway at every level of the scholarly publishing ecosystem. The question is not whether to make the shift, but how to do it efficiently.

For journals serious about visibility, indexing, and future-proofing their content: the format upgrade is not optional. It is infrastructure.

---

Looking for hands-on help with format conversion? Visit fulltextcreator.com or explore our OJS hosting and services for academic journal support.

The post From Print to Digital: PDF, HTML, or XML – What Should Academic Journals Publish Today? first appeared on OPEN JOURNAL SYSTEM SERVICES.

Zenodo is a free, open-access repository developed by CERN that allows researchers and publishers to assign Digital Object Identifiers (DOIs) to their publications — completely free of charge. Unlike commercial DOI providers, Zenodo offers unlimited DOI registration with no annual fees, making it an ideal solution for academic journals operating on limited budgets.

With a Zenodo DOI, your articles gain permanent, citable identifiers that are indexed by major academic databases, ensuring long-term discoverability and accessibility for the global research community.

How Zenodo DOI Works — What to Expect

It’s important to understand how Zenodo DOIs differ from services like CrossRef or DataCite. When you assign a DOI through Zenodo:

• The DOI link (e.g., https://doi.org/10.5281/zenodo.12345) resolves to the Zenodo record page, not directly to your journal website.
• Zenodo stores a copy of your article (PDF and metadata) as an open-access archive on its platform.
• Your journal URL is included in the Zenodo metadata, so readers can easily find and visit your journal from the Zenodo page.

This is different from CrossRef, where the DOI link points directly to the article on your journal website. With Zenodo, your article gains an additional presence on a trusted, CERN-hosted repository — providing extra visibility, long-term preservation, and credibility. Many journals use Zenodo DOIs as a cost-free alternative to commercial DOI services, and the Zenodo landing page serves as a secondary access point that complements your journal.

The Challenge: A Tedious Manual Process

While Zenodo provides an excellent free DOI service, the process of depositing articles is entirely manual. For each article, journal editors must:

1. Log in to Zenodo and create a new upload to reserve a DOI
2. Copy the DOI and add it to the article’s PDF and OJS metadata
3. After publishing the article in OJS, return to Zenodo
4. Manually enter all metadata — title, authors, affiliations, abstract, keywords
5. Fill in publishing information — journal name, ISSN, volume, issue, page numbers
6. Upload the PDF file
7. Review everything and publish the record

This process takes 10–15 minutes per article and is highly prone to errors — typos in author names, missing affiliations, incorrect page numbers, or forgotten keywords. For journals publishing 30–100+ articles per year, this becomes a significant burden on editorial staff.

Our Solution: Zenodo DOI Sync Plugin for OJS

Based on direct feedback and requests from our OJS clients and the academic publishing community, we developed the Zenodo DOI Sync Plugin — a comprehensive integration that automates the entire Zenodo deposit workflow directly from within OJS.

What previously took 10–15 minutes of manual data entry per article now takes a single click and a few seconds. All metadata is pulled directly from OJS, eliminating human error and ensuring consistency between your journal and Zenodo records.

We continue to actively develop this plugin and provide dedicated support based on user feedback and evolving Zenodo API requirements.

Key Features

🔑 Secure Token-Based Authentication

The plugin connects to Zenodo using your personal access token — no passwords stored, no complex OAuth flows. Simply generate a token from your Zenodo account and paste it into the plugin settings. Each journal can have its own Zenodo account and token.

🏷️ One-Click DOI Reservation

Reserve a DOI from Zenodo without leaving OJS. The DOI is automatically saved to the article’s identifier field. No need to switch between OJS and Zenodo.

📋 Automatic Metadata Synchronization

With a single click, the plugin transfers all article metadata to Zenodo:

• Title — in the article’s original language
• Authors — with full names, affiliations, and ORCID identifiers
• Abstract — with HTML formatting preserved (bold, italic, paragraphs)
• Keywords — all subject keywords from the article
• Journal Information — journal name, ISSN, volume, issue, page numbers
• Publication Date — from the OJS publishing date

📄 Automatic File Upload

The plugin automatically uploads all galley files (PDF and others) from OJS to Zenodo. It handles file cleanup — removing old files before uploading new ones — ensuring your Zenodo record always matches your OJS content.

🌐 Zenodo Community Integration

If your journal has a Zenodo community, the plugin can automatically associate new deposits with your community. Simply enter your community slug in the settings, and every new DOI reservation will be linked to your community page.

🚀 Publish to Zenodo from OJS

Once your article is published in OJS, you can publish it to Zenodo with one click. The plugin handles metadata sync, file upload, community review submission, and publication — all in a single operation.

📊 DOI Management Dashboard

A dedicated management page in the OJS sidebar gives you a complete overview of all articles and their Zenodo status:

• Filter by Zenodo status (Draft / Published), OJS status, or issue
• Search by title, DOI, or article ID
• Sort by any column
• Sync or publish individual articles directly from the dashboard
• Color-coded status badges for instant visual overview

🔄 Legacy DOI Scanner

Already have articles with Zenodo DOIs that were created manually? The built-in scanner finds all existing Zenodo DOIs in your journal, checks their current status on Zenodo (draft or published), and updates the local database — so you can manage everything from one place.

🌍 Multi-Language Support

The plugin interface is fully translated in English and Turkish, with support for additional languages. All labels, messages, and notifications adapt to your OJS language setting.

🔒 Role-Based Access Control

Only Site Administrators and Journal Managers can access Zenodo features. Authors, reviewers, and other users cannot see or interact with DOI management tools.

What’s Included

• ✅ Full plugin with all features described above
• ✅ Installation and configuration support
• ✅ Zenodo account and token setup assistance
• ✅ Community configuration help
• ✅ Free updates for compatibility and improvements
• ✅ Ongoing technical support

Continuous Updates & Important Notes

This plugin is actively maintained and regularly updated to keep pace with OJS releases and Zenodo API changes. All updates are provided free of charge.

A note about Zenodo: Zenodo is an independent service operated by CERN with its own policies and eligibility criteria. While Zenodo offers free DOI registration for most academic content, they may apply restrictions on certain types of publications or journals at their discretion. Such policies are determined solely by Zenodo and are outside the scope of this plugin. We recommend checking Zenodo’s policies to confirm eligibility for your journal.

Compatibility

• OJS Version: 3.3.x
• PHP: 7.4, 8.0, 8.1
• Zenodo API: InvenioRDM REST API

Get the Plugin →

The post Why Zenodo DOI for Academic Journals? first appeared on OPEN JOURNAL SYSTEM SERVICES.

If your journal publishes research in economics, finance, business, or related social sciences, getting indexed in RePEc (Research Papers in Economics) is one of the most effective ways to boost your visibility — and it’s completely free.

RePEc is a decentralized, volunteer-driven platform that distributes your research metadata across a vast network of services including IDEAS, EconPapers, CitEc, Google Scholar, EconLit, ResearchGate, and many more. With over 4,200 journals and 70,000 registered authors across 104 countries, it’s one of the largest open bibliographic databases in the social sciences.

But here’s the catch: joining RePEc requires creating structured metadata files in ReDIF format, maintaining a specific directory structure, and keeping everything updated as you publish new issues. For most journal teams, this is tedious, technical, and error-prone.

That’s exactly why we built RepecPro.

What Is RepecPro?

RepecPro is a professional export plugin for Open Journal Systems (OJS) that fully automates your journal’s RePEc integration. No need to learn ReDIF syntax, no manual file management, no worrying about directory structures. Install the plugin, enter your RePEc archive details, and export — it’s that simple.

RepecPro supports both OJS 3.3.x and OJS 3.4.x.

Key Features

Automated ReDIF Template Generation

RepecPro automatically generates all required ReDIF files — archive template, series template, and individual article templates — directly from your OJS article metadata. Titles, authors, abstracts, keywords, publication dates, DOIs, PDF links — everything is mapped correctly.

Full Export & Selective Export

Export your entire journal catalog with a single click using Full Export, or selectively export specific issues or individual articles. Perfect for both initial setup and ongoing updates.

Auto-Export on Publication

Enable automatic export and RepecPro will generate ReDIF files whenever a new article is published. No manual intervention needed — your RePEc archive stays up to date automatically.

Directory Structure & Index Files

RepecPro creates and manages the complete directory structure that RePEc’s crawler requires, including HTML index files at every level. Your archive is HTTP-accessible and ready for RePEc’s mirroring software from day one.

Configuration Validator

Before exporting, run the built-in Validate Configuration tool to check that all required settings are properly configured. Catch issues before they become problems.

Export History & Logging

Every export operation — whether manual or automatic — is logged with detailed information: date, type, status, article count, and any errors. The Recent Exports tab gives you a complete audit trail.

Multi-Language Support

Full interface support in English and Turkish, with contextual help text for every settings field.

Smart Defaults

RepecPro pre-fills settings with sensible defaults based on your journal’s existing OJS configuration — journal name, ISSN, publisher, and more. Just review and adjust as needed.

How It Works

1. Install — Upload the plugin via OJS Plugin Gallery or manually
2. Configure — Go to Tools → Import/Export → RepecPro and enter your RePEc archive code, series code, and base URL
3. Export — Click Full Export to generate all ReDIF files
4. Verify — Test HTTP access to your archive URL and validate with RePEc
5. Register — Send your archive URL to the RePEc team for inclusion

That’s it. Your journal is on RePEc.

What Gets Exported?

For each published article, RepecPro generates a complete ReDIF record including:

• Article title and abstract
• All author names and affiliations
• Publication date, volume, issue, and pages
• Keywords / JEL classification codes
• DOI (if available)
• Direct PDF download URL
• Article landing page URL

Compatibility

Feature	OJS 3.3	OJS 3.4
Automatic ReDIF generation	✔	✔
Full / Selective export	✔	✔
Auto-export on publish	✔	✔
Configuration validator	✔	✔
Export history & logging	✔	✔
English / Turkish UI	✔	✔

Get RepecPro

Ready to get your journal indexed on RePEc — the easy way?

Get RepecPro Export Plugin →

REPEC PRO GUIDE

Need help with installation or RePEc registration? Contact us — we’re here to help.

---

RepecPro is developed and maintained by OJS Services, providing professional OJS solutions for academic publishers worldwide.

The post RepecPro – RePEc Export Plugin for OJS 3.3 & 3.4 first appeared on OPEN JOURNAL SYSTEM SERVICES.

A real-world debugging story about Memcached key collisions, caching layers, and why the same bug can hide for months — until it doesn’t.

March 2026  ·  OJS-Services.com

If you’re managing multiple OJS journals on the same server, here’s a scenario that might sound familiar: you update the current issue on one journal, and a few minutes later, a completely different journal’s homepage is showing that same issue. Or worse — users are seeing a journal they’ve never heard of, with a ‘View All Issues’ link that goes nowhere.

We ran into exactly this. Multiple OJS 3.3.x installations on a shared hosting environment, all seemingly independent, but quietly contaminating each other’s data through a shared Memcached instance. Here’s what happened, how we tracked it down, and what actually fixed it.

 

The Setup

We manage a portfolio of academic journals running on Open Journal Systems (OJS). Several of them are hosted on the same server — each with its own subdomain, its own database, its own OJS installation. Completely separate, or so we thought.

The server runs SiteGround’s shared hosting stack. SiteGround offers several caching layers out of the box:

• NGINX Direct Delivery — static file serving for images, CSS, JS
• Dynamic Cache — full-page HTML caching
• Memcached — object-level caching, shared across all sites on the account

 

That last one is the key detail. Memcached runs as a single shared service at 127.0.0.1:11211 — and every OJS installation on the account was configured to use it.

 

What We Saw

The first symptom was a PHP Fatal Error appearing on the homepage of one journal:

Fatal error: Call to a member function getPublished() on null

in classes/journal/SectionDAO.inc.php on line 334

 

The error trace pointed to getByIssueId(18). Except — issue_id 18 didn’t exist in that journal’s database. The highest issue_id was 11.

So where was 18 coming from?

We checked everything: the issues table, publication_settings, journal_settings, url_path fields. Nothing. The database was perfectly correct. The right current issue was set. Yet OJS was trying to load issue 18 on every homepage request.

This is one of those bugs that PHP 8.0 exposed rather than created. On PHP 7.x, calling a method on null returns null and moves on. On PHP 8.0, it throws a Fatal Error. The underlying problem existed before — it just wasn’t visible.

 

The Cache Trail

After ruling out database issues, we turned to caching. We deleted the entire /cache/ directory. The error came back immediately on the next request. We cleared SiteGround’s Dynamic Cache. Same result — gone for a moment, then back.

Then we tried something almost accidental: switching the journal’s theme in the OJS admin panel. The error disappeared. We switched back to the original theme. It stayed fixed — for a while.

The reason? Switching themes triggers OJS’s internal cache flush, which includes Memcached. The stale data was cleared. But the next time OJS populated the cache, it pulled the wrong data again.

This pointed clearly at Memcached. The object cache was storing the wrong issue_id, and no amount of file cache clearing would touch it.

 

The Real Problem: Key Collisions

Here’s what was actually happening. OJS builds Memcached cache keys like this (from MemcacheCache.inc.php):

$this->getContext() . ‘:’ . $this->getCacheId() . ‘:’ . $id

 

For the current issue cache, this produces a key like:

issues:current:1

 

The 1 at the end is the journal_id. And here’s the problem: every fresh OJS installation assigns journal_id = 1 to the first journal. All three of our affected installations had journal_id = 1.

So Journal A, Journal B, and Journal C were all reading and writing to the exact same Memcached key. When Journal C updated its current issue, that value was written to issues:current:1. When Journal A loaded its homepage, it read that same key — and got Journal C’s data.

There is no site-specific prefix in OJS 3.3.x’s Memcached implementation. If two installations share the same Memcached instance and both have journal_id = 1 (the default), they will silently share cached data.

 

The Caching Layer Stack

Before we get to the fix, it’s worth stepping back and looking at the full picture. Modern hosting environments — especially managed ones like SiteGround — can have three or four independent caching layers operating simultaneously:

1. OJS Internal Cache (File-based)

OJS writes cache files to its own /cache/ directory. Clearing this is the first thing most people try. It has no effect on Memcached-stored data.

2. OJS Object Cache (Memcached)

Configured in config.inc.php under [cache]. This is where things like current issue data are stored. If you’re using Memcached on a shared hosting account, this cache is shared at the server level across all sites. This was the source of our problem.

3. Server-Level Dynamic Cache (SiteGround SuperCacher)

SiteGround’s Dynamic Cache stores the complete HTML output of pages. It’s fast, but it can serve stale content even after the database or OJS cache is updated. For OJS journals, we recommend disabling this entirely. OJS has its own caching logic; layering a full-page cache on top creates unpredictable behavior.

4. CDN Cache (Cloudflare)

If your journals are proxied through Cloudflare, you have yet another caching layer in front. Depending on your page rules, Cloudflare can cache HTML pages too. In our setup, some domains were behind Cloudflare — which added another variable to the debugging process when things didn’t clear as expected after a fix.

The tricky part with multiple caching layers is that clearing one doesn’t clear the others. You might flush OJS’s file cache, confirm the database is correct, but Cloudflare is still serving a page from three hours ago. Or SiteGround’s Dynamic Cache is returning a stored response generated before your fix. Always clear in the right order: OJS cache first, then server cache, then CDN.

When something looks wrong on an OJS site and you’ve already confirmed the database is correct, the question becomes: which cache layer am I actually looking at right now?

 

What Didn’t Work

For the record — things we tried that had no effect on the actual collision:

• Deleting all /cache/ files: Only affects file-based cache, not Memcached
• Adding memcache_key_prefix to config.inc.php: This option exists in the config template but is not read by MemcacheCache.inc.php in OJS 3.3.x. It does nothing.
• Clearing Cloudflare cache: Not the source
• Clearing SiteGround Dynamic Cache: Temporarily removed stale HTML, but Memcached repopulated on the next request
• Updating the current issue via database: Correct in DB, but immediately overridden by the stale Memcached value

 

The Fix

The solution was a one-line addition to MemcacheCache.inc.php in each affected installation. In the constructor, before adding the server, we set a site-specific prefix using Memcached’s OPT_PREFIX_KEY option:

$this->connection = new Memcached;

// Add this line:

$this->connection->setOption(Memcached::OPT_PREFIX_KEY, md5(__FILE__) . ‘_’);

$this->connection->addServer($hostname, $port);

 

The md5(__FILE__) generates a unique hash from the absolute filesystem path of MemcacheCache.inc.php. Since each OJS installation lives in a different directory, the hash is automatically unique per installation — no manual configuration needed.

After applying this to all three affected installations and flushing Memcached from the SiteGround panel, the cross-site contamination stopped completely.

We also added a null guard to SectionDAO.inc.php to prevent the PHP 8.0 Fatal Error in case a stale cache entry ever surfaces again:

$issue = Services::get(‘issue’)->get($issueId);

if (!$issue) return [];  // Don’t crash on invalid/stale issue_id

 

Why OJS 3.4.x Wasn’t Affected — What the Code Tells Us

The following is based on direct inspection of OJS 3.4.x source files. These are observations and reasoned conclusions, not claims we can fully verify without PKP team confirmation.

 

We had OJS 3.4.x installations running on the same server, with the same journal_id = 1, using the same Memcached instance — and they weren’t experiencing the collision. We wanted to understand why before writing this up.

Looking at the OJS 3.4.x source, the answer appears to be that the Memcached cache path for issue data has been intentionally disabled. In classes/issue/Repository.php, the getCurrent() function contains this comment:

// TODO: Caching as currently setup never properly caches objects

// and always fires a _cacheMiss()

// if ($useCache) {

//     $cache = $this->dao->_getCache(‘current’);

//     return $cache->get($contextId);

// }

 

The Memcached code is commented out. In classes/issue/DAO.php, cache flush calls are similarly disabled with TODO notes. This suggests the PKP team was aware of caching problems during the 3.4.x rewrite and chose to disable this code path temporarily, pending a proper fix.

The result is that OJS 3.4.x reads the current issue directly from the database on every request — no Memcached involved, no collision possible. It’s not that the underlying key collision problem was architecturally solved; it’s that the affected cache path simply isn’t executing.

If Memcached is re-enabled in a future OJS 3.4.x version without adding site isolation, the same collision would likely reappear. The OPT_PREFIX_KEY fix should be applied proactively.

 

Recommendations

If you’re running multiple OJS 3.3.x installations on the same server with Memcached:

• Apply the MemcacheCache.inc.php prefix fix to every installation sharing the Memcached instance
• After applying the fix, flush Memcached from your hosting panel to clear any stale cross-site data
• Disable SiteGround Dynamic Cache for all OJS subdomains — it conflicts with OJS’s own caching
• If using Cloudflare, bypass cache for dynamic paths (/index.php/*) and only cache static assets
• When troubleshooting: clear OJS cache first, then server cache, then CDN — in that order

 

For CMS and publishing platforms with their own internal caches, server-level full-page caching (Dynamic Cache, Varnish, etc.) often causes more problems than it solves. Leave object caching to the application; use the CDN for static assets.

 

Wrapping Up

Cache bugs are among the most disorienting to debug because the evidence keeps disappearing. The database looks right, the admin panel looks right, but the site is showing something wrong. When you’re dealing with a multi-layer cache stack and multiple installations sharing infrastructure, the number of possible interactions multiplies fast.

In our case, the bug had probably been present for months, quietly hiding behind PHP 7.x’s silent null handling. The PHP 8.0 upgrade made it impossible to ignore. Sometimes an upgrade doesn’t introduce bugs — it just makes existing ones visible.

We’ve submitted a detailed bug report to the PKP/OJS team with the full analysis and reproduction steps. If you’re running a similar multi-site OJS setup and seeing strange homepage behavior, Memcached key collisions should be high on your list of suspects.

 

OJS-Services.com

We manage 500+ academic journals on Open Journal Systems. When we run into edge cases like this, we write them up — because someone else is probably dealing with the same thing.

The post When Your OJS Journals Start Showing Each Other’s Content first appeared on OPEN JOURNAL SYSTEM SERVICES.