OJS 3.5: What Changed for Journal Managers

• Think in terms of operations
• Compatibility review
• Workflow testing
• Use demos and staged planning

• OJS 3.5 Demo
• Plans
• Contact

Journal managers should evaluate OJS 3.5 through the practical work that happens every day: submissions, review assignments, editorial decisions, copyediting, production, publication, email notifications, and metadata management.

A version change is not only a visual or administrative event. It can affect themes, plugins, workflows, server requirements, and staff routines, so it should be planned as a production change.

Before moving to OJS 3.5, review active plugins, theme customizations, PHP requirements, database settings, and integrations such as DOI deposits or analytics. Unsupported plugins can create issues even when the core application works.

Theme review is also important. A public journal interface should be checked on article pages, issue pages, navigation, search, mobile layouts, and pages with custom content.

A practical test plan should include author submission, reviewer assignment, editorial decisions, file uploads, publication, email delivery, DOI settings, and administrator tasks. Testing only the homepage is not enough.

Journal managers should include editors and technical staff in review. Editors can confirm workflow expectations, while technical staff can verify logs, permissions, scheduled tasks, and server behavior.

A demo environment helps teams become familiar with OJS 3.5 before committing to production changes. It can also reveal questions about roles, settings, and interface behavior.

JournalsHQ provides OJS 3.5 demo access and technical planning through its plans and contact process. The goal is cautious readiness, not unsupported claims about automatic upgrade success.