In April 2026, EIFL submitted comments for a public consultation organized by the Intellectual Property Office of the Republic of Serbia on the Draft Law on Copyright and Related Rights (2026). The amendments seek to harmonize Serbian law with two EU Directives (Directive 2012/28 on orphan works and Directive 2014/26 on collective management organizations), and to implement the Marrakesh Treaty for persons with disabilities into national law.
In March, EIFL responded to two public consultations on proposed new copyright laws. The Kenya Copyright Board (KECOBO) invited stakeholders to submit written comments on the Copyright and Related Rights Bill, 2026, while in Zambia, the Patents and Companies Registration Agency (PACRA) encouraged stakeholders to review and send proposals on the Copyright and Related Rights Bill, 2025 (extended deadline 31 March 2026). The bills seek to modernize the copyright frameworks in Kenya and Zambia in line with technological developments and international best practices.
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.
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:
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.
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:
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?
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.
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.
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.
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.
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.
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.
EIFL has signed a three-year agreement with Encyclopaedia Britannica Ltd providing discounted pricing for Britannica Academic, a comprehensive, authoritative digital library featuring expert-reviewed encyclopedia articles, primary sources, journals, and multimedia.
Libraries in 29 EIFL partner countries are eligible to access Britannica Academic through this agreement. The agreement starts on 1 April 2026 and runs for three years, until 31 March 2029.
This EIFL webinar will explore practical experiences in using AI (artificial intelligence) tools for learning and training. There will be a particular focus on using AI tools for personal learning and for developing materials for open science training. The webinar is intended for trainers, librarians and anyone interested in AI-enhanced learning.
Milica Ševkušić, EIFL Open Access Programme Project Coordinator, will speak at the Seventh Workshop for Open Access Journal Publishers organized by the Slovak Centre of Scientific and Technical Information. Her presentation, 'Building a Diamond Open Access Publishing Ecosystem', will explore approaches to strengthening Diamond open access publishing.
Join the EIFL online meet-up of open science trainers, which will discuss tools for creating illustrations for training materials. We will also continue a discussion on institutional open science training.
Date and time: 23 April, 9:00 UTC (convert to your timezone)
Registration: Please register here to participate in the meet-up.
Join the next meeting of the Community of Practice (CoP) for no-fee OA publishing in Africa.
Date and time: 15 April 2026 at 10:00 UTC/11:00 WAT/12:00 CAT/13:00 EAT (convert to your timezone).
Milica Ševkušić, EIFL Open Access Programme Project Coordinator, will speak about open access and research impact during the Open Access Programme organized by Midlands State University in Zimbabwe. The event will feature presentations on open access fundamentals, research impact, ethical publishing practices, and the Midlands State University Institutional Repository.
Join this informal online discussion, 'A Virtual Break', hosted by the EIFL Public Library Innovation Programme (EIFL-PLIP) on the topic 'The Civic Potential of Public Libraries' - that is, the potential of public libraries in divided societies to foster dialogue between different viewpoints and combat misinformation and manipulation encountered online.
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.
It’s important to understand how Zenodo DOIs differ from services like CrossRef or DataCite. When you assign a DOI through Zenodo:
Loginhttps://doi.org/10.5281/zenodo.12345) resolves to the Zenodo record page, not directly to your journal website.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.
While Zenodo provides an excellent free DOI service, the process of depositing articles is entirely manual. For each article, journal editors must:
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.
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.
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.
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.
With a single click, the plugin transfers all article metadata to Zenodo:
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.
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.
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.
A dedicated management page in the OJS sidebar gives you a complete overview of all articles and their Zenodo status:
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.
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.
Only Site Administrators and Journal Managers can access Zenodo features. Authors, reviewers, and other users cannot see or interact with DOI management tools.
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.
The post Why Zenodo DOI for Academic Journals? first appeared on OPEN JOURNAL SYSTEM SERVICES.
Public librarians provide training on various topics in their communities, and to support them, the EIFL Public Library Innovation Programme (EIFL-PLIP) has developed several educational videos in the EIFL-PLIP ‘Small Bites’ series on organizing and delivering library training programmes. We are pleased to share a new 'Small Bites' video, on the topic, ‘Managing Distracting Behaviour in Training’.
AEGIS-OA (Activate European Guidance and Incentives for Sustainable Open Access publishing), a project funded by the EU under the Horizon Europe research and innovation programme, kicked off on 19-20 March 2026 in Brussels.
EIFL is one of 24 organizations from 16 European countries partnering in the AEGIS-OA project, which brings together a diverse range of research-performing organizations, service providers, and National Capacity Centres with expertise in institutional publishing, Diamond open access, and open science.
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.
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.
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.
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.
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.
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.
Before exporting, run the built-in Validate Configuration tool to check that all required settings are properly configured. Catch issues before they become problems.
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.
Full interface support in English and Turkish, with contextual help text for every settings field.
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.
That’s it. Your journal is on RePEc.
For each published article, RepecPro generates a complete ReDIF record including:
| 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 | ✔ | ✔ |
Ready to get your journal indexed on RePEc — the easy way?
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.
Iryna Kuchma, EIFL Open Access Programme Manager, will speak about strengthening the quality and sustainability of Diamond Open Access in Africa: funding, support and impact. Her talk will cover results of the Collaboration for sustainable open access publishing in Africa project, implemented by EIFL, AJOL (African Journals Online) and WACREN (the West and Central African Research and Education Network), with funding from Wellcome.
Ramune Petuchovaite, Manager of the EIFL Public Library Innovation Programme (EIFL-PLIP), shares case studies of successful public library advocacy with Universal Service and Access Funds in Ghana, Kenya and Uganda, and first steps taken in Malawi and Zambia.
The ALMASI project (Aligning and Mutualizing Nonprofit Open Access Publishing Services Internationally) invites you to attend the 2nd Cross-regional meeting of the Diamond OA Policy Forum for Africa, Europe and Latin America.
New applications deadline for the 9th OpenAIRE Open Science Train-the-Trainer Bootcamp for librarians, data stewards, research support staff or any other professional stakeholders who are planning to deliver open science training to researchers, research support staff and/or students -
Deadline for applications: Extended to 13 April 2026 (23:59 CEST)
Results announcement: 17 April 2026
Bootcamp: 25 - 29 May 2026
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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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?
For the record — things we tried that had no effect on the actual collision:
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
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.
If you’re running multiple OJS 3.3.x installations on the same server with Memcached:
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.
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.
