michfield · May 20, 2025 07:18 · michfield · May 19, 2025 · michfield · May 20, 2025
diff --git a/tragic-support-transcript-raidboxes.txt b/tragic-support-transcript-raidboxes.txt
 Conversation with raidboxes®
 Started on May 15, 2025 at 04:06 PM Europe/Berlin time CEST (GMT+0200)

 --- May 15, 2025 ---

 04:06 PM | Customer: Hi Raidboxes! 
 What has happened to the 'WebP support' option? It is turned on, as it always was, but it seems to me that it no longer works.

 04:07 PM | Customer: For example, if I try this JPEG file (https://www.mysite.com/wp-content/uploads/2022/08/image.jpg), it is delivered as a JPEG, not as an AVIF or WebP file, although the AVIF and WebP files are in the right place: https://www.mysite.com/wp-content/uploads/2022/08/image.jpg.webp and https://www.mysite.com/wp-content/uploads/2022/08/image.jpg.avif
 04:07 PM | Customer: Could you do something on the back end to restore transparent support for modern image formats?
 04:08 PM | Customer: I think all of this began when we switched to the latest server.

 04:10 PM | Max from raidboxes®: Hi Customer, 
 
 this is Max from Raidboxes 👋 Can you please send me the page where this image is displayed at? :)

 04:10 PM | Customer: It's not the page. I've sent already all images.
 04:10 PM | Customer: It's nginx setting, not the page.
 04:10 PM | Customer: Please read my message again.

 04:11 PM | Max from raidboxes®: I read your message, but I want to check the page, where these images are displayed at.

 04:11 PM | Customer: Every page and every image has their WebP and AVIV counterparts. You can check any page.
 04:11 PM | Customer: You can go at any page
 04:11 PM | Customer: https://www.mysite.com/
 04:11 PM | Customer: Or whatever
 04:12 PM | Customer: https://www.mysite.com/medical-technology/
 04:12 PM | Customer: https://www.mysite.com/consumer-goods/
 04:12 PM | Customer: https://www.mysite.com/manufacturing-process/laser-cutting/

 04:12 PM | Max from raidboxes®: I'll have a look

 04:12 PM | Customer: I can send you more...

 04:12 PM | Customer: https://www.mysite.com/manufacturing-process/waterjet-cutting/

 04:14 PM | Customer: But original first message was most informative... You can take any image anywhere. Point is - WebP and AVIF versions are not served by nginx transparently... like they used to.

 04:14 PM | Customer: Maybe you've changed naming?

 04:22 PM | Customer: Thanks

 04:26 PM | Max from raidboxes®: We'll look into it, I'll take it to the team meeting tomorrow morning and clarify with my colleagues whether there has been a change or more frequent requests in this regard

 04:27 PM | Customer: Ok. So I'll have some info tomorrow or... ?

 04:27 PM | Max from raidboxes®: Yes, I think so

 04:27 PM | Customer: Great! Thanks!

 --- May 16, 2025 ---

 04:49 PM | Charles from raidboxes®: Hi Customer, 
 it's Charles here from Raidboxes 👋 
 
 I've looked into the issue did not find a general issue with the WebP implementation. 
 It's controlled by the rules at the top of your .htaccess file. 
 
 The WebP Version of the original images are there, that's true, but they don't seem to be generated for the additional thumbnail size WordPress Uses when displaying the smaller image variants. 
 
 I guess the issue would be solved by generating WebP for the other thumnail-sizes as well. 
 
 Kind regards

 12:49 AM | Raidboxes Assist: Rate your conversation

 --- May 17, 2025 ---

 01:42 PM | Customer: Let's continue... 
 
 1. I've checked the .htaccess in www and all the other .htaccess files up to the uploads folder. The main one in www is untouched and the same as you set. 
 I see that AVIF is not automatically served by your .htaccess, but I'll fix that and improve it later. 
 The good news is that I can change this in .htaccess. 
 2. 
 For you to test, I've put a single file in root called 1.png. 
 If you test it, you will see that it does not serve the WebP version that is there. It's not serving AVIF either, but we already know that's not expected from .htaccess as it is. 
 Please, test yourself... And then get back to me. 
 https://www.mysite.com/1.png 
 Thanks in advance. 
 Please don't give me generic answers. And please read the previous conversations.

 01:51 PM | Customer: This does NOT work: 
 curl -I -H "Accept: image/webp" https://mysite.com/1.png 
 On my staging server, works everywhere: 
 curl -I -H "Accept: image/webp" https://mystaging.com/wp-content/uploads/myimage.png 
 It is really ruining SEO for us, and that is happening for months now.

 02:01 PM | Customer: Just a thought - are you sure you don't have a configuration where Nginx or Varnish serves static files directly - bypassing Apache and its .htaccess rules.

 02:02 PM | Fernando from raidboxes®: Hi Customer, 
 Fernando here from Raidboxes 👋 
 
 We'll take a closer look and get back to you as soon as possible

 02:03 PM | Customer: I have mistake in some previous messages. It should be: 
 curl -I -H "Accept: image/webp" https://www.mysite.com/1.png 
 And this is improperly serving PNG, not webp, that is also there... 
 curl -I -H "Accept: image/webp" https://www.mysite.com/1.png.webp

 02:03 PM | Customer: Thanks!

 02:06 PM | Fernando from raidboxes®: Meanwhile, did you take a look closer to this article about webp here with us? 
 
 https://helpcenter.raidboxes.de/en/articles/2661817-webp-at-raidboxes

 02:22 PM | Fernando from raidboxes®: Which Plugin are you using to convert images into webp? Or do you upload them directly as webP? 
 
 And do you use any type of caching Plugin?

 06:21 PM | Customer: No plugin. Please, just test that one image.
 06:21 PM | Customer: No caching plugin also, as I have raidboxes caching.
 06:22 PM | Customer: Please, please, just test on that one image that I've sent to you.

 06:27 PM | Kimi from raidboxes®: Hey Customer, Kimi here from Raidboxes 👋 
 
 I see you are using a lot of plugins. 
 This is not good for your performance at all - but also plugins like "Performance Lab" are using the WebP delivery functions. 
 
 Please only use one tool to enable the WebP delivery and make sure you only use one cache at the time. 
 
 Try to enable the WebP support directly in the Performance Lab plugin if you want to use this plugin.

 10:16 PM | Customer: Lets imagine I'm not using WP at all... Just test on this one file: 
 https://www.mysite.com/1.png 
 No WordPress, no plugins. Do you want me to delete WordPress so you test this one file and make it work? 
 Please, don't ask me more questions about WordPress.

 10:17 PM | Customer: I don't have any problem with performance... The problem is "WebP Support" NOT WORKING. 
 Thanks again

 10:24 PM | Customer: How many times do I need to type the same information over and over again before somebody actually looks at what I'm asking? My question is simple and straightforward. 
 I could try to debug it for you. I could test whether static assets are served without ever reaching the .htaccess file. Would you like me to do that? Will I get some free months for this debugging work? 
 I really beg for skilled and experienced DevOps on the other end of the line.

 11:05 PM | Customer: I've done some debugging for you free of charge and found that the .htaccess file is not configured correctly to serve WebP files. 
 If there isn't a X.webp file, under no circumstances will a X.png.webp file be served when it should be. 
 You can hire me if you lack expertise, as this is a major issue – and it is probably affecting all your customers, as you are probably setting the default .htaccess file for everyone.

 11:09 PM | Customer: Hint: second set of rules not good

 --- May 18, 2025 ---

 10:53 AM | Fernando from raidboxes®: Hey Customer, 
 
 Thanks for your message. 
 
 Just to clarify: WebP is working properly on our end. I'm not quite sure what you're expecting to test with a PNG file—it might be a misunderstanding. WebP is supported as soon as the server detects a WebP file. It doesn't automatically convert PNG files to WebP. 
 
 It seems like you're expecting the server to convert your PNG into a WebP format on the fly, but that’s not how it works. I did mention this in our last conversation as well. 
 
 Have you had a chance to read our Help Center article about using WebP images with Raidboxes?
 It explains that you need to convert your PNG files to WebP yourself (or through a plugin like ShortPixel), and then upload and use the WebP version on your site in place of the PNG. 
 
 Regarding your comment "Let's imagine I'm not using WP at all..." – in that case, automatic conversion won’t work either. Our server is set up to serve WebP files if they are already available, but it doesn’t compress or convert image formats on its own. 
 To make things easier, I’ve prepared a small test page where you can see both image types in action—one native WebP file and one PNG converted via the ShortPixel plugin: 
 https://justanothertestdomain.de/ (https://justanothertestdomain.de/) 
 
 Let me know if anything’s still unclear!

 06:54 PM | Raidboxes Assist: Rate your conversation

 --- May 19, 2025 ---

 03:35 AM | Customer: No comment. This is outrageous.
 Can I complain somewhere?

 03:36 AM | Customer: Fernando, do you even know what this line does? 
 curl -I -H "Accept: image/webp" https://www.mysite.com/1.png

 11:36 AM | Fernando from raidboxes®: Hi Customer, 
 
 I just realized I forgot to include the correct subpage in the link I sent earlier — apologies for that! 
 
 You can find it here:
 👉 https://justanothertestdomain.de/sample-page/ (https://justanothertestdomain.de/sample-page/) 
 
 On that page, you can clearly see and test that the images are being served properly. Our WebP function is active and working as expected. 
 It’s possible there’s an issue on your end, especially considering the number of plugins you're using or some Plugins which do some custom code or changes in the handling Process of images — some of which might be interfering with image handling. 
 As for the curl command you mentioned — yes, I'm fully aware of how it works. You can test it yourself with this command: 
 curl -I -H "Accept: image/webp" https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-1.png 
 You’ll see from the response that WebP is being served properly when requested. I hope this helps clarify things a bit more. 
 If you still have doubts about the WebP functionality, feel free to set up a fresh box and run your own tests there — that way you can rule out any plugin conflicts or custom settings. 
 
 We really do our best to help, and it’s not our intention to cause frustration. We’ve pointed out several times that the issue may lie in your specific setup, and we’re more than happy to support where we can. 
 
 One thing you might not here from the support but maybe considering in testing is to deactivate your Plugins one by one and see if the behavior of the images still continues or stops at a certain point. 
 
 Thanks for your understanding!

 01:15 PM | Customer: Finally! Someone has read my message carefully! Thanks!

 01:16 PM | Customer: The point is this: 
 1. Your example works because you have the Testbild-1.webp file. 
 2. However, if you don't have the .webp file and only have Testbild-1.png.webp, it won't work. Notice that there is no .webp extension; only .png.webp. We append the .webp extension, we don't replace it. 
 So please test that.

 01:16 PM | Customer: Again, to repeat, there should exist just 2 files: 
 test.png
 test.png.webp 
 Delete: test.webp

 01:17 PM | Customer: And again, to be clear: 
 1. It should exist at: https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-1.png.
 2. Should not exist: https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-1.webp
 3. Should exist: https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-1.png.webp 
 Does it serve WebP properly from point 3?
 Please test this.

 01:18 PM | Customer: Note: I hope you understand why it is important to use .jpeg.webp rather than .web directly. Otherwise, how will it distinguish between, for example, X.png and X.jpg? They would both serve the same file, X.webp, and I want them to serve X.png.webp and X.jpg.webp.

 01:23 PM | Customer: But finally, someone took the time to understand my question. I'm now clarifying some important details. So let's continue solving this problem. First, let's establish what is not working and why.

 01:25 PM | Customer: In short, for file 1.png, if 1.webp is not present, 1.png.webp is never served, even though your documents state that it should be. There is a comment in the .htaccess file stating "look for file.webp or file.jpg.webp" – the "or file.jpg.webp" part is important.

 01:26 PM | Customer: Comment from .htaccess: 
 ```
 # Autodetect .webp images. If a request is made for a file ending in .jpg/.jpeg/.png/.gif
 # is received, look for a related .webp image and load this instead.'
 # Example: Requesting file.jpg: look for file.webp or file.jpg.webp.
 ```

 01:26 PM | Customer: Could you please send me a copy of the standard .htaccess file with "WebP Support" enabled to confirm that mine has not been modified?

 01:31 PM | Customer: By the way, all this worked properly before.

 01:43 PM | Fernando from raidboxes®: Hi Customer, 
 
 Thanks for the detailed explanation — that helps clarify things a lot. 
 Yes, I completely understand your point about how the .webp files are named and served. The distinction between test.png.webp and test.webp is definitely important, especially to avoid confusion between different original formats like .png and .jpg. 
 
 I’ll also run tests to confirm that the server is correctly serving the test.png.webp version when requested via WebP. 
 
 Could you tell me please with which Plugin or with which method are you adding the webp extension to the files? 
 
 For a original state file of the htaccess, please look into your box in the wordpress folder, there is a backup.htaccess file which is untouched and in its original state

 01:45 PM | Customer: Have you read my message?
 This file should not be there
 https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-1.webp

 01:45 PM | Customer: Remove it!

 01:46 PM | Customer: I need to repeat again... Ugh. Tragic. Can you focus on me, now that you know everything... so, again - for the 5th time: 
 DELETE test.webp
 RENAME IT TO test.png.webp

 01:47 PM | Customer: We only have two files: 
 test.png
 test.png.webp

 01:47 PM | Customer: Third, test.webp, MUST NOT EXIST

 01:47 PM | Fernando from raidboxes®: This file was generated by the Plugin shortpixel from its original file png. I can try to rename it manually. Thats why i ask how you change the file extension, and please dont get salty again, we do what we can

 01:47 PM | Customer: So I can test now?

 01:48 PM | Customer: Yer, of course, rename manualy!

 01:49 PM | Customer: The plugin you are using is not important. This has nothing to do with plugins or WordPress, for that matter. It's a web server issue.

 01:53 PM | Customer: Again, could you please send me a copy of the standard .htaccess file with "WebP Support" enabled to confirm that mine has not been modified? The one you've used on your example? To compare with mine

 01:57 PM | Fernando from raidboxes®: here is the original htaccess file which is used when creating a new box. so its a virgin. i ll go in my break in a few minutes. The rest i ll take care after my break 
 
 [Attachment: ".htaccess"]

 01:58 PM | Fernando from raidboxes®: And here i also placed a png.webp file as you see the testbild-2 
 
 https://justanothertestdomain.de/sample-page/

 02:01 PM | Customer: Simple, please. Again. Please.
 I need Testbild-1.png, and Testbild-1.png.webp, without Testbild-1.webp: 
 If you don't know how to do it, can you just ask for someone else, please. 
 I'm helping your company because you have .htaccess with error you are distibuting to all clients (mine was the same). 
 You could appreciate my patience...

 02:05 PM | Customer: Sorry! Now I realized that is Testbild-2! 
 So finally we have, Testbild-2.png, Testbild-2.png.webp and NO Testbild-2.webp 
 Ah, NO... not again.
 Where is? Testbild-2.png
 OK: Testbild-2.png.webp
 OK: We don't have Testbild-2.webp and that's good finally.

 02:05 PM | Customer: So we are just missing the main file: Testbild-2.png. So we can test...

 02:06 PM | Customer: So we need ONLY: Testbild-2.png and Testbild-2.png.webp
 And NO Testbild-2.webp 
 And we are missing the main file, Testbild-2.png


 02:07 PM | Fernando from raidboxes®: Test now: 
 [Image "image.png?expires=1747661400&signature=890d078fd4fff7e027a66da7f4de0142385f744f3407d8fc0394fe738ff6dc3c&req=dSUkFsx6m4VbUfMW1HO4zXzLdburw%2FEj3kmpU0hSUzl6HmITDyoEi3NYf3lk%0Aqo6E71AfTQzFvvMuBI4%3D%0A"]

 02:08 PM | Customer: Yes! Finally! Here they are! After 2 days. Let's test now :)

 02:08 PM | Customer: You can also test. It is serving PNG and not WebP

 02:08 PM | Customer: OMG. Now can you confirm that it is not working?

 02:09 PM | Customer: To sumarize: 
 It should server WebP, when requesting PNG. But it is not. It is serving PNG.
 And that is - "ta da" - the thing I was explaining for three days.

 02:11 PM | Fernando from raidboxes®: I ll go in my break now. so i am back in about 30 minutes then i ll check. You said it worked once, at the old servers?

 02:11 PM | Customer: Please, just confirm your test results. 
 Because, I think this is 9th time that I'm repeating the same thing over and over.
 I need to be sure we replicated the bug.

 02:12 PM | Customer: Just copy-paste: 
 curl -I -H "Accept: image/webp" https://justanothertestdomain.de/wp-content/uploads/2025/05/Testbild-2.png

 02:12 PM | Customer: Yes, it worked before.

 02:12 PM | Customer: ... I liked that option. And Google liked it a lot. And SERP

 02:13 PM | Customer: Worked before you introduced new infrastructure... when you didn't have apache before nginx.

 02:30 PM | Kimi from raidboxes®: Hey Customer, 
 
 I managed to solve the issue! 
 
 I adjusted your .htaccess file - now it seems to work fine

 02:30 PM | Kimi from raidboxes®: 14:28:36 [email protected]:/data/sites/web/b8mp4xggkmyrdbxio/www$ curl -I -H 
 
 "Accept: image/webp" https://www.mysite.com/wp-content/uploads/2022/12/image-scaled.jpg 
 HTTP/2 200 
 server: nginx 
 date: Mon, 19 May 2025 12:29:49 GMT 
 content-type: image/webp 
 content-length: 188232 
 vary: Accept 
 last-modified: Mon, 27 May 2024 07:20:43 GMT 
 etag: "2df48-6196a5af39023" 
 accept-ranges: bytes 
 age: 0 
 strict-transport-security: max-age=63072000; includeSubDomains; preload 
 x-varnish-cache: BYPASS 
 x-cacheable: NO:STATIC-FILE 
 cache-control: public, max-age=2592000 
 expires: Wed, 18 Jun 2025 12:29:49 GMT 
 x-content-type-options: nosniff 
 x-xss-protection: 1; mode=block

 02:31 PM | Kimi from raidboxes®: This is what i changed in your .htaccess file:

 <IfModule mod_rewrite.c> 
 RewriteEngine On 
 RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] 
 RewriteBase / 
 RewriteCond %{HTTP_ACCEPT} image/webp 
 RewriteCond %{DOCUMENT_ROOT}/$1.$2.webp -f 
 RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L] 
 </IfModule> 
 
 <IfModule mod_headers.c> 
 Header append Vary Accept env=REQUEST_image 
 </IfModule>

 02:32 PM | Customer: I know. I'll send you my final message, and I hope you'll understand...

 02:32 PM | Customer: The point is that it's not just my hosting that's affected; all your customers using this feature are affected too. 
 Prologue: 
 Instead of thanking me, you're calling me 'salty'. I could have fixed these two bugs on my server alone, but I was patient enough to help you identify a bug that was affecting all your customers. 
 Ultimately, I'll fix these two errors on my server myself, and you should do the same for your other customers.

 02:37 PM | Kimi from raidboxes®: Thanks for your feedback but i think you misonderstood something here. 
 
 Our standard .htaccess setup is designed to serve WebP images by replacing the original extension. So a request for image.png will be served as image.webp not image.png.webp. This behavior is intentional and widely adopted because it's clean, efficient, and supported by modern optimization plugins and CDNs. 
 
 Your Setup Uses a Custom File Naming Scheme (.png.webp)
 You're using a variant (.png.webp), which is totally valid but not part of the default setup. That’s why it required manual adjustment. We’re happy to assist with that — and you helped surface it, which is appreciated. 
 
 This Isn’t a Bug, It’s a Customization.
 So to be 100% clear: this isn’t a system-wide bug affecting all our customers. it’s a case of your implementation expecting behavior that differs from the default. If your setup relies on .png.webp, it will naturally require a corresponding rule. You’ve now implemented that, and it works as expected. 
 
 If any of our communication came off as dismissive, that wasn’t the intention. 
 
 We do appreciate your input and the time you invested to trace the issue. You’re right, you could have solved it yourself and moved on, but you chose to loop us in. 
 That helps make our service better, and it’s noted. 
 
 Let me know if you'd like us to implement similar rewrite logic for other sites on your account. Otherwise, we're happy that your setup is working smoothly now.

 02:38 PM | Customer: I've already wrote here - In your .htaccess file it is written:

 02:38 PM | Customer: Example: Requesting file.jpg: look for file.webp or file.jpg.webp

 02:38 PM | Customer: So, I'm not misunderstood anyting

 02:39 PM | Customer: So nothing you wrote in this last messagew is not true. As your .htaccess is telling different. Nothing special in my case.,

 02:40 PM | Customer: That's .htaccess that is common to all customers... You've send it to me today in this chat. 
 And it contains code that is trying to serve .png.web, but it doesn't work. As documented and coded. 
 So it is obvious bug.

 02:41 PM | Customer: But I really don't care.

 02:41 PM | Customer: No excuse? No thank you? C'mon. You honbor.

 02:41 PM | Customer: ... honor.

 02:42 PM | Customer: You have one more bug, unimportant... 
 btw, also the line "AddType image/avif-sequence avi" is nonsense

 02:42 PM | Kimi from raidboxes®: You're absolutely right to point out the comment in the .htaccess, it does say: 
 
 Example: Requesting file.jpg => Look for file.webp or file.jpg.webp 
 However, that line is just a comment, and unfortunately it doesn't reflect what the actual rewrite rules do. The default rules we ship are designed to serve file.webp — not file.jpg.webp. The second format (file.jpg.webp) isn't matched by the standard rules unless you specifically modify them. 
 So, to clarify: 
 - You're not wrong — the comment is misleading. 
 - The actual code does not support .jpg.webp by default. 
 - Your case isn’t special — but it is a variation not covered by the default implementation. 
 We’ve now updated or clarified the rules for your setup, and it’s working. We’ll also flag that misleading comment internally so it can be corrected in future releases. Thanks again for pointing that out — this kind of feedback helps us improve.

 02:42 PM | Customer: The line IS NOT A COMMENT.

 02:42 PM | Customer: 5 lines later YOU ARE TRYING TO IMPLEMENT THAT

 02:44 PM | Customer: You have two blocks RewriteCond

 02:44 PM | Customer: OMG :)

 02:45 PM | Customer: So, comment + implementation.

 02:45 PM | Kimi from raidboxes®: You're correct that the second rewrite block does attempt an additional check beyond the first one. But let's clear up the misunderstanding: 
 The line in the comment: 
 "Look for file.webp or file.jpg.webp" 
 ...suggests two separate patterns: 
 - file.webp ✅ (handled by both rewrite blocks) 
 - file.jpg.webp ❌ (not handled by either rule) 
 Now, regarding the second rewrite block: 
 RewriteCond %{REQUEST_URI} ^/(.+)\.(jpe?g|png|gif)$ [NC] RewriteCond %{DOCUMENT_ROOT}/%1.webp -f RewriteRule (.+)\.(jpe?g|png|gif)$ %1.webp [T=image/webp,E=REQUEST_image,L] 
 
 This part still only looks for file.webp, not file.jpg.webp. The %1 refers to the filename without extension matched by the regex (.+)\.(jpe?g|png|gif), so the server is trying to serve: 
 
 file.webp 
 not: 
 file.jpg.webp 
 
 So yes, you're absolutely right that the second block expands compatibility — but not to file.jpg.webp, only to file.webp. 
 
 In other words, the comment promises support for both, but the actual code only supports one. That’s why we adjusted your rules to also support file.png.webp, which is not covered by our default configuration. 
 
 Thanks again for pointing this out and I appreciate your persistence in getting this clarified properly.

 02:47 PM | Customer: So first part is serving 
 file.webp 
 And second 
 file.webp 
 What's the difference?
 Thet's exactly right there is a bug. You either don't need second block, or ... 
 And IT WORKED in that way before when it was done via nginx. 
 So, 3 proofs.
 But I really don't care if you don't care.

 02:48 PM | Customer: Bravo!

 02:48 PM | Kimi from raidboxes®: On NGINX there is no .htaccess file

 02:48 PM | Customer: Yes, I know

 02:48 PM | Customer: Cmon, like child?

 02:48 PM | Kimi from raidboxes®: ?

 02:48 PM | Customer: Hahaha. Sorry. I have to go

 02:48 PM | Kimi from raidboxes®: Sure, have a nice day!

 02:48 PM | Customer: No time for this. Again - bravo!

 02:48 PM | Customer: It is already on reddit

 02:48 PM | Kimi from raidboxes®: Im happy we could help you solve this issue

 02:49 PM | Customer: You didn't

 02:49 PM | Kimi from raidboxes®: Of course, it works now! Thats great

 02:49 PM | Customer: See how much typing it was...

 02:50 PM | Kimi from raidboxes®: It was a lot, that is for sure, so iam sorry it tooks that long.

 02:50 PM | Customer: 👎

 02:52 PM | Kimi from raidboxes®: and to your message above - again you're right. both rules ultimately serve file.webp. The second block is a legacy fallback and redundant in most cases. You're also correct that under NGINX this may have behaved differently.

 02:52 PM | Kimi from raidboxes®: No problem, If you have further questions, feel free to ask us😊
 Have a nice day!

 03:00 PM | Customer: And more about this "salty" thing you are giving me. Read carefully about "my special case" which is default for WebP Express plugin and EWWW Image Optimizer, and most of the others... 
 "The WordPress WebP Express plugin, when converting an uploaded image like 1.png, creates the WebP version with the original extension preserved in the filename, resulting in a file named 1.png.webp rather than simply 1.webp. There is no built-in option to remove the original extension from the WebP filename to produce just "1.webp" instead of "1.png.webp" without custom modifications..." 
 https://github.com/rosell-dk/webp-express/blob/master/README.md
 Same for EWWW Image Optimizer: https://wordpress.org/support/topic/how-to-change-the-webp-naming-rule/

 03:01 PM | Customer: ... nothing you've said was true :(

 03:11 PM | Kimi from raidboxes®: Thanks for the clarification, you're absolutely right that both WebP Express and EWWW Image Optimizer use the .png.webp naming convention by default. 
 
 That's well documented, and your references are valid. 
 
 However, our WebP delivery rules are not tailored to any one plugin’s default behavior 
 They were designed around a simpler structure (image.webp), which works out of the box for many setups and custom workflows. That doesn't mean your case is "special" in a negative sense. It just means it's different from what our base config supports by default. 
 
 You're also right that this worked differently with NGINX, and we appreciate you pointing out that discrepancy. 
 
 Bottom line: you're making good points, and we've taken them seriously.

 Is there anything else i could help you with?

 03:31 PM | Customer: In your Help article, you recommend this plugin: 
 https://helpcenter.raidboxes.de/en/articles/2661817-webp-at-raidboxes. 
 I'm not using it. It was just a reference to your article. 
 It seems to me that you are suggesting a solution in your Help Centre that doesn't work with your configuration. So please update the article accordingly. 
 Have a nice day.

 03:33 PM | Kimi from raidboxes®: Thank you for the information, I already noted that helpcenter article and we will discuss internally what changes need to made. 
 
 Thank you again.

 ---
 Exported from raidboxes® on May 19, 2025 at 03:31 PM Europe/Berlin time CEST (GMT+0200)