Closed rosell-dk closed 5 years ago
I am on Bluehost/shared. Doesn't work there as well. Currently using remote service from another server.
SiteGround gave me an account for testing WebP Express. And well, it actually works. It is possible to convert images to webp by executing the imagemagick binary. So the "ImageMagick" conversion method works. They are btw. telling me that they will also be supporting cwebp soon.
But rewrite rules aren't working on SiteGround. They have a nginx/apache setup. nginx is on top of Apache as reverse proxy and serves static files using try_files. They do not support custom nginx rules. So on SiteGround, one will simply have to use Alter HTML instead of redirection.
@vijayaraghavanramanan: You could consider sending them this letter. Btw: As SiteGround provided me with a free account for testing WebP Express, I figured that Bluehost might also want to do that. But unfortunately, no.
Closing as it does work on Siteground.
Hello @rosell-dk
I recently migrated to siteground. Earlier on GoDaddy, everything was working fine. On Siteground, I have tried all combinations of the following:
After each setting change, I saved with force new .htaccess rules and then tried the three live tests. Only the third one (Create webp files upon request?) passes
Following are the responses for the other two:
1) Testing redirection to existing webp
`Lets check that browsers supporting webp gets the WEBP when the JPEG is requested Making a HTTP request for the test image (pretending to be a client that supports webp, by setting the "Accept" header to "image/webp") Request URL: https://nerdyelectronics.com/wp-content/uploads/webp-express-test-images/kQD02q.JPEG Response: 200 OK Response headers:
- server: nginx
- date: Thu, 12 Dec 2019 05:56:38 GMT
- content-type: image/jpeg
- content-length: 3195
- last-modified: Thu, 12 Dec 2019 05:56:38 GMT
- etag: "5df1d696-c7b"
- expires: Fri, 11 Dec 2020 05:56:38 GMT
- cache-control: max-age=31536000
- host-header: 8441280b0c35cbc1147f8ba998a563a7
- x-proxy-cache-info: DT:1
- accept-ranges: bytes
Bummer. As the "content-type" header reveals, we got the jpeg. Additionally, the content-length reveals that we did not get the webp (we know that the file we put is exactly 6964 bytes). So we can conclude that the rewrite did not happen The test FAILED. Diagnosing rewrites Running a special designed capability test to test if rewriting works with .htaccess files Result: Yes, rewriting works. It seems something is wrong with the .htaccess rules then. You could try to change "Destination structure" - the rules there are quite different. It could also be that the server has cached the configuration a while. Some servers does that. In that case, simply give it a few minutes and try again. Note that if you cannot get redirection to work, you can switch to "CDN friendly" mode and rely on the "Alter HTML" functionality to point to the webp images. If you do a bulk conversion and make sure that "Convert upon upload" is activated, you should be all set. Alter HTML even handles inline css (unless you select "picture tag" syntax). It does however not handle images in external css or which is added dynamically with javascript.`
2) Testing redirection to converter
`Lets check that browsers supporting webp gets a freshly converted WEBP when the jpeg is requested Making a HTTP request for the test image (pretending to be a client that supports webp, by setting the "Accept" header to "image/webp") Request URL: https://nerdyelectronics.com/wp-content/uploads/webp-express-test-images/hrCuuz.JPEG Response: 200 OK Response headers:
- server: nginx
- date: Thu, 12 Dec 2019 05:55:17 GMT
- content-type: image/jpeg
- content-length: 3195
- last-modified: Thu, 12 Dec 2019 05:55:17 GMT
- etag: "5df1d645-c7b"
- expires: Fri, 11 Dec 2020 05:55:17 GMT
- cache-control: max-age=31536000
- host-header: 8441280b0c35cbc1147f8ba998a563a7
- x-proxy-cache-info: DT:1
- accept-ranges: bytes
Bummer. As the "content-type" header reveals, we got the jpeg. The test FAILED. Now, what went wrong? Well, there is indication that the redirection isnt working. The PHP script should set "x-webp-convert-log" response headers, but there are none. Diagnosing redirection problems Running a special designed capability test to test if rewriting works with .htaccess files Result: Yes, rewriting works. It seems something is wrong with the .htaccess rules then. You could try to change "Destination structure" - the rules there are quite different. It could also be that the server has cached the configuration a while. Some servers does that. In that case, simply give it a few minutes and try again. Note that if you cannot get redirection to work, you can switch to "CDN friendly" mode and rely on the "Alter HTML" functionality to point to the webp images. If you do a bulk conversion and make sure that "Convert upon upload" is activated, you should be all set. Alter HTML even handles inline css (unless you select "picture tag" syntax). It does however not handle images in external css or which is added dynamically with javascript.`
Hi @rosell-dk, in your last comment you stated that is working on SiteGround but I am in the same situation as @bhageria. Do I have to subscribe to EWWW to make the conversion work?
There are other ways that I could use WebP in my installation? For example can I upload a WebP image with the same name of the jpg/png and let WebP Express do its magic?
Good Day @rosell-dk,
I am also having the same issue as above. The WebP conversion is working on Siteground, however the redirect does not work.
However, alter HTML is working great! :) Nevertheless, it would be awesome if the redirect would work as well to cover CSS Files and JS included images.
Thanks for developing this super useful tool!
The WebP conversion is working on Siteground
Hi @zacci, can you explain how did you make it work on SiteGround? Did you ask to the support team?
Because I am also on SiteGround but all the conversion options fails:
Can you be so kind to explain which are your conversion settings and on which plan of SiteGround hosting are you on?
I am on a GrowBig plan and I am using PHP 7.4.2
For anyone still stuck on this issue, unfortunately you have to turn Nginx Direct Delivery off in order to make rewrite rules work on SiteGround: https://ronaldaug.medium.com/why-your-htaccess-rule-doesnt-work-on-siteground-hosting-d2a4fbb55ecb
So you fix "Serve images in next-gen formats" but now you get "Serve static assets with an efficient cache policy"... 🙄
Check it out! https://wordpress.org/support/topic/doesnt-seem-to-work-on-siteground/