Describe the issue or problem
We recently created a new version of an existing article and uploaded the associated galley files to that version and published it. Now when I attempt to view any of the galley files from the older version, they return 404 errors but the newer versions do not.
Steps I took leading up to the issue
For example:
Unpublish an existing article
Create a new version
Add a galley file to the new version
Re-publish
View the article in the front-end, change to version #1 and click the galley link - it will 404. (Version #2 galley files look fine)
What application are you using?
OJS 3.3.0-19
Additional information
This is an anonymised log entry for one of the 404’s:
2025/10/23 13:13:56 [error] 85881#85881: *112264 FastCGI sent in stderr: “PHP message: ojs2: 404 Not Found” while reading response header from upstream, client: xx.xx.xx.xx, server: server.website.org, request: “GET /index.php/XX/article/download/47 HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php8.1-fpm.sock:”, host: “server.website.org”, referrer: “https://server.website.org/index.php/XX/article/view/47/version/38”
Additionally, I wrote a small utility to query the database, given an article ID it will return all versions and their galley files, shown red where the files do not exist and green where they do. However, in the first version (at the top of the screenshot) the galley files are missing and return 404 errors. The single green galley file in the first version was one I re-uploaded, so it DOES exist on disk, but it still returns a 404!
Quick update, seems I’ve opened a can of worms!
The submission_galleys database table is/was missing entirely from my installation, possibly as a result of a failed upgrade some time ago.
The database schema appears to have some issues also, the submissions_file_revisions table has a mismatch between the actual and expected fields: revision_id versus revision
I recreated the submission_galleys table and created the missing revision_id field and I’m hoping this will be sufficient to correctly reference galley files from now on as I’m assuming the backend functionality will work for future submissions.. That’s my hope at least, and I’ll post my results back here.
Is my installation broken? Could it be the result of a failed (silent) upgrade some time ago?
This query indicates the updgrades that I performed recently and shows the upgrade path since the journal went live. You can see that the “Product” column indicates that the journal is running OJS2. Should this be showing OJS3?
The submission_galleys table shouldn’t exist in a OJS 3.3.0-x database; it was present in older branches, but was shifted to publication_galleys to accommodate submission versioning (where an article can have multiple versions) when that feature was added some years ago.
The ojs2 in the versions table is expected; eventually we’ll clean it up, but it’s just cosmetic, and best not to change.
Since you mentioned failed upgrades, are you sure you’re currently running a “clean” 3.3.0-x, or is it possible that there was a failed upgrade to 3.4.0-x? Check dbscripts/xml/version.xml to see what version your code is.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks Alex for the information - most useful, seems I’ve been chasing a wild goose with the submission_galleys direction. I’ll factor that into my investigations and post back here if I encounter any issues.
Update: I managed to find a solution that I could incorporate into my own theme. The galley_link.tpl file just needed to have the URL constructed correctly.. job done.
