Problem/Motivation
Image styles that utilize core's ConvertImageEffect will change/append the image extension (for instance, source image of foo.jpeg may have a file extension of foo.jpeg.png in an image style that converts the type.)
Core's image module handles this like so:
// Don't try to generate file if source is missing.
if (!file_exists($image_uri)) {
// If the image style converted the extension, it has been added to the
// original file, resulting in filenames like image.png.jpeg. So to find
// the actual source image, we remove the extension and check if that
// image exists.
$path_info = pathinfo($image_uri);
$converted_image_uri = $path_info['dirname'] . DIRECTORY_SEPARATOR . $path_info['filename'];
if (!file_exists($converted_image_uri)) {
$this->logger->notice('Source image at %source_image_path not found while trying to generate derivative image at %derivative_path.', ['%source_image_path' => $image_uri, '%derivative_path' => $derivative_uri]);
return new Response($this->t('Error generating image, missing source file.'), 404);
}
else {
// The converted file does exist, use it as the source.
$image_uri = $converted_image_uri;
}
}
Steps to reproduce
Add an image style that changes file type, and note the error generating the image on a local environment.
Proposed resolution
Adjust the FetchManager::fetch code to account for this scenario.
Remaining tasks
User interface changes
API changes
Data model changes
Comments
Comment #2
jhedstromThis is a little messy since the error handling in the
fetchmethod isn't actually currently catching non-200 responses (Guzzle now throwsClientException), but it addresses the issue at hand.Comment #3
gg24 commentedRerolled the patch
Comment #4
maxstarkenburgThanks, I tried the patch in #3, which seemed to resolve the 404 errors I was getting for some images that seemed to have a "Convert [to] JPG" filter applied to their style. I can't speak to the patch code, or the misgivings expressed in #2's, but I can at least say "Tested (if not fully reviewed) by (this member of) the community".
Comment #5
maxstarkenburgFWIW, even with this patch in place, I still seem to be getting the same error as before, that is ...
... when uploading a PNG (to a field with a JPG conversion effect) on my local (so I'm surprised/confused that SFP is looking for it on prod). The patch doesn't seem to be causing it though (it still happens after removing the patch), so I wonder if there might be another place in the code this needs to be applied. (FWIW, I do have
$config['stage_file_proxy.settings']['hotlink'] = FALSE;, which I thought should mention in case I'm misunderstanding that setting: maybe it always tries to grab images from prod even if uploaded locally? (though I would have thought I would have seen more 404s in the past then, unless the non-conversion ones just failed silently)).Comment #6
gedvan commentedThis is a duplicate of 2833845.
Comment #7
smustgrave commentedWould say https://www.drupal.org/project/stage_file_proxy/issues/2833845 should be closed as that issue hasn't been touched in 2 years this one seems to be getting more attention. Credit should be moved over by the maintainer before doing so.
Comment #17
smustgrave commentedMoving over credit from the duplicate issue above.
Comment #18
smustgrave commentedAs reported in #5 the patch in #3 may not be working. Could someone else verify?
Comment #19
plachThis is a reroll (+ typehint cleanup) of #3, which is working for our use cases (webp conversion).
Comment #20
smustgrave commentedComment #23
smustgrave commented