OJS 3.4 What’s New and Should you upgrade now?

All our product (including the OMP platform) is now supported by the 3.4 version.

Overview of the OJS 3. 4

The PKP team is constantly dedicated to enhancing and refining the OJS platform. Their latest accomplishment was the release of OJS 3.4 on June 9, 2023, which showcases a multitude of advancements. This version introduces substantial changes to the workflow, and user interface, and incorporates exciting new features.

Upon reflecting on our experience with the previous versions, namely 3.2 and 3.3, it becomes evident that the OJS platform has consistently delivered an exceptional user experience in managing and publishing scholarly journals electronically. Consequently, a pertinent question arises: should we proceed with upgrading to the latest OJS version or maintain our current one? To help you in reaching a well-informed decision, we have meticulously outlined the features, advantages, and comprehensive recommendations below.

Note of the 3.4 version:

Client Charset

A character set, often referred to as a charset, is a defined collection of characters that can be used by a computer system or programming language. It is a mapping between characters and their corresponding binary representations (usually numeric codes) used for the storage and communication of text data. Each character in a character set is assigned a unique code point or code value.

Character sets are essential for encoding and representing text in various forms, such as documents, web pages, emails, and other digital content. They define the set of characters that can be used in a given context, including alphabets, numerals, punctuation marks, symbols, and control characters.

There are several character encoding standards that specify different character sets and their corresponding encoding schemes, such as ASCII, Unicode, and ISO-8859. Unicode is the most widely used character set standard today, as it supports a vast range of characters from various writing systems, including languages from different countries and historical scripts.

Character sets determine how text is stored and interpreted by computers, and choosing the appropriate character set is crucial for ensuring accurate representation and communication of textual information in different contexts and languages.

Previously if you are using previous OJS in 3.1.2, and 3.2, the default charset is Latin. 

For example in this case :

The character sequence “ú” is a common symptom of a character encoding mismatch or misinterpretation. It typically occurs when a text encoded in one character set, such as UTF-8, is incorrectly interpreted as a different character set, often Latin-1 (ISO-8859-1) or Windows-1252.

In UTF-8 encoding, the character “ú” is represented by the single byte 0xC3 followed by the byte 0xBA. However, if these two bytes are misinterpreted as Latin-1 or Windows-1252, they will be displayed as “ú” instead of “ú”.

As the default column is set to use the “latin1_swedish_ci” character set and you attempt to store the character “ú” into that column when adding new data to the OJS below 3.3 version, it would not be stored as “ú” by default. The “ú” representation suggests a character encoding mismatch or misinterpretation.

So in many cases as the OJS uses the column latin_swedish as the default charset for many of the column default charset. When storing some UTF8 character set, it will be held as “ú” in the database data. 

This problem at the user level can be fixed easily by configuring this configuration in OJS < 3.4 as they have this configuration in their config.inc.php file.

; Database collation
collation = utf8_general_ci

; Client output/input character set
client_charset = utf-8

The problem is, as the default column is using latin1_swedish_ci that has resulted in many of the OJS having character mismatch stored in previous OJS so it will have this issue.

Many plugins may have a compatibility issue with the 3.4 version

As there have many changes in the OJS 3.3 version, you will get most of the plugins including the theme will have substantial issues with OJS 3.4. 

Many of the technical issues and some hooks have been removed in OJS 3.4 version. For example : 

The import() statements and global constants like this are no longer used:

import('classes.submission.Submission');
import('lib.pkp.classes.author.PKPAuthor');

$submission = new Submission();
$author = new PKPAuthor();

$submission->setData('status', STATUS_PUBLISHED);

The above code should be updated with :

use APP\submission\Submission;
use PKP\author\Author;

$submission = new Submission();
$author = new PKPAuthor();

$submission->setData('status', Submission::STATUS_PUBLISHED);

Hooks Removed

These hooks were typically removed due to code refactoring or major updates that made them obsolete. Some of the hooks that were removed are :

Mail::send
Announcement::getProperties
Author::getProperties::values
EmailTemplate::getProperties
Galley::getProperties::values
Issue::getProperties::fullProperties
Issue::getProperties::summaryProperties
Issue::getProperties::values
Publication::getProperties
Section::getProperties::fullProperties
Section::getProperties::summaryProperties
Section::getProperties::values
Submission::getProperties::values
SubmissionFile::getProperties
User::getProperties::fullProperties
User::getProperties::reviewerSummaryProperties
User::getProperties::summaryProperties
User::getProperties::values
Announcement::getMany::queryBuilder
Announcement::getMany::queryObject
Author::getMany::queryBuilder
Author::getMany::queryObject
EmailTemplate::getMany::queryBuilder
EmailTemplate::getMany::queryObject::custom
EmailTemplate::getMany::queryObject::default
Galley::getMany::queryBuilder
Issue::getMany::queryBuilder
Publication::getMany::queryBuilder
Publication::getMany::queryObject
Stats::getOrderedObjects::queryBuilder
Stats::getRecords::queryBuilder
Stats::queryBuilder
Stats::queryObject
Submission::getMany::queryBuilder
Submission::getMany::queryObject
SubmissionFile::getMany::queryBuilder
SubmissionFile::getMany::queryObject
User::getMany::queryBuilder
User::getMany::queryObject
User::getReviewers::queryBuilder

Code Removed

As part of modernizing code, several functions were removed, deprecated or replaced by the PKP team, for example these methods no longer work to show submission cover images.

Submission::getCoverImage();
Submission::getLocalizedCoverImage();
Submission::getCoverImageAltText();
Submission::getLocalizedCoverImageAltText();
Submission::getLocalizedCoverImageUrl();

Get the cover image info from the Publication object instead.

APP\publication\Publication::getLocalizedData('coverImage');
APP\publication\Publication::getLocalizedCoverImageUrl($contextId);

OJS is getting in love with Laravel

In OJS 3.3 some of Laravel features have been implemented but not fully utilized. The developer now integrated many of the features and architecture from Laravel to OJS. Now in version 3.4, a lot of Laravel features have been implemented, for example, PHPMailerhas have been replaced by Laravel Mailer, Job, and Queues, Event, Query Builder, Facades, Cache, Collection, Lazy Collection, etc. 

Now you can use Database Query Builder from Laravel. Instead of using DAO.

$dao->retrieve(
"SELECT controlled_vocab_entry_id as id from controlled_vocab_entry_settings cves where setting_value like ? and setting_name = 'submissionKeyword'",
[$keywordList]
);

Now it can be used  Query builder to run some queries:

DB::table('controlled_vocab_entry_settings')
->selectRaw('controlled_vocab_entry_id as id')
->where('setting_name', 'submissionKeyword')
->whereIn('setting_value', $keywordList)
->get();

The change of course may affect the compatibility of many plugins that have run the DAO query and many themes/plugins as this version introduces a substantial change in the code of the plugin and theme coding. The drawback is many of the themes/plugins should update their code in major change too including some of the thing to consider that many of the deprecated function of PHP 7 is no longer supported in PHP 8.1 version.

The delete feature in the submission 

This feature still not existed although many of the users request this as this will make the user easier to delete submissions: 

The article metadata editor has no change

When you need to edit the metadata of the article, 3.4 still offers the same user interface or does not introduce any new feature and it still has some vertical tabs on the metadata as shown in 3.2 onward. 

There is no additional metadata introduced in that editor.

DOI in the meta editor is disappeared 

Another thing that needs to note is, in the article metadata you won’t find the DOI identifier as one of the vertical menu tabs. 

The only notable change is, the DOI metadata, in 3.4 is not available in the article metadata editor. This will make the journal manager or publisher of the article become more complex in managing the article metadata because the DOI will be separated into a single menu.

Although the DOI is now dedicated as the main menu in the OJS backend, unfortunately removing this menu in the article metadata is not a very good idea. This makes the journal manager or editor do multiple click to edit the current article DOI that they are editing into another menu and interface.

Still … no feature to edit Submission Date

This 3.4 also still does not provide an input that allows you to edit the Submission date. Although this feature has been requested and needed by many of the users. This feature is important as we found that many of the journals are doing some migration from the paper-based archive to the digital-based archive. Using the provided submission date as automatically recorded by the OJS system will mislead. 
This issue as many asked by our client have implemented in our plugin in OJTPlusPro one of the features. Check it out here.

The downloaded file from the article

In OJS 3.1, files of the article galley such as PDF files will be downloaded with this convention 

SubmissionId-GenreName-FileId-RevisionId-FileStage-DateUploaded.extension 

In 3.3 until 3.4 the file will be downloaded with the name of the uploaded name and still not changed. For example when downloading the PDF galley from the article name:

“Quanta Analytics Effectivity in Stock Price Judgement” will not result in the PDF file name as Quanta-Analytics-Effectivity-in-Stock-Price-Judgement.pdf but with the uploaded file name as uploaded in the upload stage in adding the galley. Yes, we agree that this is not a good idea as many of our client complaint about this. To fix this our team has a special free plugin that fixes the issue.

To fix this, you can download and activate the plugin by reading this article :
https://openjournaltheme.com/restore-the-ojs-3-3-x-downloaded-filename-convention-free-plugin

Minor New features

Added the feature of journal statistics in the Statistic Menu

as in the 3.2 onward version you can get the accumulated statistic for some activities such as the article view and download in the dedicated OJS statistic menu, in 3.4 you also get the new statistic for the journal.

Now in OJS 3.4 version you will see the accumulated view of all the journals like this :

DOI for PDF or Article galley

Now you can add the PDF file with its specific DOI. 

As far as we know, we don’t think this is very useful as this may become the article that has multiple doi’s will become confusing if someone does a citation of the article. The author may lose or duplicate citations with this policy. 

In some other cases, this will make the creation of DOI becomes more expensive as many DOI providers charge the DOI based on the record quantity. 

If you have some ideas why this is important just let us know in the comment so other people will thank you for such a new knowledge.

Geographical Statistic

In 3.4 there is a new  feature that allows the platform to record the visitor based on the Graphical location : 

Unfortunately, this feature is a lack in essential feature as many indexers such as Scopus and other reputable indexing, need the data not only for the visitor, but for all the roles that participate in the journal workflow such as Author, Editor, and Journal Manager can be viewed in the chart or in the aggregate data. 

This feature also is not very useful when there is no way to show the result in the front end as this may remove the need for the journal to depend on some third-party service such as StatCounter, ClusterMaps or others. 

Many indexers also don’t trust this internally collected data since it can be modified rather than using external statistic data.

Major New Feature in  OJS 3.4

We have provided a detailed description below of the prominent features retained from OJS 3.3 and the additional features introduced in the latest OJS 3.4 version.

Improved User Interface

OJS 3.3/3.4 includes a better and improved user interface. Page layout, layout, and navigation have been updated to improve the user experience and make navigating within the system easier.

For example, in the submission title as complained by many of the OJS users, it is   now can add some text formatting :

In the author submission process, the 3.4 version the process will be offered in wizard-based process :

Improved Peer Review Functionality

OJS 3.3/3.4 has improved peer review functionality. New features, such as automatic review assignments based on topics or areas of expertise, updated review notifications, and improved reviewer collaboration tools, allow for a more efficient peer review process.

Role and capability for multi journal change

Site Administrators now have the same managerial access as Journal Managers regardless of whether they also have that role.

This is intended to differentiate more clearly between Site Administrators (who are usually system administrators or technical support, but are not active in the journal workflow) from Journal Managers (who participate in the workflow); in previous releases, it was often required for administrators to assign both roles to be effective.

Starting with OJS 3.4.0, Journal Managers now have the ability to control user enrollment in their journal regardless of whether the user is active in other journals.

As we know, In previous releases it was often necessary to escalate registration issues to Site Administrators when users were active in multiple journals.

In essence, multi-journal installations allow for more centralized and efficient management of multiple journals within one OJS system. This feature is especially useful for publishers or institutions that manage several journals with similar operational and management needs.

Improved Security and Stability

OJS 3.3/3.4 offers increased security and stability. Known security vulnerabilities have been fixed, and several bug fixes and performance improvements have been made to maintain system stability.

Upgrading to PHP 8.1 enables OJS to take advantage of the improved security measures and advanced protection features offered by the newer PHP environment. Newer PHP versions undergo rigorous testing and development, focusing on strengthening security protocols and resolving any vulnerabilities identified in previous versions. Additionally, PHP updates often introduce performance optimizations and stability enhancements, resulting in a smoother and more reliable experience for OJS users.

How to install OJS 3.4

Preparing and installing OJS can be straightforward when following the necessary steps. To get started, you need to ensure your server meets the required specifications. Once prepared, you can follow a comprehensive tutorial provided in the link below to guide you through the entire process of installing OJS version 3.3x. This tutorial covers all the necessary steps and provides detailed instructions for a successful installation:

How to install OJS step by step

Note: This comprehensive tutorial provides a step-by-step installation guide using the OJS 3.3 demo version. While the tutorial specifically focuses on version 3.3, the instructions and concepts covered are still applicable and relevant for installing OJS version 3.4.

How to Upgrade OJS 3.4

To ensure a smooth upgrade process and safeguard your data, it is crucial to prepare a backup before upgrading your OJS installation. This involves creating a backup of your OJS files, database, and any customizations you have made. Once the backup is secured, you can proceed with the upgrade process.

For a comprehensive and detailed tutorial on how to upgrade OJS 3, you can follow the link below:

OJS upgrade tutorial

Note: The provided link leads to a comprehensive tutorial that covers the complete upgrade process of OJS 3

How to fix errors when upgrading ojs 3.4

During the upgrade process, you may encounter errors such as the following:

1. Fatal error: Uncaught Exception: Invalid product name “academic_pro” in /OJThome/Uyt657/public_html//lib/pkp/classes/plugins/PluginRegistry.php:185
2. Fatal error: Uncaught Exception: Invalid product name “classy” in /OJThome/Uyt657/public_html//lib/pkp/classes/plugins/PluginRegistry.php:185
3. Fatal error: Uncaught Exception: Invalid product name “noble” in /OJThome/Uyt657/public_html//lib/pkp/classes/plugins/PluginRegistry.php:185
4. Fatal error: Uncaught Exception: Invalid product name “novelty” in /OJThome/Uyt657/public_html//lib/pkp/classes/plugins/PluginRegistry.php:185

To resolve this error and successfully complete the upgrade, please follow the steps below:

1. Restore the database backup to ensure a clean starting point for the upgrade process.
2. Before proceeding with the upgrade process, make a copy of all the plugins and themes used in the previous OJS version. Paste these copied files into the corresponding locations within the new OJS version files. This step ensures that your custom plugins and themes are preserved during the upgrade.
3. Now, you can proceed to run the upgrade command or process for OJS.

Is it the right time to upgrade? 

We strongly suggest to all of our clients to halt the upgrade of the new release of minor versions of OJS such as from the transition from 3.3.x to 3.4.x which is called the minor change or upgrade. The safest version currently is 3.3 latest that we find no urgent bug on that version.

As we explore and tested this version on our client and environment, we found that many of the plugins or theme is not supported with this version. Rather than that we have seen many reports from the OJS user that have upgraded their OJS with a “Fatal Error” or Blank page after they use the frontend or the common workflow. 

Yes, We agree that our suggestion to pending the urge to upgrade the OJS may have become counterproductive with the adoption of the new software. However as we take the side of our client and most of the OJS users, we highly recommend PKP as the main maintainer of the OJS software to test the new release and invite another user to give feedback before officially releasing it to the community since it becomes counter-productive to them.

Here is a list of bugs currently reported by the first adopters of OJS 3.4.0.1 :

1. In the submission process, the author sometimes cannot continue in the workflow due to a fatal error (urgent bug)
2. The profile page of the user cannot be accessed as it is shown a fatal error
3. The process that often resulted in a fatal error
4. Text Editor Extra that results in a fatal error
5. Announcement list gets mixed in the multi journals environment when the journal manager showing in the backend
6. Authors Unable to Initiate Discussion in Workflow
7. OAI Validation error as you can see here
8. The list of compatible plugins in 3.4 version can be checked here: https://pkp.github.io/plugin-compatibility/index.html

Although we do not strongly upgrade your OJS, our team has worked so hard to make our product fully compatible with OJS/OMP 3.4. At this time we believe that we are the only provider committed to the long-term support for our product. If you still get the 1-year free upgrade, you can directly upgrade the theme/plugin in the OJT Control Panel.

References :

https://docs.pkp.sfu.ca/dev/release-notebooks/en/3.4-release-notebook#client-charset

Muhammad Hendra

Project Manager

Hendra here, I love writing about OJS and share knowledge about OJS. My passion is about OJS, OMP platform and doing some research on creating innovated products for that platform to help publisher to improve their publication.