Migration OJS 2.2.3 to 2.4.8

Software Support
1

Hello.

I am working on migration OJS 2.2.3 to 2.4.8.

I downloaded the full package, changed the config.inc.php with the data from the old version.

When running the database update is with the following error:

php tools/upgrade.php upgrade

[pre-install]
[load: upgrade.xml]
[version: 2.4.8.0]
[data: dbscripts/xml/upgrade/2.3.0_usersettings.xml]
[schema: lib/pkp/xml/schema/signoff.xml]
[data: dbscripts/xml/upgrade/2.3.0_preupdate.xml]
[data: dbscripts/xml/upgrade/2.3.0_subscription_ip.xml]
ERROR: Upgrade failed: DB: Can’t find file: ‘./seer_2010/subscription_ip.frm’ (errno: 2)

In my understanding, in version 2.3.0 there was a table called subscription_ip.

What should I do in this case?

Thanks.

Tiago

2

Hi @tiago_agostinho,

Hmm, that’s a MySQL error message – MySQL expects that file to exist but it doesn’t. That’s different from a table that OJS expects to be present but isn’t there. Have you moved your MySQL data files around? MySQL expects to manage those by itself. You might want to try running mysqlcheck on your database.

Regards,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher ,

I have tried several things to make the OJS running properly, but without success.

Leaving part of migration, I did another test: Copy all the 2.2.3 version of the files to the new server, along with the files and import the database.

It is showing several errors, as you can see this url http://www.ambi-agua.net/seer2/index.php/ambi-agua/index.

Searching on google I saw that the problem may be in the version of PHP that is not compatible; it proceeds?

The old server was running PHP 5.2.4 and PHP 5.5.9 the new wheel.

I have a way to hide these messages without migrating?

Tiago

4

Hi @tiago_agostinho,

I can pretty much guarantee that OJS 2.2.3 will not run on PHP 5.5.9; OJS 2.3.3 was released in 2009 and a lot of things have changed since then.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi @asmecher,

Really, I have a big problem to be solved.

We are working with OJS 2.2.3 version a long time.

I see that many go through problems when migrating version.

Summary of actions that did and did not work:

  • Run ojs-2.2.3_to_2.4.8.patch patch
  • Download the complete package ojs-2.4.8.tar.gz
  • Run ojs 2.2.3 with PHP 5.2.4

The biggest problem I see is with respect to the database.

I’ve read and re-read the documents, forum, google etc …

I thought about going by downloading the newest versions (2.2.4 Download OJS (.tar.gz)) and run the upgrade database.

And so on…

What would you advise me?

Regards,

Tiago

6

Hi @tiago_agostinho,

I would suggest trying the “full package upgrade” process described in the upgrade document. Basically, you would need to unpack the newest release on your new server, then copy across your old database, files directory, and public directory. Configure your config.inc.php so that it knows where to find them. Then try running the upgrade script.

If you get stuck on a particular step, describe it here and I may be able to help.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hello @asmecher,

Following his directions, I got it!

I have only a small problem to be solved.

During the update, there were some errors with controlled_vocabs table (duplicate records). As my time was short and needed to put the OJS to run, I have chosen to comment on the lines and in upgrade.xml file.

But now I need to update the tables (controlled_vocabs / controlled_vocab_entries / controlled_vocab_entry_settings) correctly.

There is this possibility?

Regards,

Tiago
8

Hi @tiago_agostinho,

Is there data in the reviewing interests field that you need to save?

Regards,
Alec Smecher
Public Knowledge Project Team

9

@asmecher,

Yes there is.

10

Hi @tiago_agostinho,

The best way to upgrade while preserving that data is to fix the problem you’re encountering with duplicate entries, rather than skipping that part of the upgrade and devising a different mechanism to transfer the reviewer interests. Do you have the error message that arose when you tried upgrading without removing those lines in the upgrade script?

Regards,
Alec Smecher
Public Knowledge Project Team

11

Hi @asmecher,

I no longer have the message.

Anyway, I will back up the database and the OJS and perform again, to correct the problem.

12

Taking advantage, I have one more question.

The Editorial Team page shows the names by section disorderly manner.

How do I sort by name.

Regards,

Tiago

13

Please post this new question in a new thread, with a new title.

This will help keep the forum organized, and help others find this new question in the future.

14

ok @ctgraham.

Thank you.

15

Hi @asmecher,

Following their guidelines, returned the backup of the database, corresponding to version 2.2.4 of OJS, and ran the following command: # php tools/upgrade.php upgrade to update the database.

The following error occurs in 1062: Duplicate entry ‘interest-4096-4’ for key ‘controlled_vocab_symbolic’, as was previously reported.

I ran this select to find duplicate data.

SELECT user_id
FROM user_settings
WHERE setting_name = ‘interests’
AND setting_value != “”
GROUP BY user_id, setting_name
HAVING count(*) > 1;

Returned 51 rows.

user_id
2
4
5
7
10
12
13
14
15
16
17
…

Perform this select to analyze each user_id individually:
SELECT * FROM user_settings WHERE setting_name = ‘interests’ AND user_id IN (2);

It seems a bug, because the table controlled_vocabs does not work with locale and has a unique key (controlled_vocab_symbolic) for the columns symbolic, assoc_type and assoc_id.

It seems I will have to choose only one language by user_id, delete the others and run the command again.

Would you help me.

Regards,

Tiago

16

Hi @tiago_agostinho,

I’m hesitant to invest too much time in a comprehensive solution here because this is such an old upgrade issue – do you have many users who list interests in several languages? I suspect that’s the factor that is causing your upgrade to fail where others have not had problems, and if it’s user-entered data, then I suspect that’s a very unusual situation. If you only have a few users who have entered interest data in several languages then the best quick solution would probably be to whittle those down manually to a single languages for the few cases.

Regards,
Alec Smecher
Public Knowledge Project Team