Images not displaying in HTML versions of articles

MashriqMahjar · February 16, 2022, 8:32pm

Problem:
We are implementing new HTML formatting for our journal articles. However, the images are not showing up in the HTML versions, despite being uploaded to OJS and having the code be correct (see images). Here’s an example of a published article with no images displaying.

What I tried to resolve the issue:
I tried playing around with the code and also uploading images as different file formats (PNGs, etc). We have another article whose HTML has embedded images and that one works just fine. I compared the HTML between the two and could not see a difference.

Application Version: 3.3.0.8

Screenshots:
Screen Shot 2022-02-16 at 3.24.38 PM
Screen Shot 2022-02-09 at 9.15.33 AM

rcgillis · February 16, 2022, 11:52pm

Hi @MashriqMahjar,

What options do you have for the dependent files? Could you share a screenshot of that, please? It looks as though they are possibly being stored in a non-web accessible location so won’t be displayed on the web?

-Roger
PKP Team

MashriqMahjar · February 17, 2022, 2:19pm

Hi Roger,

Thank you for getting back to me so quickly! Do you mean options within OJS for dependent files? It looks like multimedia, images, and HTML stylesheet. I attached a screenshot. I uploaded these image files as images, and our style is embedded within our HTML code so we don’t need to add the stylesheet.

Yes, I uploaded them from my computer, so they aren’t on the web. Do they need to be stored on our website to load? I don’t believe that was the case with the published article whose images are displaying (see second screenshot). We can try to do that, though, if need be.

Screen Shot 2022-02-17 at 9.11.27 AM

Screen Shot 2022-02-17 at 9.17.59 AM

rcgillis · February 17, 2022, 3:33pm

Hi @MashriqMahjar,

I was curious where the images on the galley that was not working were being uploaded to, because for the example that you provided for the one that was working, these appear to be uploaded to your site without any issues, as well as one at least at the start of the galley that appears to be using a remote URL for an external website. Are you able to see the file path for the uploaded images for the galley that isn’t working?

-Roger

MashriqMahjar · February 17, 2022, 5:00pm

Hi Roger,

I’m not able to see the file path for the uploaded images–or at least I’n not sure how to access that information. It is just strange to me since the images as uploaded with the HTML as dependent files, so I’m not sure why it would need to be stored elsewhere (i.e. on our website).

micahvandegrift · February 17, 2022, 5:54pm

Hi @rcgillis I’m on the library side and working with the journal to figure this out. I was able to backwards engineer the URL where Image 1 for the broken article is hosted: https://lebanesestudies.ojs.chass.ncsu.edu/index.php/mashriq/article/download/13/459/1824

I found this by finding an image from the working article and changing the numbers after the download/… to match the article number (13), HTML view number (459), and then the image number (1824) which I found when looking at the supplemental files added to the HTML galley. So we could unpublish, edit the <img> tags in HTML to point to all those image numbers and theoretically, it should display?

The puzzling thing for me is when uploading the HTML the first time, we wouldn’t know what the image numbers would be until we connect them to the galley, right? And as long as on the 1st upload the HTML uses the proper image name “Fig1.jpg” in the <img src> tag, and we upload a file titled Fig1.jpg, OJS should see it and display, correct?

asmecher · February 17, 2022, 8:35pm

Hi @micahvandegrift,

OJS has code to look for images in the HTML markup and replace their URLs with ones matching the names of dependent files:

github.com

pkp/ojs/blob/stable-3_3_0/plugins/generic/htmlArticleGalley/HtmlArticleGalleyPlugin.inc.php#L135..L181

      
        
            	 * @param $galley ArticleGalley
            	 * @return string
            	 */
            	protected function _getHTMLContents($request, $galley) {
            		$submissionFile = $galley->getFile();
            		$submissionId = $submissionFile->getData('submissionId');
            		$contents = Services::get('file')->fs->read($submissionFile->getData('path'));
            
            
		// Replace media file references
            		import('lib.pkp.classes.submission.SubmissionFile'); // Constants
            		$embeddableFilesIterator = Services::get('submissionFile')->getMany([
            			'assocTypes' => [ASSOC_TYPE_SUBMISSION_FILE],
            			'assocIds' => [$submissionFile->getId()],
            			'fileStages' => [SUBMISSION_FILE_DEPENDENT],
            			'includeDependentFiles' => true,
            		]);
            		$embeddableFiles = iterator_to_array($embeddableFilesIterator);
            
            
		$referredArticle = null;
            		$submissionDao = DAORegistry::getDAO('SubmissionDAO');
            		foreach ($embeddableFiles as $embeddableFile) {

It should be enough to have an image tag using the name listed in the Dependent Files grid (e.g. “Figure1.jpg”) – making sure to urlencode any special characters that appear in the names (I don’t see any in your examples). The URL rewriting is done when the HTML is presented to the user.

At a glance, I think the problem might be that you’re using “smart quotes” (“ and ” rather than ") in your markup, judging by the screenshot above. Make sure to use regular " quotes.

Regards,
Alec Smecher
Public Knowledge Project Team

micahvandegrift · February 18, 2022, 2:04pm

HI Alec - thanks for this! We’ve had that smart quote issue before, and its one we never catch. Let me do some testing and see if that’s the culprit. Appreciate it!

asmecher · February 28, 2022, 4:00pm

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