CUNY Academic Commons

Can you please share the URL of an affected page?

Ah, duh. So Sorry.

https://pirjournal.commons.gc.cuny.edu

https://pirjournal.commons.gc.cuny.edu/2023/09/24/puppet-matters-new-materialism-and-ecocriticism-in-contemporary-puppetry/

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

....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.

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.

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.

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.

Thanks Boone.

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

Thanks, Laurie and Ray!

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.

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.