Issue in upgrading OJS 2.4 to OJS 3.x

jcalabe · October 25, 2017, 11:16am

Hi Team,

I am facing this error while upgrading the OJS version from 2.4 to OJS 3.1.

“Errors occurred during installation: A database error has occurred: Table ‘article_galleys_stats_migration’ already exists”

I analyzed this error and I noticed that this error may occur because of the earlier upgrade process. But I did not do any upgrade to my website earlier. So please advice to fix this issue.

Best regrads,
-Calabe

ajnyga · October 25, 2017, 11:39am

If you are 100% certain that there was no previous upgrade attempt, then I guess you could try just deleting (or renaming) the ‘article_galleys_stats_migration’ table.

However, I find it hard to believe that the table would exist there because of any other reason. Unless the upgrade script from 2.x to 3.1 is trying to create it twice @bozana?

Before any upgrade attempt you should always backup both the database and the files (OJS files and submission files). OJS3 upgrade will move things around in your files directory so after an unsuccesful upgrade attempt you should restore the files directory from the backup.

bozana · October 25, 2017, 12:31pm

Yes, @ajnyga is correct.

That table is created here: ojs/upgrade.xml at ojs-3_1_0-0 · pkp/ojs · GitHub (s. ojs/2.4.0_preupdate_usageStatistics.xml at ojs-3_1_0-0 · pkp/ojs · GitHub). Then the migration is done if that table exists: ojs/upgrade.xml at ojs-3_1_0-0 · pkp/ojs · GitHub (s. ojs/Upgrade.inc.php at ojs-3_1_0-0 · pkp/ojs · GitHub). Then the table is removed ojs/upgrade.xml at ojs-3_1_0-0 · pkp/ojs · GitHub (s. ojs/2.4.0_postUsageStatsMigration.xml at ojs-3_1_0-0 · pkp/ojs · GitHub).

Thus, the DB table is not created twice.
So it’s strange that it is already there, if no upgrade attempt was made…

Best,
Bozana

jcalabe · October 26, 2017, 4:58am

Hi Team,

Thank you for your prompt reply. I will try deleting the table from the database.

Also, I have an issue in upgrading the OJS2 to OJS3. I have completed the upgrade the staging environment. But after upgrade the layout has totally changed and all the content & settings were deleted.

Please advice me to set up the same layout & template as like the OJS 2 website.

Thanks,
-Calabe

jcalabe · October 26, 2017, 5:11pm

HI Team,

I have tried by deleting the table from the database and I further proceed with the upgrade. But I am receiving this error when I proceed further with the OJS 3 upgrade.

+++
DB Error: Unknown column ‘issue_id’ in ‘field list’

Stack Trace:
File: /var/www/vhosts/[Site-name]/httpdocs/classes/install/Upgrade.inc.php line 639
Function: DAO->update(“INSERT INTO metrics (file_type, load_id, metric_type, assoc_type…”, Array(9), False)

File: (unknown) line (unknown)
Function: Upgrade->migrateDefaultUsageStatistics(Object(Upgrade), Array(2))

File: /var/www/vhosts/[Site-name]/httpdocs/lib/pkp/classes/install/Installer.inc.php line 415
Function: call_user_func(Array(2), Object(Upgrade), Array(2))
+++

Please advice to fix this issue with the OJS 3 upgrade.

Best regards,
-Calabe

bozana · October 27, 2017, 7:16am

Hi @jcalabe

Have you started the new update on your clean OJS 2.4.x database i.e. the one before any update?

As @ajnyga said: “Before any upgrade attempt you should always backup both the database and the files (OJS files and submission files). OJS3 upgrade will move things around in your files directory so after an unsuccesful upgrade attempt you should restore the files directory from the backup.”
This also gilts for the DB.

Best,
Bozana

Ranjan_Mohapatra · January 16, 2020, 12:46pm

I have a quick question. We took a backup for 10 journals and the size was 150 gb. Now Server space is very less, so we are thinking to download the backup files to our local system and migrate the same to OJS 3 on our local system for testing. Will this work on our local system. We have installed OJS2 and OJS3 separately to test this and they are working fine. So our doubt is if the migration will happen successfully on local system. Also will all the issue files will convert to latest version or I have to manually download the XML file and change the tag.

ctgraham · January 16, 2020, 2:13pm

Please don’t post the same question on multiple threads. Instead, search for the best existing topic or create a new topic as needed.

I’ve responded to your other post here:

Jnana_Rana · January 17, 2020, 2:35am

@ctgraham Need one more clarification related to the question which @Ranjan_Mohapatra has asked.

Suppose i have all the following backup from OJS2 as per pkp guide line 2.3.3. That is

[Making Backups of Your System](https://pkp.sfu.ca/ojs/docs/userguide/2.3.3/systemAdministrationBackup.html)

1.1. Backing up the OJS System Files

1.2. Backing up the Database

1.3. Backing up the files/ Directory

[Restoring Your System From Backup](https://pkp.sfu.ca/ojs/docs/userguide/2.3.3/systemAdministrationRestoring.html)

2.1. Restoring Files

2.2. Restoring the Database

Now my question is:

Can i perform the [Restoring Your System From Backup] on OJS 3.x installation directly from my OJS 2.x backup files?

Best Regards,
Jnana

ctgraham · January 17, 2020, 8:21pm

The OJS2 Guide describes both backing up the “System Files” and the “files/ Directory”. The “System Files” backup includes both the OJS application files and the “public” files directory.

A backup which includes the following will allow you to build a fresh copy of OJS, either at the current version, or a later version:

The OJS database
The OJS private files (files_dir)
The OJS public files (“public”)
The config.inc.php

You do not need the old OJS application files to build the 2.x installation first in a 3.x migration. You can extract the database, private files, public files, and config.inc.php directly from your 2.4.x backup within a fresh install of 3.x.

This is essentially what is described in the UPGRADE.md document, starting with the “Full Package” section:

github.com

pkp/ojs/blob/stable-3_1_2/docs/UPGRADE.md#1-full-package

# Upgrading an OJS Installation

Note: Before upgrading your installation, perform a complete backup of your
data files and database. If the upgrade process fails, you will need to recover
from backup before continuing.

If you are using PHP Safe Mode, please ensure that the max_execution_time
directive in your php.ini configuration file is set to a high limit. If this
or any other time limit (e.g. Apache's "Timeout" directive) is reached and
the upgrade process is interrupted, manual intervention will be required.


## Upgrading from OJS 2.0.x, 2.1.x, 2.2.x, or 2.3.x

See [docs/UPGRADE-UNSUPPORTED](UPGRADE-UNSUPPORTED.md).


## Upgrading from OJS 2.4.x

OJS 3.x is a major rewrite of Open Journal Systems, introducing numerous new

This file has been truncated. show original

Be sure to continue on to the “Upgrading the OJS Database” section, where the process will modify your database and the files in files_dir:

github.com

pkp/ojs/blob/stable-3_1_2/docs/UPGRADE.md#upgrading-the-ojs-database

# Upgrading an OJS Installation

Note: Before upgrading your installation, perform a complete backup of your
data files and database. If the upgrade process fails, you will need to recover
from backup before continuing.

If you are using PHP Safe Mode, please ensure that the max_execution_time
directive in your php.ini configuration file is set to a high limit. If this
or any other time limit (e.g. Apache's "Timeout" directive) is reached and
the upgrade process is interrupted, manual intervention will be required.


## Upgrading from OJS 2.0.x, 2.1.x, 2.2.x, or 2.3.x

See [docs/UPGRADE-UNSUPPORTED](UPGRADE-UNSUPPORTED.md).


## Upgrading from OJS 2.4.x

OJS 3.x is a major rewrite of Open Journal Systems, introducing numerous new

This file has been truncated. show original

Jnana_Rana · January 18, 2020, 4:07am

Thank you so much @ctgraham for your valuable input.
I have gone through your inputs minutely and will definitely share my progress in this thread as and when it happens.

Jnana.

Jnana_Rana · January 27, 2020, 2:29am

@ctgraham I was in the process of upgrading OJS 2.4.2.0 to OJS 3.1.2.4.

So far i am successful in following activity

Restored OJS Public files(“public” from System Files).
Restored OJS private files(files_dir)
Importantly OJS database
config.inc.php

After this activity while i am pressing
“Install Open Journal System” on http://localhost/journal/index.php/index/install page
After some time i am getting a error in DB which says.

Error occurred during installation.
A database error has occurred: Duplicate entry ‘manualpayment-0-manualInstructions’ for key 'plugin_settings_pkey’

How will i proceed. Please help. Thanks you.

Regards,
Jnana.

ctgraham · January 27, 2020, 1:50pm

Instead of using the “Install Open Journal System” link in the install page, look for the “Upgrade” link.

Be sure to delete your database before re-trying.

Delete and Restore OJS Public files(“public” from System Files).
Delete and Restore OJS private files(files_dir)
Delete and Import OJS database
Copy config.inc.php with “Installed = Off”
Visit the Install page
Click the “Upgrade” link.

Jnana_Rana · January 28, 2020, 1:33am

Thanks a lot @ctgraham. As the files are quite big in size it may take a 2/3 days before i share you the update.

Meanwhile i have a quick question.
Do we have any log file which can tell us whats went wrong while upgrading ?

Regards,
Jnana.

ctgraham · January 28, 2020, 1:48pm

If you have access to the command line, we strongly recommend using that method, as everything can be logged. Without that, I think we would need to make a code change to log the web process to your PHP error log or to the files_dir.

Jnana_Rana · January 28, 2020, 3:56pm

@ctgraham i understood the complexity then, Better i will use command line. Can you suggest the documentation which will guide me how to proceed with upgrade using command line.

Jnana_Rana · January 29, 2020, 2:07am

@ctgraham when i tried to “Upgrade” as per your suggestion via “OJS Web Interface” it gives me a black page.

I also tried using command line Interface:
$ php tools/upgrade.php upgrade
It finished within a second and nothing happened.

I am clueless now what’s happening. Kindly help.

Regards,
Jnana.

ctgraham · January 29, 2020, 2:10pm

Did you see any output in the CLI upgrade? Even if there was nothing to do, you would expect to see some.

Try running php tools/upgrade.php check. This should report the version of the application and the version of the database.

Jnana_Rana · January 30, 2020, 2:19am

@ctgraham It prints nothing for check. It prints nothing for upgrade command also.
PFA above for your reference.

Where am i going wrong ?

I want to specify few things here:

Do you want to see the restored config.inc.php file?
Here i have done some modification like the private_file is different where the site is hosted and live. So i changed it to point to the path it is restored.
Attribute like base_url changed to "base_url = “http://pkp.sfu.ca/ojs”
Database settings not touched.
In the installed directory of the actual application(which is in OJS 2.4) contain many other custom directories which are not part of default OJS 3.x. But i only copied “public” directory and config.inc.php in to the OJS 3.x installed directory.

I highly appreciate your quick reply @ctgraham.

ctgraham · January 30, 2020, 5:17pm

The configuration file is required for the upgrade process. When run without a config.inc.php, you should see something like:

$ php tools/upgrade.php check
<h1>Cannot read configuration file config.inc.php</h1>Cannot read configuration file config.inc.php

But, no setting value that I know of will prevent the upgrade tool from displaying anything at all, as you are seeing. One possible exception could be the database driver, which when changing from PHP 5.x to PHP 7.x must change from “mysql” to “mysqli”. Otherwise, changing your settings within config.inc.php, including private_files and base_url should not cause the problem.

Copying the public directory and the config.inc.php into a fresh install of OJS 3.x should work.

I’m not seeing a good reason for why there would be no output from running the upgrade script.

As an remote possibility, perhaps your CLI instance of PHP is logging PHP error messages to a file rather than to STDERR, and a PHP level error (such as using “mysql” instead of “mysqli”) is being logged to that file rather than to the screen. Or perhaps the CLI is configured to suppress all PHP errors? We can check this by running:

php -i

and looking for values for “display_startup_errors”, “error_log”, and “error_reporting”.

A shortcut is:

php -i | grep error