Currently there are many universities or organizations that have several journals from different OJS with the use of servers and different versions of OJS even though the journals are under the auspices of the same organization and manager, gradually this will certainly become a problem for journal managers in managing journals. to equalize the quality of the journal, in terms of site accessibility, site security, OJS version, compatibility of using plugins and several other problems that make it difficult for the main journal manager to achieve a goal to produce a journal site that has reliable access quality, good security and similar versions. in managed journals.
Problem with Native Export – Import data
Actually, the feature for merging the two OJS is already available in one of the export – import features, namely the following features:
But unfortunately this feature only performs export-import related to issue data, articles and users only. This feature does not record activity logs, metrics related to the number of downloads and views as well as workflow processes that occur in the journal to be merged. In the PKP roadmap itself, it is not certain which version they will launch this feature on in OJS, because there are several priorities that PKP thinks are more urgent so they won’t be able to launch this feature in the near future. So currently the OJS merge process can only be done manually by using the export – import method in OJS and making changes to the database manually.
- What we learned when we migrated journal into the OJS consisted of 94 journals.
- The beginning
- Detail results OJS Merge
- Workflow OJS Merge
- How to merge the OJS to another OJS?
- 1. Upgrade to match the Journal version
- 2. Create Journal
- 3. Copying the contents of the journal to be merged
- 4. Create a staging server
- 5. Export dan import data submission journal
- 6. Export dan import user data
- 7. Re-Assign author on submission article
- 8. Carry out the review process on article submission
- 9. Fixing Statistik of abstract and the download counter article
What we learned when we migrated journal into the OJS consisted of 94 journals.
Some time ago, there was an initiation from one of the largest universities in Indonesia, Universitas Airlangga. They intend to carry out journal management in one campus command so that the maintenance process can be carried out in a more centralized manner.
Before we continue this article, we need to mention that there are some important notes, in this case the shortcomings that need to be considered from this OJS combined activity.
- Article ID changed
- There are some components that are not merged and the transfer process must be done manually.
- Journals can be offline for some time to ensure that there is a similarity of data between previous journals and destination journals.
- Change of destination url of DOI (need to do manual change request activity to DOI provider like Crossref).
Of course, it will take time to merge this journal because the merge process is done manually and step by step. Currently we have successfully merged journals at Universitas Airlangga which have (OJS2x – 94 Journal) (OJS2x-1 Journal) (OJS 3.2x – 4 Journal) ( OJS3.3x – 1 Journal).
Because this process is done manually, in this merged journal which will not have the same thing as the previous journal, here are the details that you and your team can take into consideration in the OJS merge process:
1. The journal link after the merge will change and automatically the DOI link on the article when accessed will lead to the old journal.
To solve this problem you can apply crossref to fix this problem.
2. In order to be able to do a merge, we also have to upgrade the journal, where the similarity of this journal is needed for the article and user export process so that it can run well on the journal that we want to merge.
3. Always do a backup before doing this process.
Note that OJS mergers should be done by professional and experienced staff. There may be many errors that you will encounter during the activity. We don’t take any responsibility for any result caused by the tutorial explained in this article.
- Before initiating the activity process please backup your OJS sites and database to the external drive.
- Although we have shared the detailed step to doing activity in this article, we don’t provide any guarantee or responsibility for the result
- Advanced activity including OJS merges should be done by a professional and experienced since the failed process can make your OJS and its database corrupted
- This article is not intended as a form of advice for the case you are facing. This article only describes the steps we have encountered in the cases we found.
Detail results OJS Merge
This merge process can also carry out all the details of data transfer for each article that has been published or is still in the review and submitting process with detailed results as follows:
- Moving statistical content on the front page of OJS such as sidebar menus, journals, and other static content.
- Transferring article data with the status of publishing, review, copyediting, and submitting with document data that will remain the same using native export XML tools in OJS 3.3xx.
- Transferring users with the same role using native user XML tools in OJS 3.3xx
And at this time we also found some shortcomings in the results of the merge that was done manually:
- In the article that we moved, the user was not assigned automatically, so we had to do the assigned process manually.
- If there is a review, submission, or copyediting process that you want to move, you have to do the process manually one by one manually, at this time we have not found the right method to automate this process.
- Statistical data on each published article will be 0.
- The date in the statistics will be reset to the date when you import data into the journal.
Workflow OJS Merge
This merge process will be carried out manually using several stages of the process with a workflow description as follows:
How to merge the OJS to another OJS?
After you have finished preparing the journals you want to merge, here are the detailed steps for the OJS merge process:
In this OJS merge process, you have to make sure that the version of OJS that will be merged has the same version, because in OJS itself each version has a different submission structure. Most likely this will cause an error in the article transfer process when using export or import tools in OJS.
So, I highly recommend that you use OJS with the same version.
For details on the upgrade process you can visit the following tutorial:
In the following tutorial, we will explain in detail the process of upgrading OJS version 2 to OJS version 3. xx (latest version)
1. Upgrade to match the Journal version
In the following tutorial, we will explain in detail the process of upgrading OJS version 3 to OJS version 3. xx (the latest version)
Note: After completing the OJS upgrade process, please make sure again that the results of the OJS that we have upgraded can all function normally.
2. Create Journal
So that later the merged journal has the exact same appearance and function as the previous journal, you also have to make sure the OJS version you create is the same as the OJS upgrade. For details on the journal installation process on the server / cpanel, you can visit the following tutorial:
Note: Please make sure you make the latest version of the journal on PKP
3. Copying the contents of the journal to be merged
When you have finished creating a new journal, the next step is that you need to edit some journal settings that contain text or image content on the front page or on the OJS workflow itself. Here are some details of the content you need to load so that the new OJS content has the same content:
- Static content ( Description Journal, editorial team, header journal)
- Custom block menu
- Static page
- Import and export all article
4. Create a staging server
After the upgrade process is complete and you are about to enter the journal migration stage, we strongly recommend that you create a staging server, which you can use in the data import process and trial error journal, because we are importing export data, there is a possibility that you will experience errors.
5. Export dan import data submission journal
When you have finished making adjustments to the appearance of the journal, then you can import the article using the tools in OJS.
For the first stage, we will export articles first to the old journal, in the following way:
Tools – Import Export – Native XML Plugin
Export Articles: You can export articles that have been published or with the status of review, copyediting, submission. With this tool, the review process and the results of the discussion on the submission will not be transferred to the new journal.
Before you export, you can filter the articles you want to display for export.
Then to filter the articles you want to export based on the submission category, you can click on the filter.
The following screen displays all the articles in your journal. After the article you want to export is selected, click export article.
Here are the export results in the article
Export Issue: with this tool, we can perform a complete export issue along with the articles that have been published in the issue.
Import issue: Later this import tool is used for new journals that you want to migrate, you can import articles or import issues.
6. Export dan import user data
With this tool, you can export and import users with the same roles. By visiting the following tools:
Tools – Users XML Plugin: Import and export users
Note: If you experience duplicate errors after importing, don’t panic! when the user has the same username/email, then the import process for that user will fail, because the OJS system cannot have the same username or email between users.
When we import submissions between journals, the submission and author processes in the journal will be empty. Therefore, for every submission that we import and the submission has had a review process, we will do the re-assignment process manually.
Note: Before you re-assign the article, you must first do the export-import user process.
To add a participant, click assign to the article.
8. Carry out the review process on article submission
All process review processes on article details must be done manually to equalize the details of each process.
Note: Please note that when this process is carried out, we strongly recommend that the OJS admin urge all journal managers to temporarily stop the submission process so that there are no content differences between OJS that will be merged.
9. Fixing Statistik of abstract and the download counter article
In OJS 3.3x submissions, which have been imported, statistical data for articles appearing on the OJS page will be reset to 0.
To fix this statistical display problem, you can do it manually by editing the journal database, in the following way:
You must collect all the following data in the metrics database table with the following steps:
- Record the Submission id file galley in the new journal and the old journal
- Record the Submission id in the new journal in the old journal
- Write down the Section id in the new journal and the old journal
- Record Journal id in the new journal and the old journal
- Export new metrics journal data
- Perform editing by replacing new data using the data in the metric table that has been recorded
- Merge data on table metrics
- Fixing tanggal detail pada submission yang masih dalam proses review
When the import submission process is in a new journal, all review processes contained in submissions with the status of the review, copyediting, published, and decline will be lost, so that the submission process can continue in the new journal, the admin journal must perform the review process manually one by one and replace the dates one by one corresponds to the date of the review process in the old journal, yes it sounds very a lot of jobs, unfortunately, until now we have not found a method to perform the automation process. Here are some points for you to pay attention to in making changes to the date of the submission details that you must make changes to:
Submission files :
Submission files are all files uploaded in the process of submission, you can find this file submission in the submissions, revisions, review, and copyediting tabs. To change the upload date for a submission file, you must record the submission id, then change the date manually using the.
Generate Date changes submission file id:
|UPDATE `submission_files` SET `updated_at` = ‘2022-03-10 05:36:00’ WHERE `submission_files`.`submission_file_id` = files_id;|
Discussion ( Note date )
The discussions that are replaced here are all types of discussions in each submission flow, such as: Pre-review discussions, Review Discussions, and Copyediting Discussions. To get an id for each discussion, you can run the following script to display all id results for all submissions in your journal with the status of the review, copyediting
|select n.note_id, n.title, n.contents, n.date_created, n.date_modified, s.submission_id from notes n, queries q, submissions s where s.context_id = (Change with your Journal ID) and s.status = 1 and (s.stage_id = 4 or s.stage_id = 3 or s.stage_id = 1) and q.assoc_type = 1048585 and q.assoc_id = s.submission_id and n.assoc_type = 1048586 and n.assoc_id = q.query_id;|
Then once you get the id, you can adjust the date using this script.
|UPDATE `notes` SET `date_created` = ‘2022-02-27 13:49:30’ WHERE `notes`.`assoc_id` = your_note_id;|
That’s it. When you have finished doing all the steps above, the next step maybe you can match the results of the journal migration data, for statistical journal data you can check randomly on several articles contained in journal publications that have been migrated, for submissions you can also check on several articles that are in the review process on journals that have been completed in the migration.
Conclusion: To do this journal migration process takes time and a team must be committed to carrying out the process so that the journal migration process is 100% successful, I also remind you that this migration process is not recommended on a live server, because of the possibility of the migration process causing missing Replacing data so that the detailed data in the article becomes inaccurate. We strongly recommend that the migration process is carried out on the staging server that you have provided previously.