Project

General

Profile

Actions

Bug #19055

closed

Images not appearing on site

Added by Laurie Hurson 5 months ago. Updated about 1 month ago.

Status:
Resolved
Priority name:
Normal
Assignee:
-
Category name:
-
Target version:
Start date:
2023-10-19
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Hi All,

Message from a user below. I have been able to recreate the issue on the site in firefox and chrome.

They are not running any plugins that I think would cause this. Will you take a look?

Thank you!

Message
> "We have had a consistent problem with images even though we turned off jetpack where certain ones just will not load on the first try, only on refresh. I looked and some do have a 500 error. I tried just to change the captions and see if the metadata was messing things up but no consistent success. I have also tried making sure all the images are smaller, but many pages, very small images are not loading. There is one error about an event listener that I cannot make sense of and may not be connected at all.

Screenshots Attached


Files


Related issues

Related to CUNY Academic Commons - Bug #19400: Images not loadingNew2023-12-11

Actions
Actions #1

Updated by Boone Gorges 5 months ago

Can you please share the URL of an affected page?

Actions #3

Updated by Laurie Hurson 5 months ago

I also forgot to add that usually the images load upon refresh or upon second visit but when you visit as new visitor you get the error

Actions #4

Updated by Boone Gorges 5 months ago

  • Target version set to 2.2.1

Thanks, Laurie.

I also forgot to add that usually the images load upon refresh or upon second visit but when you visit as new visitor you get the error

This is because the images are loaded in your browser cache. So we can ignore this part of the issue - the problem is with the initial load.

I'm able to reproduce the problem very sporadically, maybe one out of every 20 pageloads. In those cases, the image request results in a 500 error.

I noticed that the failing requests on this specific page are of the form [url]/files/... and not [url]/blogs.dir/[blogid]/files... The src attribute for the images uses the blogs.dir URL, but the srcset uses the masked /files/ URL. This suggests that the problem is occurring only with async loaded images. It seems like it would be an enhancement for the Commons if srcset paths were built using /blogs.dir/, since they'd then avoid the wp-content/cac-files.php script. I think I will add a filter that catches wp_calculate_image_srcset and rewrites the URLs accordingly, but I'll hold off in case Ray or Jeremy see a problem with doing so.

If the problem is indeed limited to images that are loaded from the rewritten /files/ URL, it could be that the srcset rewriting described above will solve the immediate problem. It doesn't address the underlying issue of why the 500 errors are occasionally appearing, though. It's possible that there's a firewall-level rule that's rejecting the async requests because of their frequency or something like that. I'm not sure how we would do deeper investigation without close support from IT. For this reason, I'd like to suggest that we go with my workaround - avoiding the 500s by serving the srcset files directly from Apache and bypassing the WP application - to see if it is a good-enough solution.

Actions #5

Updated by Laurie Hurson 4 months ago

....For this reason, I'd like to suggest that we go with my workaround - avoiding the 500s by serving the srcset files directly from Apache and bypassing the WP application - to see if it is a good-enough solution.

This sounds good to me. Unless Ray and Jeremy have other thoughts.

Let me know what you all decide and I can let the commons user know.

Thanks so much for looking into this.

Actions #6

Updated by Raymond Hoh 4 months ago

I think I will add a filter that catches wp_calculate_image_srcset and rewrites the URLs accordingly, but I'll hold off in case Ray or Jeremy see a problem with doing so.

Boone, we had a similar discussion about this back in https://redmine.gc.cuny.edu/issues/15767#note-7 . Perhaps we should use the 'wp_get_attachment_url' filter and do the /blogs.dir/ replacement there and only if the site is public. I guess the one concern with this approach is if a site goes private after being public and if a public attachment URL gets saved into the post content. If that is the case, we would have to do some on-the-fly determination on the domain and whether the user has access to the private site.

Actions #7

Updated by Boone Gorges 4 months ago

I guess the one concern with this approach is if a site goes private after being public and if a public attachment URL gets saved into the post content. If that is the case, we would have to do some on-the-fly determination on the domain and whether the user has access to the private site.

This protection should already be in place. When blog_public is set to less than 0, an .htaccess file is created in that site's blogs.dir directory. See https://github.com/cuny-academic-commons/cac/blob/a7fe75794d902f9927622efca87cc61ee8590486/wp-content/mu-plugins/cac-file-protection.php#L83, #7997.

We already do this for mapped domains. See https://github.com/cuny-academic-commons/cac/blob/a7fe75794d902f9927622efca87cc61ee8590486/wp-content/mu-plugins/assets/mercator.php#L93, #18204, #15767. I think perhaps I will eliminate this Mercator-specific code, and will instead do the attachment-URL rewriting for all sites.

Actions #8

Updated by Boone Gorges 4 months ago

  • Status changed from New to Testing Required

My comment above about expanding the Mercator fix was incorrect. The Mercator-focused fix was to ensure the consistency of the domain used for attachment URLs. In this case, our goal is to ensure a consistent path.

In any case, I've put the proposed fix in place in https://github.com/cuny-academic-commons/cac/commit/0d7fccbab62a52e015de29bbc54c82ee07d0e4af. It filters 'wp_get_attachment_url', but this function is not part of the stack when building srcsets, so there's another filter in place that specifically targets srcset calculation.

Laurie, could you run some initial tests on the site in question to see if you are able to reproduce the original issue?

Actions #9

Updated by Laurie Hurson 4 months ago

Thank you both for looking into this.

The users are still reporting issues on the following pages

1. Wayang and Lighting article (figure 1)

https://pirjournal.commons.gc.cuny.edu/2023/10/03/revitalizing-wayang-puppetry-through-creative-lighting/

2. Karen Smith’s Wayang pUppetry now report, first photo,

https://pirjournal.commons.gc.cuny.edu/2023/10/05/conference-report-wayang-and-puppetry-now/

3. Mari Boyd, first photo; And a later photo, maybe 5th.

https://pirjournal.commons.gc.cuny.edu/2023/09/23/the-name-succession-investitures-of-the-youki-marionette-family-interweaving-the-old-and-the-new-in-edo-string-puppetry/

4. Alissa Mello first photo

https://pirjournal.commons.gc.cuny.edu/2023/10/06/conference-report-portrait-of-the-puppeteer-as-author/

The only issue I can create is on the first article (1. Wayang and Lighting article (figure 1)) on the photo following the line:
"Balinese Hindu ideology are called the Panca Maha Buta; pertiwi (earth), apah (water), bayu (wind/air), teja (light/fire), and akasa (sky)."

See screenshot. I can only recreate this issue in safari and chrome, not firefox. Are either of you seeing this issue as well? Is this image somehow served differently?

I don't know why the users are continuing to see issues across the site. Is it possible this is a cache issue for the other articles?

Actions #10

Updated by Boone Gorges 4 months ago

Thanks for following up.

I'm able to reproduce the problem on https://pirjournal.commons.gc.cuny.edu/2023/10/03/revitalizing-wayang-puppetry-through-creative-lighting/, though only very intermittently.

I found a StackOverflow issue that suggested that we ought not to be determining the Content-Length when using Sendfile, because Apache will do it for us. I've implemented this change in https://github.com/cuny-academic-commons/cac/commit/0f8e8483f97db4b650662657848947124e1a861a See https://stackoverflow.com/questions/3998111/xsendfile-wont-serve-the-files-in-apache-2-2 However, this change did not affect the behavior - I'm still able to occasionally get the 500 error for the image.

The markup for the ChartImage-1.jpeg image is different from others on the page. Specifically, it doesn't have the decoding="async" attribute, nor does it have srcset. It also uses the /files/ rewritten URL rather than the blogs.dir URL. I'm unsure why this specific image is different - there must've been something different about the way the image was uploaded, or perhaps the way it was inserted. (Maybe before the Block Editor?) I've manually changed the img tag so that it uses the URL https://pirjournal.commons.gc.cuny.edu/wp-content/blogs.dir/22962/files/2023/09/ChartImage-1.jpeg and the problem now goes away. If the site admins notice a similar issue on other images, they could make the corresponding URL format change on those images, and it should fix the issue.

All of this doesn't settle the question of why Apache is occasionally throwing 500 errors when attempting to serve a file using Sendfile. It seems to occur only with async images, which suggests that it's triggering a sort of security rule ('referer' sniffs or something like that). I'm unsure how to debug this further at this time, so hopefully the workaround described in the previous paragraph, along with the filters I put in place earlier in the ticket, will be sufficient for this specific user.

Actions #11

Updated by Boone Gorges 4 months ago

  • Target version changed from 2.2.1 to 2.2.2

Some of the fixes described here were shipped as part of the 2.2.1 release, but I'm moving to 2.2.2 so that we can continue to track.

Actions #12

Updated by Laurie Hurson 4 months ago

If the site admins notice a similar issue on other images, they could make the corresponding URL format change on those images, and it should fix the issue.

I realize I should have asked this on the dev call -- how do I edit the image URLs? I thought this would be clear from poking around the media library but I cannot find where to edit. I can see the URl but do not have editing privileges.

https://pirjournal.commons.gc.cuny.edu/wp-admin/post.php?post=175&action=edit

Actions #13

Updated by Raymond Hoh 4 months ago

I realize I should have asked this on the dev call -- how do I edit the image URLs? I thought this would be clear from poking around the media library but I cannot find where to edit. I can see the URl but do not have editing privileges.

Hi Laurie,

You would have to edit the post in question and edit the HTML manually from the Image block. I've attached an animated GIF where you would have to make the change.

In the GIF, you would change:

https://pirjournal.commons.gc.cuny.edu/files/2023/09/Fig-3-Feet.jpg

to:

https://pirjournal.commons.gc.cuny.edu/wp-content/blogs.dir/22962/files/2023/09/Fig-3-Feet.jpg
Actions #14

Updated by Laurie Hurson 4 months ago

Thanks Boone.

I have updated all the HTML for all the images on the site now, and I hope this resolves the loading issue.

Actions #15

Updated by Boone Gorges 4 months ago

Thanks, Laurie and Ray!

Actions #16

Updated by Laurie Hurson 4 months ago

Hi All,

Just circling back to this to ask one more question. The site admins want to install aplugin that provide site views and stats, and the obvious answer is Jetpack. But they are claiming that install Jetpack previously is what started these image issues.

Based on what you have seen here, is that possible? Would re-installing jetpack re-create all these images, and/or somehow revert all the links to the problematic URL path?

Thanks in advance for any insight you can provide on this weird question.

Actions #17

Updated by Boone Gorges 4 months ago

I'm pretty sure that Jetpack won't recreate any images, nor will it change the content of your posts as they exist in the database. It's possible that Jetpack will attempt an on-the-fly filtering of post content to swap out some image URLs, though this ought to be reversible by deactivating Jetpack. So I think it's safe to test by activating the plugin.

Actions #18

Updated by Boone Gorges 4 months ago

  • Target version changed from 2.2.2 to 2.2.3
Actions #19

Updated by Boone Gorges 3 months ago

  • Target version changed from 2.2.3 to 2.2.4
Actions #20

Updated by Boone Gorges 3 months ago

Actions #21

Updated by Boone Gorges 3 months ago

  • Target version changed from 2.2.4 to 2.2.5
Actions #22

Updated by Boone Gorges 2 months ago

  • Target version changed from 2.2.5 to 2.2.6
Actions #23

Updated by Boone Gorges about 2 months ago

  • Target version changed from 2.2.6 to 2.3.1
Actions #24

Updated by Boone Gorges about 1 month ago

  • Status changed from Testing Required to Resolved

Closing this ticket due to lack of activity. Feel free to reopen if related issues arise. Thanks!

Actions

Also available in: Atom PDF