Ojs 2.4.8-5 to ojs 3.2.1-1

lacris · August 12, 2020, 8:09am

Good morning!

I have tried to update our OJS 2.4.8-5 (with php 7.0) to OJS 3.2.1-1 (with php 7.4.3)

After making the corresponding backup copy of the database and filesystem, changing permisisons, etc and restoring in a new databse and new installation, I typed:

php tools/upgrade.php check, and I get:
Code version: 3.2.1.1
Database version: 2.4.8.5
Latest version: 3.2.1.1
Database version is older than code version
Run “tools/upgrade.php upgrade” to update

And after running php tools/upgrade.php upgrade and wait a lot of minutes, it ends with:

ERROR: Upgrade failed: DB: Duplicate entry ‘4524-3-1’ for key ‘review_rounds_submission_id_stage_id_round_pkey’

My first question is:

Can this update be done without going through the intermediate versions?

An the second one:

How can I solve the error that I get?

Thank you so much!
Cristina

asmecher · August 12, 2020, 3:04pm

Hi @lacris,

Have a look at this issue discussion: Upgrade to 3.0.0: pkey violation on review_rounds · Issue #1921 · pkp/pkp-lib · GitHub

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 14, 2020, 9:12am

Good morning @asmecher.

Thanks for your support: I deleted 12 rows duplicated (by excuting:

This query returns the duplicated rows that need to be deleted:

    SELECT rr.* FROM review_rounds as rr WHERE rr.review_round_id 
        NOT IN (SELECT MIN(rrr.review_round_id) FROM review_rounds as rrr 
                GROUP BY rrr.submission_id, rrr.round);

)
Then, I reinstallled OJS 3.2.1-1 from the beginning and it seemed that everything was fine until, after many minutes and many messages on the screen, the connection between the machine with the ojs and that of the bd was closed.

Should I “parameterize” something in the php.ini, the OJS or the DB so that it does not happen again?
I have to start again.

Thank you so much!
Cristina

asmecher · August 14, 2020, 2:47pm

Hi @lacris,

When you say the connection to the database was closed, do you mean during the upgrade process?

If you’re hitting server timeouts, you might be able to work around it by creating some indexes to speed up the upgrade process. Try applying this change after restoring from backup and before re-running the upgrade script.

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 17, 2020, 8:40am

morning @asmecher,

Yes, the connection closed during the upgrade process (it seems that was the ojs server machine who closed).

I´m going to try with that change you tell me. Did I delete duplicates before creating those indexes right?

If I can do this today, I´ll feed back to you.

Thanks!
Cristina

lacris · August 17, 2020, 11:28am

Hello again @asmecher,

I´ve tried to do that about de Indexes by executing those querys in MySQL directly but this are my results:

CREATE TABLE temp_authors AS SELECT * FROM authors; -->> OK
CREATE INDEX temp_authors_s_id ON temp_authors (submission_id); → OK
CREATE INDEX temp_authors_a_s_id ON temp_authors (author_id, submission_id); → OK

CREATE TABLE temp_submissions AS SELECT * FROM submissions; → ERROR Table ‘ojspru32.submissions’ doesn’t exist
CREATE INDEX temp_submissions_s_id ON temp_submissions (submission_id);

CREATE TABLE temp_submission_galleys AS SELECT * FROM submission_galleys; → Table ‘ojspru32.submission_galleys’ doesn’t exist
CREATE INDEX temp_submission_galleys_s_id ON temp_submission_galleys (submission_id);

CREATE TABLE temp_published_submissions AS SELECT * FROM published_submissions; → Table ‘ojspru32.published_submissions’ doesn’t exist
CREATE INDEX temp_published_submissions_s_id ON temp_published_submissions (submission_id);

CREATE TABLE temp_citations AS SELECT * FROM citations; → OK
CREATE INDEX temp_citations_s_id ON temp_citations (submission_id); → Key column ‘submission_id’ doesn’t exist in table
CREATE INDEX temp_citations_c_s_id ON temp_citations (citation_id, submission_id); → Key column ‘submission_id’ doesn’t exist in table

And then, I have stopped …

I could continue with the UPDATES that appear in the URL that you tell me, referring to “citations”, but the UPDATE related to submissions I can’t since I don’t have any table name with the word submission in its name. Neither does a table called submissions, nor submissions_gallery, nor published_submissions.

Maybe I’m misunderstanding you and I don’t have to execute those queries in my MySQL?
In any case, it would give the same error because, as I said, these tables do not exist.

Or your idea was that I download those two files to my OJS 3.2.1-1 installation and try to upgrade?

Thanks again!
Cristina

asmecher · August 17, 2020, 5:39pm

Hi @lacris,

You won’t be able to run those queries directly in MySQL as they need to be executed at the right stage of the upgrade process. If you change the indicated files in the link, it’ll take care of that for you.

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 18, 2020, 6:43am

Ops! I suspected that I had misunderstood you when I was writing to you yesterday.

So the idea is to download the two files and launch the upgrade, right?

One last question: do the downloaded files come with the changes or should I modify them as seen in the link?

Thank you very much indeed for your help!
Cristina

lacris · August 18, 2020, 9:58am

good morning @asmecher!

Good news!I

I have finally managed to update to the new version.
Let’s see what OJS administrators and users think.
Thank you very much!
Cristina

ps: go for the OMP!

lacris · August 18, 2020, 12:05pm

Hi @asmecher,

Too early to claim victory
I have run ojs via the web and a blank page appears whose source code is:
<! DOCTYPE html>

<html lang = "

In the logs I have seen two errors:

1- Unknown collation: ‘utf-8’ : I have changed ir in the config.inc.php by the defaullt ( utf8_general_ci) and rebooted apache.

And the second one:

2- PHP Fatal error: Uncaught Error: Call to undefined function mb_split() in /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/shared.mb_str_replace.php:47\nStack trace:\n#0 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/modifier.replace.php(34): smarty_mb_str_replace()\n#1 /ojs/ojs-3.2.1-1/cache/t_compile/65bfc3e024c2e9104f46e23b73376a9455e3df0e^10ae5578a0959129b8d4ceeb9f99c1bb2a9cbd65_0.app.frontendcomponentsheader…php(34): smarty_modifier_replace()\n#2 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_5f3baf7f9f7f88_62100310()\n#3 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#4 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#5 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#6 /ojs/ojs-3.2.1-1/cache/t_compile/65bfc3e024c2e9104f46e23b73376a9455e3df0e^51cfb9321c891ada9323e7942962579e7e4324d1_0.app.frontendpagesindexSite.tp.php(26): Smarty_Internal_Template->_subTemplateRender()\n#7 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_5f3baf7f979383_29067914()\n#8 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#9 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#10 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(232): Smarty_Internal_Template->render()\n#11 /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute()\n#12 /ojs/ojs-3.2.1-1/lib/pkp/classes/template/PKPTemplateManager.inc.php(922): Smarty_Internal_TemplateBase->display()\n#13 /ojs/ojs-3.2.1-1/pages/index/IndexHandler.inc.php(83): PKPTemplateManager->display()\n#14 /ojs/ojs-3.2.1-1/lib/pkp/classes/core/PKPRouter.inc.php(391): IndexHandler->index()\n#15 /ojs/ojs-3.2.1-1/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest()\n#16 /ojs/ojs-3.2.1-1/lib/pkp/classes/core/Dispatcher.inc.php(143): PKPPageRouter->route()\n#17 /ojs/ojs-3.2.1-1/lib/pkp/classes/core/PKPApplication.inc.php(279): Dispatcher->dispatch()\n#18 /ojs/ojs-3.2.1-1/index.php(68): PKPApplication->execute()\n#19 {main}\n thrown in /ojs/ojs-3.2.1-1/lib/pkp/lib/vendor/smarty/smarty/libs/plugins/shared.mb_str_replace.php on line 47

I don’t know if I can change the collation after upgrading. And I don’t know how to fix the second error either.

I take this opportunity to ask you another question: can I delete the “cache” directory?

Thanks a lot!!!
Cristina

asmecher · August 18, 2020, 8:36pm

Hi @lacris,

The message Call to undefined function mb_split() means that your PHP installation is missing the mbstring extension. I’d recommend installing it.

Yes, you can remove the contents of the cache directory (e.g. rm cache/*.php) and they should be re-generated automatically.

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 19, 2020, 8:35am

Hi @asmecher,

I have managed to see some of the contents but I have several questions:

1- The accents or the eñes do not look good.

2- a series of messages appear at the top of the screen of the type:

ADOConnection._Execute(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (‘submissionKeyword’, 1048588, 3019)) % line 1217, file: [adodb.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/lib/vendor/adodb/adodb-php/adodb.inc.php) ADOConnection.Execute(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (‘submissionKeyword’, 1048588, 3019), Array[1]) % line 229, file: [DAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/db/DAO.inc.php) DAO.update(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (?, ?, ?), Array[3], true, false) % line 99, file: [ControlledVocabDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/controlledVocab/ControlledVocabDAO.inc.php) ControlledVocabDAO.insertObject(Object:ControlledVocab, false) % line 60, file: [ControlledVocabDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/controlledVocab/ControlledVocabDAO.inc.php) ControlledVocabDAO._build(submissionKeyword, 1048588, 3019) % line 31, file: [SubmissionKeywordDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/submission/SubmissionKeywordDAO.inc.php)

ADOConnection._Execute(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (‘submissionSubject’, 1048588, 3019)) % line 1217, file: [adodb.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/lib/vendor/adodb/adodb-php/adodb.inc.php) ADOConnection.Execute(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (‘submissionSubject’, 1048588, 3019), Array[1]) % line 229, file: [DAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/db/DAO.inc.php) DAO.update(INSERT INTO controlled_vocabs (symbolic, assoc_type, assoc_id) VALUES (?, ?, ?), Array[3], true, false) % line 99, file: [ControlledVocabDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/controlledVocab/ControlledVocabDAO.inc.php) ControlledVocabDAO.insertObject(Object:ControlledVocab, false) % line 60, file: [ControlledVocabDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/controlledVocab/ControlledVocabDAO.inc.php) ControlledVocabDAO._build(submissionSubject, 1048588, 3019) % line 31, file: [SubmissionSubjectDAO.inc.php](file://nwww/web/servicios/sp/ojs-3.2.1-1/lib/pkp/classes/submission/SubmissionSubjectDAO.inc.php)

around 90 messages.

3- there are several PDFs that tell me that they are invalid or corrupted.

I don’t know if item 1 is because I upgraded with collation = utf-8 and then changed it to the defaukt value (after upgrade).
Maybe should I do everything again from the start with collation = utf8_general_ci?

For item 2 I have put in the php.ini that I do not get errors:
display_errors=Off
display_startup_errors=Off

but I restart apache and everything remains the same

And I don´t know what to do with the corrupted PDF files …

Thank you again.

lacris · August 19, 2020, 12:31pm

Hello,

I’ve been testing a lot of variants of reporting_errors but it lways returns the same:

;error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT l
;error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE & ~E_USER_DEPRECATED
;error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR
error_reporting = E_STRICT

Thanks!
Cristina

asmecher · August 19, 2020, 4:16pm

Hi @lacris,

Have you turned on the debug option in config.inc.php? If so, set it to Off.

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 20, 2020, 8:36am

ha, ha, ha! It was! All clean! thank you!!!
You have resolved my second question.

Now: my specials characters (accents, eñes, …):

I did the “upgrade” with collation = utf-8 and it was successful but when I connected via the web, in the logs it complained about the collation, so I changed it in the config.inc.php to the one that came by default: utf8_general_ci

Since it still looks bad, I don’t know if I should redo the update from scratch. What you think?

I think I will.

I’ll keep you informed.
By!
Cristina

lacris · August 20, 2020, 10:49am

Hello again @asmecher!
I have redo all the migration with the default collation and the update has gone well but the “special” characters (accents for example) do not look good.
Is it a matter of the update itself or is it something that the OJS administrator must configure?

Thanks a lot!
Cristina

asmecher · August 20, 2020, 6:14pm

Hi @lacris,

This is related to your connection_charset setting in config.inc.php; what value was is set to for both your old and new installations?

Regards,
Alec Smecher
Public Knowledge Project Team

lacris · August 21, 2020, 7:58am

Hi Alec!
I remember that in a first update attempt I had problems with the charset that I put in the new config.inc.php

Actually this is what I have in the old install:

client_charset = utf-8
; If enabled, must be the same character set as “client_charset”
connection_charset = utf8
database_charset = utf8
; Note that client_charset and database collation must be set
charset_normalization = Off

And this is what is in the new config.inc.php:

client_charset = utf-8
; If enabled, must be the same character set as “client_charset”
connection_charset = utf-8

I do not know if I should try to update putting the same values as in the old one and test if it leaves me. It sounds to me that the update procedure did not like utf8 and “preferred” utf-8 just to be the same as the client_charset.

What do you recommend me?
Thank you!
Cristina

lacris · August 21, 2020, 9:33am

Hi Alec!

Done! Now they can see all the special characters and I can´t find any corrupted PDF file (At least for now) …

I’m going to let them test it out before I do the upgrade in production.

Many thanks!

asmecher · August 21, 2020, 3:19pm

Hi @lacris,

Glad to hear you’re making progress!

Note that the discrepancy between utf8 and utf-8 in the following settings…

client_charset = utf-8
connection_charset = utf8

…is intentional and should not be “corrected”. The two settings go to different libraries that have different expectations around how UTF8 is expressed.

Regards,
Alec Smecher
Public Knowledge Project Team