Upgrade from OJS 2.2.4 to 2.4.8 Error

Hi @RickMath,

This suggests that the copyed_assignments table doesn’t exit in your OJS 2.2.4 database. It should – I suspect something has happened in your database backup/restore process, or that your config.inc.php is still pointing at the wrong database.

After restoring your 2.2.x database and checking your config.inc.php, try connecting to MySQL manually, using the credentials in config.inc.php, and ensuring that the copyed_assignments table exists. It definitely should with a 2.2.4 database.

Alec Smecher
Public Knowledge Project Team


I have attached two screen shots before and after the attempted upgrade.

copyed 1,jpg is before and copyed 2.jpg is after.

What should we check for in the config.inc.php?

I checked the database before I gave them the go ahead and the table was there.

We can try again but any further suggestions would help. We do not assign copyeditors so the id is zero as you can see in the first shot. I have checked the articles table and the copyed_assignments tables for ids in the assignments table that do not exist in the articles table.

Copyed 1
Copyed 2


I did check the config.inc.php file and the correct database is there.

Sorry for not checking this before the previous reply.

I received this from the hosting service. Also see above the apparent attacks to the forum.


I have further tested the upgrade and found that the exact error is below :


A database error has occurred: Table 'jamtorg_ojsnew.counter_monthly_log' doesn't exis


From what i can see the table counter_monthly_log doesn’t exist in the jamtorg_old database as well and possible this is causing the issue with the upgrade. Please provide this detail to support forum and see what they have to say.

I also received this.


I have tried once again using a new copy of database ‘jamtorg_ojsnew’ and found that after running the upgrade script, the database table copyed_assignments is missing from the database. I think this is causing the error with the upgrade. Somehow the database table is getting removed after running the upgrade script.

Hi @RickMath,

I’m a little concerned by the number of different outcomes on an apparently repeated process – when the process is repeated consistently, the same outcome should result. If you’re varying the environment as you test it’ll be extremely hard to debug any issues you hit along the way.

The copyed_assignments table should exist before the upgrade, and should be removed as part of the upgrade process. (The data, if any, gets migrated elsewhere.)

The counter_monthly_log table should also exist in an OJS 2.2.x installation (it’s part of the Counter plugin, which ships with OJS 2.2.4). However, if that plugin is disabled, your system will have operated OK without it. To create it, run the following SQL. (Again, do this after restoring the DB from backup but before executing the upgrade script.)

CREATE TABLE counter_monthly_log (
year                     BIGINT NOT NULL,
journal_id               BIGINT NOT NULL,
count_jan                BIGINT NOT NULL DEFAULT 0,
count_feb                BIGINT NOT NULL DEFAULT 0,
count_mar                BIGINT NOT NULL DEFAULT 0,
count_apr                BIGINT NOT NULL DEFAULT 0,
count_may                BIGINT NOT NULL DEFAULT 0,
count_jun                BIGINT NOT NULL DEFAULT 0,
count_jul                BIGINT NOT NULL DEFAULT 0,
count_aug                BIGINT NOT NULL DEFAULT 0,
count_sep                BIGINT NOT NULL DEFAULT 0,
count_oct                BIGINT NOT NULL DEFAULT 0,
count_nov                BIGINT NOT NULL DEFAULT 0,
count_dec                BIGINT NOT NULL DEFAULT 0,
count_ytd_total          BIGINT NOT NULL DEFAULT 0,
count_ytd_html           BIGINT NOT NULL DEFAULT 0,
count_ytd_pdf            BIGINT NOT NULL DEFAULT 0

ALTER TABLE counter_monthly_log ADD  UNIQUE INDEX counter_monthly_log_pkey  (year, journal_id);

Alec Smecher
Public Knowledge Project Team



We will try this and get back. I do not think we have varied the environment. We just have been cleaning up tables with ids that do not match.

We appreciate your patience.



SUCCESS!!! See comment below from tech support.

Thanks and can we go all the way from here to 3.1.1-1

Rick :grinning:

Whoops forgot the comment in my elation.

ERROR: Upgrade failed: DB: Duplicate entry ‘EDITOR_DECISION_ACCEPT-en_US’ for key ‘email_templates_default_data_pkey’

I had to empty the email_templates_default_data table in order to proceed.

Hi @RickMath,


I do worry that you’ll find yourself without the workflow email texts if you’ve emptied the email_templates_default_data table – I would suggest re-installing your language. From your “Languages” tab in Settings, use the “Reload defaults” action on each language you’re using to accomplish this.

Alec Smecher
Public Knowledge Project Team


I do not see where to do this. Is it part of Setup for the Journal manager?

We tried to upgrade to 3.1.0-1 and received the error below.

DB Error: Data too long for column ‘contents’ at row 1

So, I changed the type of contents row of the table notes from text to longtext, but it didn’t help.

Another question

Should we be upgrading to 3.1.1 rather than 3.1.0-1

Hi @RickMath,

OJS 3.1.1 hasn’t been released yet – the latest is currently OJS 3.1.0-1. (Are you seeing OJS 3.1.1 available somewhere? It might be a typo.)

The only place I could think of a contents column being a problem is in the notes table. I suspect you have some problem content there, perhaps a spam submission or something, as the TEXT column should already be big enough to hold it. But to migrate that content using a LONGTEXT, edit lib/pkp/xml/schema/notes.xml, find the definition of the contents column:

<field name="contents" type="X"/>

…and change the type from X to XL. Then restore your 2.4.8 database and re-run the upgrade.

I would suggest checking what the long content is there after performing the upgrade to see if it’s some kind of exotic spam or something.

Alec Smecher
Public Knowledge Project Team


I checked the notes table and there are no records.

Also I do not see where to make the changes mentioned a few posts ago on the email_templates_default_data table

We will try the change to the contents field and get back.

I thought I saw a post on 3.3.1 Must have been a typo.

We tried again and received this

[code: Installer Installer::moveReviewerFiles]
There are no readable files in this directory tree. Are safe mode or open_basedir active?

Hi @RickMath,

There are a few other threads with suggestions for this message; see e.g. this one. It’s likely that you’re encountering yet another data error in your old 2.x install.

Alec Smecher
Public Knowledge Project Team

We found three articleIDs that did not have sections, they were null. We corrected this with section numbers.

The installation of 3.1.0-1 was partially completed. We can get to the site administration page with http://www.jamt-online.org/OJS/index.php/ and log in with the administrator account. When we use http:/jamt-online.org/OJS/index.php/JAMT/ we get a 404 error. The JAMT path is in the admin page as it was before.

The stack trace is
Stack trace at http://www.jamt-online.org/OJS/index.php/JAMT/ is currently showing following :

File: /home/jamtorg/public_html/OJS/lib/pkp/classes/core/PKPPageRouter.inc.php line 197
Function: Dispatcher->handle404()

File: /home/jamtorg/public_html/OJS/lib/pkp/classes/core/Dispatcher.inc.php line 134
Function: PKPPageRouter->route(Object(Request))

File: /home/jamtorg/public_html/OJS/lib/pkp/classes/core/PKPApplication.inc.php line 243
Function: Dispatcher->dispatch(Object(Request))

File: /home/jamtorg/public_html/OJS/index.php line 68
Function: PKPApplication->execute()

I am not sure what to do at this point. I can see users, roles and the other system information on the admin page so all of that is OK.



I enabled the journal to appear publicly on the edit page. When I did the journal was visible and I could see issues and the current issue.

There is no login area or anything else.

When I close the page and tried to open the admin link all I could get was the journal page. I went to the journal table and enabled was set to 1. I set it to 0 and was able to get back to the admin page.

Is this related to the stack trace notices that appear in my last post?

Thanks we are making progress.

Hi @RickMath,

Are you sure the upgrade completed successfully? If it did, you should have received a confirmation message saying so. If the processess stopped with an error, or stopped without confirming that it had completed, your journal might not be fully upgraded and some data errors can result.

The 404 error is explained by the journal being disabled.

When your journal is enabled, and you only have a single journal, the administration tools are mostly folded into Journal Setup, so you likely won’t see them in a separate Administration area. This was done because many of our users only work with a single journal, so the separation of Administration (site-wide) from Setup (journal-specific) was confusing.

The missing login areas etc. might be explained by an incomplete upgrade, but I’d also suggest checking your PHP error log to see if there are any useful details there.

Alec Smecher
Public Knowledge Project Team


I looked at the error log under our public_html follder. We had a front end to www.jamt-online.org that was written by our site admin. www.jamt_online.org/OJS I think pointed to the OJS system. The error log is very long and contains references to php and other files in that front end that is outside of the OJS folder.

I wonder if this is causing the problem with the upgrade failure. I thought about being able to get to the site admin page. If we remove all the frontend files and folders above the OJS folder will we have a problem?

I hope this makes sense.

Thanks for you patience.