Upgrade from OJS 2.4.7 to 3.0.1 fails


Isn’t there any update on this issue yet?


Hi @asmecher,

Will there be a fix for this issue in 3.0.2?


Hi @salehig,

I’m afraid not – I’m just wrapping up the OJS 3.0.2 release now – but I’ll try to have a look at this shortly, and if need be, will prepare a patch to apply to 3.0.2 to address any issues that turn up.

Alec Smecher
Public Knowledge Project Team

1 Like

Hi Alec
I have recently taken over from Ghazal Salehi (@salehig ) as she has gone on maternity leave for remaining part of this year. Our OJS upgrade from v2.4.6 to v3.0.1 is still due till this issue of upgrade script failure is resolved. Can you please let me know any update on this issue resolution?
Thanks & kind Regards
Sunil Sinha ( s2.sinha@qut.edu.au)

Hi @sinhsu,

I’ve managed to replicate the problem locally thanks to @Oberdan’s database dump, but haven’t had the time to dive into it thoroughly. It’s high up on my to-do list; thanks for your patience.

Alec Smecher
Public Knowledge Project Team

Hi all,

Thanks for your patience. I’ve wrangled through @Oberdan’s database dump and it appears that there is a data error in the OJS 2.4.x data: some of the articles don’t have a valid section.

To check for articles in this situation, run the following in your database:

SELECT a.article_id FROM articles a LEFT JOIN sections s ON (a.section_id = s.section_id) WHERE s.section_id IS NULL;

This will generate a list of article IDs for which a section is needed. You can either go in via the OJS 2.4.x workflow and assign them, or you can edit the database directly. (If working with the database directly, make sure that the section_id you use belongs to the journal the submission is in.)

Once you’ve corrected the data error, take a fresh backup of the database and files area and try the upgrade again.

Alec Smecher
Public Knowledge Project Team



The SciELO OJS has 3976 sections in this situation.

mysql> SELECT a.article_id FROM articles a LEFT JOIN sections s ON (a.section_id = s.section_id) WHERE s.section_id IS NULL;
| article_id |
| 109 |
| 843 |

| 137276 |
| 137439 |
3976 rows in set (0.38 sec)

It is a huge number of records to fix them through the interface.

Do you have any suggestion to try to fix these gaps in a fast and secure way?

Hi @fabiobatalha/all,

The first thing to do is establish a policy on how, from a content perspective, you want to assign these articles. Is there already a consistently-named and suitable section in the journals that you want to assign these articles to? Do you want to create a new section for each journal?

Since you have so many journals, the most expedient approach is probably to create a new section for each journal, directly in the database. You can do this with:

INSERT INTO sections (journal_id, seq, editor_restricted, meta_indexed, meta_reviewed, abstracts_not_required, hide_title, hide_author, hide_about) SELECT journal_id, -9999, 1, 1, 0, 1, 1, 0, 1 FROM journals;

This will create a new section for each journal. The seq value of -9999 will cause the section to be listed very high in the table of contents (I suspect you’ll need to preserve the order of article display) but we’re also going to use it below as a convenience to help find these new sections when populating the other data needed.

Now you’ll want to give a title to each section:

INSERT INTO section_settings (section_id, locale, setting_name, setting_value, setting_type) SELECT section_id, 'en_US', 'title', 'New Section Title Here', 'string' FROM sections WHERE seq=-9999;

The above example sets the English (en_US) title to “New Section Title”; adjust the locale and title to suit, and repeat the query as many times as you need for multiple locales. Make sure you provide at least a value in the journal’s primary locales.

Now you’ll need to do a multi-table update in order to assign the unassigned sections to the new sections:

UPDATE articles a LEFT JOIN sections s1 ON (s1.section_id=a.section_id) LEFT JOIN sections s2 ON (a.journal_id=s2.journal_id AND s2.seq=-9999) SET a.section_id=s2.section_id WHERE s1.section_id IS NULL;

NOTE: I’ve run these queries but not tested them comprehensively. Please make sure you have a good backup before executing them, and before going live with the data corrected this way, make sure to review it within the installation to ensure it looks OK.

(These queries are intended for execution on the OJS 2.x database, prior to running the upgrade script.)

Alec Smecher
Public Knowledge Project Team

Hi @asmecher

It works fine for me!

Finally every journal migrated to 3.0.2 version!!

Hi @fabiobatalha,

Excellent, congratulations!

Alec Smecher
Public Knowledge Project Team

Hello @asmecher

Sorry about the long delay replying to this… I had to stop working on the upgrade for a few weeks. After the section ids were corrected the upgrade worked. Thanks!



Hi @Oberdan,

Thanks for following up!

Alec Smecher
Public Knowledge Project Team

Hi @asmecher
for me instead the php error log message is

PHP Warning: assert(): Assertion failed in /var/www/vhosts/geospatialhealth.org/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 285
<h1.>Invalid file!</h1.>ojs2: Invalid file!

I put the point to have the code displayed.
How I should I proceed? I updating from to

This is php log:

[load: upgrade.xml]

[code: Installer Installer::checkPhpVersion]

[code: Installer Installer::syncSeriesAssocType]
[data: dbscripts/xml/upgrade/2.4.0_preupdate_usageStatistics.xml (skipped)]
[data: dbscripts/xml/upgrade/2.4.0_preupdate_usageStatistics2.xml (skipped)]

[code: Installer Installer::removeReviewEntries]
[data: dbscripts/xml/upgrade/3.0.0_preupdate.xml]
[data: dbscripts/xml/upgrade/3.0.0_adaptTimedViews.xml (skipped)]
[data: dbscripts/xml/upgrade/3.0.0_adaptReferrals.xml]
[data: dbscripts/xml/upgrade/3.0.0_adaptBooksForReview.xml]
[data: dbscripts/xml/upgrade/remove_timed_views_bots.xml (skipped)]
[data: dbscripts/xml/upgrade/3.0.0_preupdate_commentsToEditor.xml]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_review_assignments.xml]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_notes.xml]
[data: dbscripts/xml/upgrade/3.1.0_preupdate_payments.xml]
[data: dbscripts/xml/upgrade/3.1.1_preupdate_citations.xml]
[schema: lib/pkp/xml/schema/common.xml]
[schema: lib/pkp/xml/schema/log.xml]
[schema: lib/pkp/xml/schema/announcements.xml]
[schema: lib/pkp/xml/schema/scheduledTasks.xml]
[schema: lib/pkp/xml/schema/temporaryFiles.xml]
[schema: lib/pkp/xml/schema/metadata.xml]
[schema: lib/pkp/xml/schema/reviews.xml]
[schema: lib/pkp/xml/schema/reviewForms.xml]
[schema: lib/pkp/xml/schema/controlledVocab.xml]
[schema: lib/pkp/xml/schema/submissions.xml]
[schema: lib/pkp/xml/schema/submissionFiles.xml]
[schema: lib/pkp/xml/schema/notes.xml]
[schema: lib/pkp/xml/schema/views.xml]
[schema: lib/pkp/xml/schema/genres.xml]
[schema: lib/pkp/xml/schema/tombstone.xml]
[schema: lib/pkp/xml/schema/rolesAndUserGroups.xml]
[schema: lib/pkp/xml/schema/metrics.xml]
[schema: lib/pkp/xml/schema/views.xml]
[schema: lib/pkp/xml/schema/libraryFiles.xml]
[schema: lib/pkp/xml/schema/navigationMenus.xml]
[schema: dbscripts/xml/ojs_schema.xml]
[data: dbscripts/xml/indexes.xml]

[code: Installer Installer::installDefaultNavigationMenus]

[code: Installer Installer::migrateStaticPagesToNavigationMenuItems]

[code: Installer Installer::migrateSRLocale]

[code: Installer Installer::concatenateIntoAbout]

[code: Installer Installer::concatenateIntoMasthead]

[code: Installer Installer::migrateCounterPluginUsageStatistics (skipped)]

[code: Installer Installer::migrateTimedViewsUsageStatistics (skipped)]

[code: Installer Installer::migrateDefaultUsageStatistics (skipped)]
[data: dbscripts/xml/upgrade/2.4.0_postUsageStatsMigration.xml (skipped)]
[data: dbscripts/xml/upgrade/2.4.0_postUsageStatsMigration2.xml (skipped)]
[data: dbscripts/xml/upgrade/2.4.0_postCounterMigration.xml (skipped)]
[data: dbscripts/xml/upgrade/2.4.0_postTimedViewsMigration.xml (skipped)]
[data: dbscripts/xml/upgrade/3.0.0_change_assoc_type.xml]
[data: dbscripts/xml/upgrade/3.0.0_change_assoc_type_metrics.xml]
[data: dbscripts/xml/upgrade/3.0.0_settings.xml]

[code: Installer Installer::installDefaultGenres]

[code: Installer Installer::migrateArticleMetadata]
[data: dbscripts/xml/upgrade/3.0.0_update.xml]

[code: Installer Installer::clearDataCache]

[code: Installer Installer::migrateUserRoles]

[code: Installer Installer::fixReviewForms]

[code: Installer Installer::htmlifyEmailTemplates]
[note: docs/release-notes/README-BEACON]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::installEmailTemplate]

[code: Installer Installer::installEmailTemplate]
[data: dbscripts/xml/upgrade/3.0.0_scheduledTasks.xml]

[code: Installer Installer::localizeCustomBlockSettings]

[code: Installer Installer::convertEditorDecisionNotes]

[code: Installer Installer::convertQueries]

[code: Installer Installer::migrateFiles]

[code: Installer Installer::convertSupplementaryFiles]

[code: Installer Installer::provideSupplementaryFilesForReview]
PHP Warning: assert(): Assertion failed in /var/www/vhosts/geospatialhealth.org/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 285
<h1.>Invalid file!</h1.>ojs2: Invalid file!

Thanks for any help


Hi everybody,
any help?

Hi @Tiziano

Do you have any file without revision or with revision = 0 or NULL in your database table article_files?


Hi @bozana,
I checked and in the “revision” column the minimum number is 1. There is no one with number 0.
Is this the reason for the error?

Thanks for help.


Hi @Tiziano

Probably there is a reason for the error, we just have to figure it out :slight_smile:
If the revision is not the problem: is there maybe an entry in your DB table article_supplementary_files that contains a file_id that is not in the table article_files (but where remote_url is not null)? – Could you execute this SQL and post the results:
SELECT * FROM article_supplementary_files WHERE file_id NOT IN (SELECT file_id FROM article_files)


I have run the SQL and the result is this:



Hmmm… that looks OK :-\

Could you then please also execute this SQL:
SELECT a.journal_id, sf.* FROM article_supplementary_files sf, articles a WHERE a.article_id = sf.article_id AND sf.show_reviewers = 1 AND sf.remote_url IS NULL


Ah, sorry, now I see – your results contain for some files with file_id = 0 (without the file), although they are not remote files.
I will patch the SQL to consider that as well…