OJS 3.0, production galley files not loading

Software Support
,
1

Although this is also connected to supplementary files, this is clearly a different issue than the other one I posted earlier (OJS 3.0 upgrade fails to move/rename some supplementary files).

After upgrading to OJS 3.0 I noticed that the galley files view is not loading when I open the production tab in the workflow. It works when I only have one file there, but if the original article had several supplementary files added in the Editing-Layout stage in OJS2 the javascript in the galley view just keeps on loading.

Firebug gives me a 500 Internal Server Error for

GET http://servername.fi/index.php/journalname/$$$call$$$/grid/article-galleys/article-galley-grid/fetch-grid?submissionId=55539&_=1474294158542

The error log says:

[Mon Sep 19 10:09:29.773372 2016] [:error] [pid 10259] [client 192.168.175.21:59773] PHP Warning: assert(): Assertion failed in /var/www/servername.fi/public_html/lib/pkp/controllers/api/file/linkAction/FileLinkAction.inc.php on line 42, referer: http://servername.fi/index.php/journalname/workflow/index/55539/5
[Mon Sep 19 10:09:29.773398 2016] [:error] [pid 10259] [client 192.168.175.21:59773] PHP Fatal error: Call to a member function getFileId() on a non-object in /var/www/servername.fi/public_html/lib/pkp/controllers/api/file/linkAction/FileLinkAction.inc.php on line 46, referer: http://servername.fi/index.php/journalname/workflow/index/55539/5

However, if I go to the public site, I can see and open every file attached to the article without any errors. So basically all the files should, and are, there and also the database should be ok. But why does the galley view get stuck?

2

Hi @ajnyga,

I wonder if there aren’t some galleys in your 2.x install that don’t have files properly attached. Try running in your database…

SELECT sg.galley_id, sg.file_id FROM submission_galleys sg LEFT JOIN submission_files sf ON (sf.file_id = sg.file_id) WHERE sf.file_id IS NULL;

Regards,
Alec Smecher
Public Knowledge Project Team

3

Thanks. That does return 18 rows, but there are hundreds of these cases in the upgraded database so I find it hard to believe that this would be the reason.

4

Hi @ajnyga,

I would suggest reviewing and deleting those 18 rows from submission_galleys – it’s likely a data error in your 2.x installation.

As for the hundreds of cases – do you mean that the galley files grid fails to load for hundreds of submissions?

Regards,
Alec Smecher
Public Knowledge Project Team

5

Yes exactly, although I do not have an exact number but definitely more than those 18 rows can explain.

All of them are cases where there are more than on file attached. And in all cases the public site shows and opens all those same files without any problems. I will look into this tomorrow and start with those rows (it’s already 10 PM here).

6

Hi @ajnyga,

Do you mean cases where a single article had more than one galley? Can you confirm that this is the distinguishing feature (e.g. by looking at a few of each sort)?

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi,

I quickly checked a few and yes, that is the distinguising feature.

All articles with one galley file load the galley view without any problems and every article with more than one galley file keep on loading the galley view. One supplementary file was enough to cause the problem.

I do not know yet if this is a problem with the public supplementary files only, I will try to find an article with more than one actual galley file tomorrow and see how that is working.

Edit: So for example this article from OJS2 has problems. I can open both of these files in OJS3 if I am looking at the published article but the galley view does not load in the workflow, see below.

8

Hi,

Some new info on this matter. So, I found an article with more than one actual galley file and as you can see below, it opens without any problems.

So this is problem related to supplementary files. In all cases where an article had (public) supplementary files attached, the galley view is not loading after the upgrade to OJS3. However, all the files attached to the article can be opened from the public article view.

Edit: I probably found the reason why the supplementary files are not showing in the galley view section. In the submission_files table there is a field called file_stage. It is set to 2 for each attached (public) supplementary file. For the actual article galleys it is always 10.

If I change that value from 2 to 10, the galley view section is loaded and also the supplementary file is visible.

Is this something you could fix in the upgrade script? There are of course other files attached to a submission in the submission_files table so I can not simply update the table and replace 2 with 10 in the file_stage field.

Galley view if supplementary files have file_stage set to 9 or less:

Galley view if supplementary files have file_stage set to 10 or more:

Edit2: in the original OJS2 database the same file has file_stage set to 6 in article_files table.

Edit3: The last query in 3.0.0_update.xml should change that value to 10, but for some reason this is not happening with supplementary files <query>UPDATE submission_files SET file_stage=10 WHERE file_id IN (SELECT file_id FROM submission_galleys)</query>. I checked submission_galleys table and the supplementary file is there. No idea why only the actual galley file is getting updated to 10 and the supplementary files keep on having 2 in file_stage.

Edit4: Running that query in the database solved this problem (<query>UPDATE submission_files SET file_stage=10 WHERE file_id IN (SELECT file_id FROM submission_galleys)</query>). I still do no understand why this did not work during the upgrade process?

Edit5: Another problem. Although the galley view is now loading, the links leading to the supplementary files are not working anymore.
This is because the upgrade script has renamed the files like this 49454-216-40616-1-2-20150312.doc. If I understand correctly, the last 2 before the timestamp equals to the value in file_stage field. Now that the value is 10, the script is looking for a file named 49454-216-40616-1-10-20150312.doc, which does not exist. So, any suggestions how to do the upgrade so that the supplementary files get the right file_stage and the renamed filenames are correct?

9

Hi @ajnyga,

Alternately, I suspect it’ll be best to relax the current restriction on the galley files listing to permit both SUBMISSION_FILE_PROOF and SUBMISSION_FILE_SUPPLEMENTARY. You can do this by editing controllers/grid/articleGalleys/ArticleGalleyGridCellProvider.inc.php. Find the code that fetches the file inorder to present the link:

import('lib.pkp.classes.submission.SubmissionFile');
$submissionFile = $submissionFileDao->getLatestRevision(
    $element->getFileId(),
    SUBMISSION_FILE_PROOF,
    $element->getSubmissionId()
);

Change it to:

import('lib.pkp.classes.submission.SubmissionFile');
$submissionFile = $submissionFileDao->getLatestRevision(
    $element->getFileId(),
    null,
    $element->getSubmissionId()
);

Please confirm whether this resolves the issue (you’ll have to reset the file_stage records you changed) and if so I can commit to our code repository.

Regards,
Alec Smecher
Public Knowledge Project Team

10

Hi,

That does sound like something that would solve it. I will check if I remembered to take a backup before I updated the file_stage fields. If not, I will do another test upgrade on Friday anyway.

I still have to solve this as well in the next upgrade test: OJS 3.0 upgrade fails to move/rename some supplementary files
I will probably look for a script that will change the extensions to small case and run that before the update, but I think that the issue mentioned there is something that should be taken into consideration also in the upgrade script.

11

Hi,

I can confirm that this solves the problem. Thank you so much.

I still do not understand why the supplementary files get file_stage=2 during the upgrade. Hopefully this does not create other problems later on?

The same thing happened when I installed a fresh 2.4.8.1., created on journal, one issue and one article with one galley file and one supplementary file. The supplementary file had file_stage=2 after an upgrade to OJS3 and the galley view did not load.

ps. if possible, please comment my issue here: OJS 3.0 upgrade fails to move/rename some supplementary files I will do another test upgrade on Friday and it would be nice to solve the extension problem as well. As I said, I can of course run a script of my own pre-upgrade, but this is probably something that other users will experience as well.

12

Hi @ajnyga,

Thanks for confirming – I’ve committed the proposed change here:

The file stage of 2 is OK for upgraded data.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
13

Hi,

I did another test upgrade and had a lot of these errors:

Warning: Invalid argument supplied for foreach() in /var/www/ojs.tsv.fi/public_html/classes/install/Upgrade.inc.php on line 1182
PHP Warning: Invalid argument supplied for foreach() in /var/www/ojs.tsv.fi/public_html/classes/install/Upgrade.inc.php on line 1191

These are maybe connected to the problem with the file_stage field.

14

Hi @ajnyga,

Those pieces of code didn’t change, and it suggests that the system wasn’t able to fetch the files it needed to get from the database. Are you sure you dropped the database entirely and re-created an empty database before restoring the 2.4.x database?

Regards,
Alec Smecher
Public Knowledge Project Team

15

I think there is a slight misunderstanding here. Your proposed change is working like you thought it will and I am happy with this solution while it does not create any problems later.

I just noticed during another test upgrade from 2.4.8.1 to 3.0 that I was getting a lot of these errors and by looking at the code they involve these could perhaps explain why the file_stage stays in 2.

It was definitely a clean database. It is a dump from the production server.

16

Hi @ajnyga,

The file_stage of 2 is OK going forward. If this is a different database, I suspect there’s possibly some kind of data discrepancy that’s preventing OJS from fetching file lists for certain submissions.

Regards,
Alec Smecher
Public Knowledge Project Team

17

It is the same OJS installation, or a copy of it. I just did another test upgrade from 2.x to 3.0 after solving some issues I have reported here.

Those two errors are basically the last known problems I have. There were 164 of them during the upgrade. I was thinking of editing the upgrade code so that I can debug what is happening there. We have so much content that 164 files missing is hard to track.

18

Hi @ajnyga,

Hmm, I’m still confused by these messages appearing now when they didn’t before. The upgrade code hasn’t changed, so those shouldn’t be appearing now where they didn’t before – hence my suggestion earlier that you ensure you’re starting with an empty database before you restore the database dump from backup.

Regards,
Alec Smecher
Public Knowledge Project Team

19

Oh, these were most likely in the first upgrade as well. It was just that the terminal was so full of other errors as well (hundreds) because the upgrade script did not find files that had the extension written in capital letters. After fixing that issue most of the error messages disappeared and I was left with these.

I will let you know when I do another test upgrade on friday and try to debug this as well.