OK, so we have a problem and I’m looking for someone who could help. Anyone willing to consult on this for us? We would love to hire someone to help fix this as soon as practicable, or at least provide some direction. It seems that after the upgrade from 3.2.0-2 to 3.3.0-6 there are some database issues, but these were not discovered until after the backup was overwritten (oh no…). We are having trouble with submissions to the site, and editing existing journals.
[php7:error] PHP Fatal error: Uncaught Error: Call to a member function getData() on null in /var/www/journal/plugins/generic/htmlArticleGalley/HtmlArticleGalleyPlugin.inc.php:109\nStack trace:\n#0 /var/www/journal/lib/pkp/classes/plugins/HookRegistry.inc.php(107): HtmlArticleGalleyPlugin->articleDownloadCallback('ArticleHandler:...', Array)\n#1 /var/www/journal/pages/article/ArticleHandler.inc.php(421): HookRegistry::call('ArticleHandler:...', Array)\n#2 /var/www/journal/lib/pkp/classes/core/PKPRouter.inc.php(395): ArticleHandler->download(Array, Object(Request))\n#3 /var/www/journal/lib/pkp/classes/core/PKPPageRouter.inc.php(246): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)\n#4 /var/www/journal/lib/pkp/classes/core/Dispatcher.inc.php(144): PKPPageRouter->route(Object(Request))\n#5 /var/www/journal/lib/pkp/classes/core/PKPApplication.inc.php(362): Dispatcher->dispatch(Object(Request))\n#6 /var/www/journal/index.php(68): PKPApplication->execute()\n#7 {main}\n thrown in /var/www/journal/plugins/generic/htmlArticleGall ey/HtmlArticleGalleyPlugin.inc.php on line 109
It seems that the migration failed; really need help figuring out how to stabilize the install. I’m happy to get some pointers, but I’m not very familiar with the internals of the software and would love to hire someone to look at it with me.
Sorry to hear that the upgrade didn’t go so well. If you have someone who can look at the database a bit, here’s a pointer. That line of code, line 109 in the HtmlArticleGalleyPlugin, is this:
There are several calls to getData() on it, but the thing that is probably triggering the error is a null submission file, since there is a test for a null galley object a few lines up that would return false before line 109 was reached. So, I’d probably look in the publication_galleys table for submission_file_id columns that are either null, or do not exist in the files table any more. You can try running this query:
SELECT * FROM publication_galleys WHERE submission_file_id NOT IN (SELECT distinct file_id from files);
That would give you galleys that have invalid files, and from there you can work back to the publication object in the publications table, and from there you can get back to the submission object based on the submission_id column and then look in the workflow at that submission and see what’s up.
If you search through that file for new_file_id, you’ll see that it eventually gets renamed to file_id here:
But before that happens, the file_id column in your table should have been renamed to submission_file_id (it’s the line just prior).
This is a guess, but given that that’s the first time a column is renamed in that table during this process, does your MySQL user have ALTER TABLE privilege?
The problem is that right now we’re left with the fact that a substantial amount of the upgrade process did not run here.
Another curiosity, in that OJS 3.3 requires a) InnoDB database tables because it uses foreign keys for the first time ever, and b) creating a foreign key requires that the user has the REFERENCES mysql privilege.
Also, and perhaps you’ve already investigated this. I know you said that the backup was overwritten but does the systems admin have a server level backup that you can just restore back to? A nightly backup of the entire machine?
So I was able to walk through the steps and found where the upgrade stopped processing, and was able to complete the DB upgrade, and things look good. This isn’t pretty, I’ll acknowledge, and really not sure what happened, but alas things look good and consistent.
However, now when loading any page, I am getting a blank page and the following in the error logs:
Starting to look into this one now, but not finding this column in the upgrade scripts/classes.
Glad to hear that you’re making progress. There is a locale column in a bunch of places, and it might have been added to a table during the initial schema synchronization that occurs when you upgrade. If you grep for “locale” in
dbscripts/xml/ojs_schema.xml
and in lib/pkp/xml/schema/*.xml
You’ll find it in a lot of places. To help narrow this down, you can enable debugging output in your config.inc.php file:
; Enable database debug output (very verbose!)
debug = Off
Soooo… close… Found that the submissions.locale column was missing - added the column to the table and things look really good. But we were unable to edit an existing submission title. I added the locale by hand in the database for that submission and then was able to edit the submission in the UI.
Weird that the locales are missing - any suggestion if there’s any way to recover them from another table or reference, or are we looking at a manual process to re-add the locale to each submission?
Hmmm, well, the locale for your submissions could be in a few possible places for reference. Is this a multilingual journal, generally? The locale on the submission is the one chosen by author when they submit, i.e. it’s the locale set in the journal’s Website Settings area, here:
And if you’re only allowing one language, that’s the language that the submissions should have as a locale. If you allow more than one language, you could probably correlate right to the locale column in the publication_galleys table, which is the language the galley is in. The relationship to submissions would be via the submission_id column in the publications table, and then to the publication_galleys table via the publication_id column.
Yes, it’s a multilingual journal. I was able to correlate to locale in publication_galleys as you described. Thank you! I’ll start walking through some further tests to make sure things look all set.
