Error message during upgrade of ojs 2.3.7 to 2.4.1

[dankomed]

Dear Team,

I have followed all the steps for updating ojs using the complete ojs.2.4.1.tar.gz package. I backed up the mysql databse, then change the name of the /ojs folder (of the current journal installation) to ojs-237, and rename ojs-241 folder to /ojs. I moved the /cache and /public folders, the files_dir is outside /ojs, and modified the config.inc.php from the ojs 2.4.1 verion so that I input the correctly installed fields from the old config.inc.php file. In addition, I gave read and write and execute permissions to all these files (and also the upgrade.php file from the /tools folder). Finally, I turn off the installation.
I correctly see the upgrade link, and click to upgrade the mysql database. I obtain this error:

Errors occurred during installation:
A database error has occurred: Table 'notification_settings_old' already exists

Is it possible to guess from the above message what went wrong. I tried 3-4 times to update, and the same message is obtained. The mysql database is also corrupted, but I can restore it, then rename back the /ojs-237 folder to /ojs and the old journal installation works. So, I verify that the mysql database before the update works well. Something else is going on, but I can't figure what.

[asmecher]

Hi dankomed,

The only way that table can be present is if an upgrade was previously attempted but it failed part-way through. The easy way to "solve" the problem is to simply restore from backup, drop that table, and run the upgrade again -- but unless you have some idea what happened the first time the upgrade was attempted, it's impossible to guess whether you'll run into other problems.

Regards,
Alec Smecher
Public Knowledge Project Team

[dankomed]

Dear Alec,

Thank you for your suggestion. After some study, I was able to access my sql database via myPhpAdmin ob go daddy. Surprizingly, even after database restore, the extra entries ending with _old were present, e.g. articles_old, etc. I realized these were possibly a kind of backups due to previous unsuccessful database upgrade. Unfortunately, even after cleaning all these _old entries the upgrade procedure created Error:

A database error has occurred: Duplicate entry '7--pub-id::publisher-id' for key 1

In my sql database(0js 2.3.7) I have 116 entries. Is it possible that there is a new entry created by the upgrade, which does not have _old ending, so that it blocks the upgrade, or there is a problem in the original database that I can fix. Is it possible to understand from the error message which part of the sql table contains the problem, then I can manually try to edit the duplicate entry and delete it. Thanks

[dankomed]

possibly connected with the problem - some of the submissions to the journal were deleted (they were tests). Inside the journal, when logged in as editor, I see archived entries with IDs 3,4,5,6,8,9, and current in review with ID 11. The entry with ID 7 should be one of the already deleted.

[dankomed]

Well, the upgrade seems to be impossible. I tried deleting the published issue in the journal, but this did not improve anything. Just shortened the Error message to:

A database error has occurred: Duplicate entry '7' for key 1

So, I created a new mysql database "database2" and I was able to install ojs 2.4.1 with a new storage folder outside ojs "store2". So basically on my site I have two ojs systems installed using separate mysql databases and separate storage folders. The ojs 2.3.7 is installed in folder /ojs whereas ojs 2.4.1 is installed in another folder /ojs-241. I can open in parrallel both ojs installations in two different browser windows, so that I can manually synchronize their content after logging in in both ojs's as admin.

Because at this time I have only 1 published issue, I would like to migrate the pdfs, etc. manually, i.e. submit, skip review, directly accept and publish. My question is this: If I export all user connected tables e.g. "users", "users settings" etc. from the mysql database operating with ojs-237, will it work if I import them into the mysql database operating with ojs-241. The purpose is to save the discomfort of re-registration for my current users. I will be glad to have advice on proper way to migrate user accounts only without their submissions.

[dankomed]

I believe now that the upgrade problem is related to the fact that fresh independent instalation of ojs 2.4.1 on the GoDaddy server has problem with uploading .css files or image files. It complains that either the file is not the correct format or the upload failed. The permission to write to all relevant folders are given, so I suspect something is going on with the mime settings. I am wondering what new is added to ojs 2.4.1 that it does not work, while ojs 2.3.7 works.
Previous topic viewtopic.php?f=3&t=2892 mentioned possible fix to classes/core/String.inc.php, but this file is not available neither in ojs 2.3.7, nor ojs 2.4.1.

[asmecher]

Hi dankomed,

That file is located in lib/pkp/classes/core; the same potential methods of determining a MIME type are present, but have been re-arranged between the two versions.

Regards,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi dankomed,

Note that depending on what tools you use restoring a database from backup will give you a different result than deleting and re-creating the database first. It's generally cleaner if you delete and re-create the database before running a restore, because otherwise you may have leftover tables, sequences, etc.

Regards,
Alec Smecher
Public Knowledge Project Team

[dankomed]

Dear Alec,

I have dropped all tables in the mysql database, then restored it - it contain 116 tables. Then I moved the /cache and /public folders to new ojs 2.4.1 folder (unzipped tar.gz complete package). I modified the new config.inc.php and also the String.inc.php (to eliminate mime problems).
Unfortunately the database upgrade failed with the same message as before:

A database error has occurred: Duplicate entry '7--pub-id::publisher-id' for key 1

Can you tell me what tables the above message refers to, so that I inspect for weird entries? I checked the "published articles" table in mysql without finding anything wrong with the pub_id collumn.

[asmecher]

Hi dankomed,

If you turn on the show_stacktrace message in config.inc.php and try that process again, you should get a stack trace that indicates what table / where in the code the problem occurred. Alternately, another way of getting the same information is to turn on the "debug" setting -- but you'll have to do that just before you hit the "Upgrade" button or you'll be wading through a lot of DB queries on your way there.

Regards,
Alec Smecher
Public Knowledge Project Team

[dankomed]

Dear Alec, the error was not removed by show_stacktrace on. However, strangely, when I restored the mysql database, and tried to upgrade with debug = on I received a long list of messages and finally "Upgrade of OJS to version 2.4.1.0 has completed successfully. Don't forget to set the "installed" setting in your config.inc.php configuration file back to On."
I have previously been able to upgrade without error message once, but checking the published vol 1 issue 1 was indeed corrupted. I tried to open an article and it says: "Fatal error: Call to undefined method PublishedArticle::getDOI() in /home/content/517/6xxxxxxxxx2/html/ojs/cache/t_compile/%%28^280^280EE005%%dublincore.tpl.php on line 79"

I am now trying to delete the published issue and re-publish again, but the created new issue does not show button "Publish". Should I discard something from the ojs cache?

[asmecher]

Hi dankomed,

Neither the debug or show_stacktrace options would've caused the upgrade to complete successfully where it failed before; they are information-only options so I'm not sure what happened differently this time. The problem you're encountering now is because of permissions problems in the cache/ subdirectory. That directory (and everything it contains) needs to be writable by the user account your web server uses to run your PHP scripts. (This will depend on your server's configuration.) I would suggest deleting cache/*.php and cache/t_compile/*.php, correcting your file permissions on cache/ and its contents, and checking that page again.

Regards,
Alec Smecher
Public Knowledge Project Team

[dankomed]

Dear Alec, finally the problem is Solved! Actually, I was able to update and reach the same status with corrupted first issue before. I was not aware that the problem requires cleaning/blanking up the php cache. Why then for upgrading the users are advised to copy the old /cache folder into the new ojs 2.4.1 complete package? Or, at least it is worth to be stated in the Read Me notes that the .php cache can safely be cleaned up and then it will be regenerated, etc.
In my case, after I cleaned the .php files in both the /cache folder outside of t_compile and everything within t_compile, I was able to publish again the vol.1 issue 1 using the accepted articles, which were automatically returned to Editing status after I deleted the published issue.
Despite of all the troubles (and many useless activities, which I did over and over again in the past days), I am satisfied that finally the ojs was upgraded. Thanks for the provided expert guidance. Next, i will try fixing the ISSN export issue, which was my primary concern and lead me to upgrading.

[asmecher]

Hi dankomed,

Great, glad to hear it's been successfully upgraded. The template cache should actually take care of itself, but many users run the system with file permissions in cache/t_compile set so that OJS can't manage those files. This will work just fine until the system is upgraded, when suddenly OJS won't be able to update the compiled templates and things will stop working as you saw. I think a permission check during install/upgrade would probably help to prevent this kind of thing; you aren't the only one to have run into it.

Regards,
Alec Smecher
Public Knowledge Project Team