OJS 3.1.1.2 HTML galley images not loading after Native XML import

Hi there,

We are running an instance of OJS 3.1.1.2 on RedHat Linux, with PHP 5.6 and FastCGI.

Late last year we migrated an older standalone OJS 2.x journal from another institution by creating a local dev instance of it and upgrading to 3.1.1.2. We then did a native XML export of all issues, articles and users into the RedHat shared instance.

Unfortunately we just discovered that for the older articles that used HTML galleys that the images are not loading in the browser.

For example, https://openjournals.uwaterloo.ca/index.php/JoCI/article/view/2839. If you click on “HTML” it will go to https://openjournals.uwaterloo.ca/index.php/JoCI/article/view/2839/3640. If you scroll down the page to Figure 1, you’ll see it does not load. The HTML is referencing “figure1.png”, which does correspond correctly to the png file in the files folder. As well, in the database, the file_id (13669) matches the filename for the png (2839-178-13669-1-17-20201123.png).

So, if you use browser tools and change “figure1.png” to “https://openjournals.uwaterloo.ca/index.php/JoCI/article/download/2839/3640/13669” in the src it downloads correctly.

I have looked through some of the error reports others have had (including me) with 2.x → 3.1 migrations and HTML galleys. However, this was not a typical upgrade, but rather an XML export/import. The files all seem to be there, but OJS is just not rendering the images in the HTML galleys.

Any help is greatly appreciated!

Cheers,

Graham Faulkner
UWaterloo Library

Should I be adding the patch and running the script mentioned at Fix HTML galley image migration in OJS2 to OJS3 · Issue #2582 · pkp/pkp-lib · GitHub?

It looks to me like the issue that you linked was merged and released with OJS 3.1. So if you did an upgrade from 2.x to 3.1, that should have been applied already.

The code that transforms the URLs in the HTML galley is located here:

I’d recommend investigating to see if $embeddableFile->getOriginalFilename() is returning the expected name to match the preg_replace.

(I’d also recommend trying an upgrade to 3.3. It’s now been several years since 3.1.x was released and we are not able to provide much support for problems in that version.)