OJS: Broken images in HTML galleys

Software Support
1

We have a number of older issues for which we did HTML versions of the articles as well as PDF. These HTML versions used to work fine. Now, the inline images are failing to load. See from V1 (2019-05) of the journal, for example:

https://journals.h-net.org/jfs/article/view/31/192

According to the HTML, the missing image is supposed to be here:

https://journals.h-net.org/jfs/article/download/31/version/2/192/4097/Gaebel_review_cover.jpg

but that fetch gets an HTTP 404. No file of that name exists on the server. The relevant image appears to be on the server as:

uploads/journals/4/articles/31/6669e4c800744.jpg

How can I fix these?

Version history:

3.3.0.15 	3 	3 	0 	15 	2023-08-18
3.3.0.14 	3 	3 	0 	14 	2023-04-11
3.3.0.3 	3 	3 	0 	3 	2021-02-18
3.1.2.1 	3 	1 	2 	1 	2019-06-14
3.1.1.4 	3 	1 	1 	4 	2019-01-03
3.1.1.1 	3 	1 	1 	1 	2018-06-13

Server information:

OS platform 	SunOS
PHP version 	7.4.33
Apache version 	nginx/1.26.1
Database driver 	pgsql
Database server version 	14.7

I see two posts about similar problems:

Neither seem like quite the same problem.

2

Hi @drboone,

Do you know if these images broke across a particular upgrade?

Regards,
Alec Smecher
Public Knowledge Project Team

3

Alec,

While that seems likely, I don’t think I can point to the point in history where it arose. I think the key staff member I should check with is out today, but I’ll see if we can choke up on the failure time.

De

4

Actually, I was mistaken. After checking, these HTML galleys were done this summer, so no upgrades involved.

5

Hi @drboone,

I think this is an nginx configuration issue. Looking at your image URL:

https://journals.h-net.org/jfs/article/download/31/version/2/192/4097/Gaebel_review_cover.jpg

I get an nginx-branded 404 page when I try to access it. However, if I take the suffix off the filename and try this:

https://journals.h-net.org/jfs/article/download/31/version/2/192/4097/Gaebel_review_cover

…then it successfully downloads.

I suspect nginx is configured to look for requests that look like filenames, and handle them outside of PHP. This might e.g. be part of your URL rewriting configuration.

(OJS lets the last part of the URL take whatever form it likes, as long as the IDs are correct. That way third party client-side tools that expect filenames will be happy.)

Regards,
Alec Smecher
Public Knowledge Project Team

7

This topic was automatically closed after 13 days. New replies are no longer allowed.