Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When the "use_imagecache_root" configuration is enabled and the site uses an image style using a conversion to webp, the original image is never downloaded. The "new" \Drupal\stage_file_proxy\EventSubscriber\StageFileProxySubscriber skips over the check for the "use_imagecache_root" for all relative paths added when the subscriber detects "webp".
For reference, \Drupal\stage_file_proxy\EventSubscriber\StageFileProxySubscriber:
// Is this imagecache? Request the root file and let imagecache resize.
// We check this first so locally added files have precedence.
$original_path = $this->manager->styleOriginalPath($relative_path, TRUE);
if ($original_path && !$is_webp) {
if (file_exists($original_path)) {
// Imagecache can generate it without our help.
return;
}
if ($config->get('use_imagecache_root')) {
// Config says: Fetch the original.
$fetch_path = StreamWrapperManager::getTarget($original_path);
}
}
Steps to reproduce
- Enable the "use_imagecache_root" stage_file_proxy configuration.
- Create an image style with a conversion to webp.
- Visit a page with an image using the test image style.
- Actual results: The image style derivative file is downloaded from the origin server.
- Expected results: The original image is downloaded from the origin server and then the image style derivative file is created locally using the original image.
Proposed resolution
- Fix the logic used in
\Drupal\stage_file_proxy\EventSubscriber\StageFileProxySubscriber. - Improve detection of image styles with a converted file.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|
Issue fork stage_file_proxy-3402972
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
recrit commentedMR 58 has been opened with the fix for the 2.1.x branch.
Attached is a static patch at commit 28f616d8 for any builds to use.
Comment #5
smustgrave commentedComment #7
smustgrave commentedMay have to revert this as it caused a regression #3409100: Regression - Local files with a dot in their filenames are not correctly served if a quick solution can be found over there can leave this in.
Comment #8
recrit commented@smustgrave the entire patch for this issue may not need reverted. I believe we might just need to revert this line change:
src/EventSubscriber/StageFileProxySubscriber.php: ~ line 190
Comment #9
smustgrave commentedIf I revert that in the other issue, does this one still work for you?
Comment #10
recrit commented@smustgrave Yes, this issue 3402972 is still fixed with the updates in #8
Comment #11
herved commentedHi @recrit, @smustgrave,
The suggestion in #8 doesn't seem to fix #3409100: Regression - Local files with a dot in their filenames are not correctly served.
Files with a dot are still "hotlinked" without the extension for me.
E.g: some.image.png?itok=**** > some.image?itok=****
Comment #12
idebr commentedThis issue adds an additional path to check for all files. All paths that are not available on the origin trigger an exception. As a result, the watchdog is now filled with Stage file proxy exceptions.
Comment #13
smustgrave commentedSince this issue has been merged for 2 months almost, reluctant to fully revert so would like to see if we can find a solution for both.
Comment #14
smustgrave commented@idebr can you post the error though. Then we can try and figure it out.
Comment #15
smustgrave commentedAlso @herved and @idebr does reverting this solve both issues?
Comment #16
idebr commentedStage File Proxy is now pinned to version 2.1.2 for my project to prevent the watchdog spam. A watchdog entry looks like this:
Comment #17
smustgrave commentedWill work on reverting this today.
Comment #19
smustgrave commentedReverted in https://git.drupalcode.org/project/stage_file_proxy/-/commit/06706daa72b...
Comment #20
smustgrave commentedDid a release for 2.1.4 with this reverted
Comment #22
trakoczi commentedI still have this problem with 2.1.4, it is unclear to me if I can do anything about it or not, but here is the error:
Stage File Proxy encountered an error when retrieving file https://www.***.***/sites/default/files/styles/large/public/2024-02/myfi.... Client error: `GET https://www.***.***/sites/default/files/styles/large/public/2024-02/myfi...` resulted in a `404 Not Found` response:
The GET request misses the .png extension of the file.
Comment #23
smustgrave commentedI reverted the change from this ticket as it caused other failures. So this solution may be on track but needs work.
Comment #24
recrit commentedIn case anyone is looking for the functionality of this patch, I have attached a patch that works with the latest 2.1.x-dev which still has the method for "getFilePathWithoutConvertedExtension".
Comment #27
carlos romero commentedWith 2.1.4 on drupal 10.2 get error when apply the patch, i was updated the 2.1.x branch and reroll the patch
Comment #28
saidatomRTBC #24 - https://www.drupal.org/files/issues/2024-03-29/stage_file_proxy-3402972-... works fine
Comment #29
herved commentedThis is still causing issues for me.
With both hotlink and use_imagecache_root set to TRUE, and using a file with a dot in its name e.g.: foo.bar.jpg it redirects to foo.bar and wrongly strips the extension (expected is foo.bar.jpg).
You can replicate this with an image field directly with the widget preview (using thumbnail image style which doesn't use any image_convert effect).
Can anyone else confirm this? I'm moving this back to needs work for now.
If I understand correctly, there are multiple scenarios depending on hotlink=TRUE/FALSE and use_imagecache_root=TRUE/FALSE.
Also I wonder, why would this be limited to webp? I suspect it is applicable to any image style using the image_convert effect (which can have many more supported extensions like webp, png, jpeg, jpe, gif,..).
Comment #30
smustgrave commentedFix appears to be the same solution posted here #3439840: Webp images are not getting generated locally.
Can someone test that ticket please.
Comment #31
herved commented#29 still holds true, for me.
I'll crosslink it there.
Comment #32
smustgrave commentedSeems still an issue. Closing the other issue as duplicate
Comment #34
tonypaulbarker#28 worked for me. I do not have the cases described in #29. I think those cases are less common than my case, which is no dots in the filename and converting JPEG to WebP. This issue describes a problem for webp images and I don't think a problem has been reported for other file types. As long as we don't introduce new issues, could we improve this for the majority of cases and then other potential cases be handled on follow up tickets?
Comment #35
idebr commentedWe can use Core's ImageStyleDownloadController::getUriWithoutConvertedExtension to get the the original file extension. This prevent the issue getting the filename without a dot as reported in #16
Comment #39
smustgrave commentedLike the approach, would like someone who's been experiencing this issue to mark it though.
Comment #40
idebr commentedComment #41
justinchev commentedI was experiencing the issue with the double file extensions, eg. *.jpg.webp.
Applied the patch in #40 to 3.1.0 and it has resolved the issue for me.
Comment #43
smustgrave commentedLets give it a shot.
Comment #44
carlos romero commentedHi, I have reverted the commit of in branch 3402972-2.1.4.
The method ImageStyleDownloadController::getUriWithoutConvertedExtension is not present in Drupal version 9.5.x, the 2.x version of stage file proxy is for Drupal 9.x and 10.x.
idebr thanks for the contribution, but this only applies to version 3.x of stage file proxy.
Thanks
Comment #45
herved commentedI'm encountering an intermittent bug where Drupal messages (from the messenger service) are not rendered consistently. This seems to occur when generating image style derivatives for local images that contain dots in their filenames, e.g.: public://random_66d64a4456c133.73906322.png
Somehow the messages are registered in
\Drupal\Core\Messenger\Messenger::addMessageand are present in flashbag but they are not present when retrieved to be printed in\Drupal\Core\Messenger\Messenger::deleteAll. It looks like the flashbag reference is lost somehow. Maybe because ofreturn new Response()in \Drupal\image\Controller\ImageStyleDownloadController::deliver ?I see 2 records in such cases in dblog:
- Source image at public://random_66d653fc1a31f4.61396650.png not found while trying to generate derivative image at public://styles/col_lg_2_4x3/public/random_66d653fc1a31f4.61396650.png.
- Stage File Proxy encountered an error when retrieving file https://[prod_domain]/sites/default/files/styles/col_lg_2_4x3/public/random_66d653fc1a31f4.61396650.png. Client error: `GET https://[prod_domain]/sites/default/files/styles/col_lg_2_4x3/public/random_66d653fc1a31f4.61396650?itok=xzHldlkP` resulted in a `404 Not Found` response:
> notice the missing png extension in the request URL.
Reverting to 3.1.0 or disabling stage_file_proxy fixes it.
I'll open a new issue and provide more info soon when I have some more time.
Comment #49
lincoln-batsirayi commentedI'm still getting this issue with the double file extensions, eg. *.jpg.webp using the module version 3.1.3 and 3.1.4 and on drupal 10.3.10, does anyone have any ideas? Looking at my sites/default/styles/[name-of-image-style] directory they just aren’t generated at all, I’ve also tried doing "drush if" on those image styles but it hasn’t worked either
Edit: I forgot to note that this is happening for newly uploaded images on a responsive image component like this:
Comment #50
mably commentedSill being hit by the problem, so it looks like it's not really fixed.
Stage File Proxy is fetching
.jpgstyled files instead of.jpg.webp...Any solution?
Drupal 11.1.8 with Stage File Proxy 3.1.5.
Looks like my problem could rather be cURL related:
cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.bordeaux.fr:443 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://www.bordeaux.fr/sites/bor-bdxfr-drupal/files/styles/3_2_930x620/public/2025-06/Panneau-17-_Alban-Gilbert--mairie-de-Bordeaux.jpg.webp?itok=-GGB5i9aEDIT: It was a Docker networking problem, everything is finally working fine.