3 issues after upgrading from OJS 2.2.2-0 to 2.3.2-1

[asmecher]

Hi Sina,

Ah, I misread your response -- I thought you were upgrading with a patch, not using the entire package. I still think something must remain from the old version, though; searching the entire codebase of OJS 2.3.2-1 for "copyed_assignments" shows that it only appears in the upgrade script. If you're seeing it when you try to use the system, some old reference to it must somehow remain in your installation directory.

You mentioned that "Upgrading from 2.2.4.0 to 2.3.3-3 runs to an error." -- do you have a copy of this error?

Note that if you try to upgrade, and the process fails, your database will be left in an indeterminate state. If you want to try upgrading again, you should first restore your database to its state from before you first ran an upgrade.

Regards,
Alec Smecher
Public Knowledge Project Team

[sighteer]

Hi,

I have the same problem ... even worse, I didn't got the "update successful" page even I refresh it. I'm using full package replacement by web, because I have no shell.

Errors occurred during installation:

•A database error has occurred: Table 'xcedu_ojs.copyed_assignments' doesn't exist

Thank you in advance!

[sighteer]

Hi again,

Now I understand why the error occours, it is because I first got another error, and then the DB is in its intermedia state (should be fine if overwritten with backup).

The first error I got is this one:

[11-Dec-2010 12:37:29] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 668 bytes) in /home1/xcedu/public_html/ojs/lib/pkp/classes/xml/XMLParserDOMHandler.inc.php on line 78

I have already changed the php.ini memory_limit to 32M, 64M, 128M, 512M, so I suppose it shouldn't be the problem. Again, I am using web based upgrading.

Please, help me.

Thank you!

- Sighteer

[robinhood1362]

Hi Alec,

You said "You mentioned that "Upgrading from 2.2.4.0 to 2.3.3-3 runs to an error." -- do you have a copy of this error?"
The error is: "DB Error: Data too long for column 'subject' at row 1"

I remember I used to get the same error before, when a reviewer's comment title exceeded 90 characters, after which I manually changed max to 255 in the database. But in this 'upgrade' case, I wonder why this is happening.

Any thoughts?

Thanks,
Sina

[asmecher]

Hi Sina,

This could be in article_email_log, email_templates_default_data, or email_templates_data -- you could use the "debug" setting in config.inc.php to determine which. These fields haven't changed size in many releases, so I suspect this is something you've previously changed in the database. When you run the upgrade, OJS applies the database descriptors (i.e. dbscripts/xml/ojs_schema.xml) to the existing database; it sounds to me like it's trying to re-set the column length (255) to a database column that contains longer data than that.

Regards,
Alec Smecher
Public Knowledge Project Team

[apennathur]

Thanks Matt, issue #2 has been resolved by manually adding the SIGNOFF_COPYEDITING_AUTHOR as per your comments. SQL code example:

Code: Select all

INSERT INTO signoffs (symbolic, assoc_type, assoc_id, user_id) VALUES ('SIGNOFF_COPYEDITING_AUTHOR', '257', '184', '0')

Regards,
John Grobler

Dear John, we are having the same problem, and we tried your code, could you please let us know how the values for assoc_type and user_id are set for each article in the copyediting sign-off table? Are they constant at 257 and 0? We understand from Matt's posting below that assoc_id is the article id so we have added this for every article.

Thank you so much for any help you can provide.

[RoTiV]

Thanks Matt, issue #2 has been resolved by manually adding the SIGNOFF_COPYEDITING_AUTHOR as per your comments. SQL code example:

Code: Select all

INSERT INTO signoffs (symbolic, assoc_type, assoc_id, user_id) VALUES ('SIGNOFF_COPYEDITING_AUTHOR', '257', '184', '0')

Regards,
John Grobler

This works for the edit page (http://.../index.php/myjournal/editor/submissionEditing/2345).


But not for the view page, which keeps appearing incomplete (http://.../index.php/myjournal/article/view/j. 1676-4893.2011.2345).
error log

Code: Select all

ojs2 has produced an error\n  Message: WARNING: array_keys() [<a href='function.array-keys'>function.array-keys</a>]: The first argument should be an array\n  In file: /.../lib/pkp/classes/core/DataObject.inc.php\n  At line: 53\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.2.14\n   Apache Version: Apache/2.2.16 (Unix) DAV/2 PHP/5.2.14\n   DB Driver: mysql\n   DB server version: 5.0.84-log, referer: http://.../index.php/myjournal/issue/current

ojs2 has produced an error\n  Message: WARNING: array_shift() [<a href='function.array-shift'>function.array-shift</a>]: The argument should be an array\n  In file: /.../lib/pkp/classes/core/DataObject.inc.php\n  At line: 54\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.2.14\n   Apache Version: Apache/2.2.16 (Unix) DAV/2 PHP/5.2.14\n   DB Driver: mysql\n   DB server version: 5.0.84-log, referer: http://.../index.php/myjournal/issue/current

PHP Fatal error:  Cannot return string offsets by reference in /.../lib/pkp/classes/core/DataObject.inc.php on line 55, referer: http://.../index.php/myjournal/issue/current

[aapollaro]

We had the same problem but it worked with this query!

Thanks Matt, issue #2 has been resolved by manually adding the SIGNOFF_COPYEDITING_AUTHOR as per your comments. SQL code example:

Code: Select all

INSERT INTO signoffs (symbolic, assoc_type, assoc_id, user_id) VALUES ('SIGNOFF_COPYEDITING_AUTHOR', '257', '184', '0')

Regards,
John Grobler

[asmecher]

Hi Sina,

If you're getting an error message about copyed_assignments existing after upgrading, some of the code must still be referring to it. Could you try turning on the "show_stacktrace" option in config.inc.php to get more information?

(Re: patch output: It sounds like you didn't use the patch process, so don't worry about that.)

Regards,
Alec Smecher
Public Knowledge Project Team

[peterdietz]

We have the error as mentioned previously.

Code: Select all

PHP Fatal error:  Call to a member function getDateNotified() on a non-object in /[path]/cache/t_compile/%%B0^B03^B0335942%%copyedit.tpl.php on line 151, referer: http://[site]/editor/submissionEditing/1580

However, the proposed fix of inserting a row in the database doesn't improve things. So any further help is appreciated. I'm wondering if the view needs to be safer and check if the value is null/non-existent before trying to call getDate* on the object.

Code: Select all

INSERT INTO signoffs (symbolic, assoc_type, assoc_id, user_id) VALUES ('SIGNOFF_COPYEDITING_AUTHOR', '257', '184', '0')

Our signoffs table has over 9000 entries, I've grouped by symbolic, and here is the distribution. Is it abnormal that COPYEDITING_AUTHOR is so much smaller than the others?
symbolic count(*)
SIGNOFF_COPYEDITING_AUTHOR 36
SIGNOFF_COPYEDITING_FINAL 1543
SIGNOFF_COPYEDITING_INITIAL 1543
SIGNOFF_LAYOUT 1543
SIGNOFF_PROOFREADING_AUTHOR 1543
SIGNOFF_PROOFREADING_LAYOUT 1543
SIGNOFF_PROOFREADING_PROOFREADER 1543

Thanks

[asmecher]

Hi peterdietz,

See http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=6456 (which is linked from the Recommended Patches list, http://pkp.sfu.ca/wiki/index.php/OJS_2.3.4_Recommended_Patches).

Regards,
Alec Smecher
Public Knowledge Project Team

[peterdietz]

Ok great, thanks for the links. We use Git, so I'll likely just cherry-pick the fixing commits into our system. (Its amazing how well that works).
Note: it would be nice if bugzilla could reference the sha1 of the fixing commit, or if you migrated to github issues. I have to search for git commits that have same commit message as bug title to find the one I want to cherry-pick. Minor annoyance, but many cheers for all your work.

As far as my bug I just commented about. I re-reread the earlier comments in this thread, and found that every article has to have the 7 signoffs. I found that the articles that were causing the error were missing copyediting_author, and I was able to fix that by doing the INSERT and setting the assoc_id equal to my affected article's ID. I had blindly tried inserting something with copyediting_author and assoc_id of a previous person's issue. Lesson: Read twice, SQL once.

[mbria]

Published INSERT did the job.

BTW, following peterdietz example we also count symbolics and this is what we get:

Code: Select all

SELECT symbolic, count( * )
FROM `signoffs`
GROUP BY `symbolic`


Code: Select all

symbolic    count(*)
SIGNOFF_COPYEDITING_AUTHOR    166
SIGNOFF_COPYEDITING_FINAL    365
SIGNOFF_COPYEDITING_INITIAL    365
SIGNOFF_LAYOUT    365
SIGNOFF_PROOFREADING_AUTHOR    365
SIGNOFF_PROOFREADING_LAYOUT    365
SIGNOFF_PROOFREADING_PROOFREADER    365


I will try the patch, but just to know... every article need a SIGNOFF_COPYEDITING_AUTHOR row?
Does it means that the DB is wrong?

Thanks you all,
m.

[solty]

Hello,
I was upgrade from 2.3.7.0 to 2.4.2.0 (March 14, 2013).
Everything OK except for "Browse by Author", there are broken author names and his/her affiliations.

And I see an error:
Fatal error: Cannot return string offsets by reference in /var/www/vhosts/domainname.com/httpdocs/lib/pkp/classes/core/DataObject.inc.php on line 66

You can see
http://www.neuroquantology.com/trial/in ... ch/authors

OS platform Linux
PHP version 5.3.16
Apache version Apache
Database driver mysql
Database server version 5.5.30-cll

Could you suggest any solution?

Best,

[asmecher]

Hi solty,

I suspect the problem is due to a database inconsistency. Look for entries in the author_settings table where the affiliation isn't properly localized, e.g.:

Code: Select all

SELECT count(*) FROM author_settings WHERE setting_name = 'affiliation' AND (locale IS NULL OR locale = '');

You should get 0 if all affiliations are properly localized. If you get a number that's not zero, then you'll have to correct those entries, e.g. by setting the locale to 'en_US' for English, or by deleting them.

Regards,
Alec Smecher
Public Knowledge Project Team