After spending another 2 hours trying to find the problem I stumbled across the “System” button inside the WebP Express plugin. Here’s the output from myc configuration:
System info:
- PHP version: 7.4.0
- OS: WINNT
- Server software: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.0
- Document Root status: Available and its "realpath" is available too. Can be used for structuring cache dir.
- Document Root: C:/WAMP64/www/
- Document Root (symlinked resolved): C:\WAMP64\www
- Document Root: Available and its "realpath" is available too. Can be used for structuring cache dir.
- Apache module "mod_rewrite" enabled?: yes
- Apache module "mod_headers" enabled?: yes
Wordpress info:
- Version: 5.5.3
- Multisite?: no
- Is wp-content moved?: no
- Is uploads moved out of wp-content?: no
- Is plugins moved out of wp-content?: no
Image roots (absolute paths)
uploads: C:\WAMP64\www\IST01/wp-content/uploads (resolved for symlinks: C:\WAMP64\www\IST01\wp-content\uploads)
themes: C:\WAMP64\www\IST01/wp-content/themes (resolved for symlinks: C:\WAMP64\www\IST01\wp-content\themes)
plugins: C:\WAMP64\www\IST01/wp-content/plugins (resolved for symlinks: C:\WAMP64\www\IST01\wp-content\plugins)
wp-content: C:\WAMP64\www\IST01/wp-content (resolved for symlinks: C:\WAMP64\www\IST01\wp-content)
index: C:\WAMP64\www\IST01
Image roots (relative to document root)
uploads: IST01/wp-content/uploads
themes: IST01/wp-content/themes
plugins: IST01/wp-content/plugins
wp-content: IST01/wp-content
index: IST01
Image roots (URLs)
uploads: https://localhost/IST01/wp-content/uploads
themes: https://localhost/IST01/wp-content/themes
plugins: https://localhost/IST01/wp-content/plugins
wp-content: https://localhost/IST01/wp-content
index: https://localhost
WebP Express configuration info:
- Destination folder: mingled
- Destination extension: set
- Destination structure: image-roots
(To view all configuration, take a look at the config file, which is stored in C:\WAMP64\www\IST01/wp-content/webp-express/config/config.json)
Live tests of .htaccess capabilities / system configuration:
Unless noted otherwise, the tests are run in wp-content/webp-express/htaccess-capability-tester.
WebPExpress currently treats the results as they neccessarily applies to all scopes (upload, themes, etc),
but note that a server might be configured to have mod_rewrite disallowed in some folders and allowed in others.
- .htaccess files enabled?: no
- mod_rewrite working?: no
- mod_headers loaded?: no
- mod_headers working (header set): no
- passing variables from .htaccess to PHP script through environment variable working?: no
- Can run php test file in plugins/webp-express/wod/ ?: no
- Can run php test file in plugins/webp-express/wod2/ ?: no
- Directives for granting access like its done in wod/.htaccess allowed?: yes
.htaccess files that WebP Express have placed rules in the following files:
- C:\WAMP64\www\IST01/wp-content/uploads/.htaccess
WebP rules in uploads:
File: C:\WAMP64\www\IST01/wp-content/uploads/.htaccess
# Rules for handling requests for source images
# ---------------------------------------------
<IfModule mod_rewrite.c>
RewriteEngine On
# Redirect to existing converted image in same dir (if browser supports webp)
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (?i)(.*)(\.jpe?g|\.png)$
RewriteCond %1\.webp -f
RewriteRule (?i)(.*)(\.jpe?g|\.png)$ %1\.webp [T=image/webp,E=EXISTING:1,L]
# Make sure that browsers which does not support webp also gets the Vary:Accept header
# when requesting images that would be redirected to webp on browsers that does.
<IfModule mod_headers.c>
<FilesMatch "(?i)\.(jpe?g|png)$">
Header append "Vary" "Accept"
</FilesMatch>
</IfModule>
</IfModule>
# Rules for handling requests for webp images
# ---------------------------------------------
# Set Cache-Control header for requests to webp images
<IfModule mod_headers.c>
<FilesMatch "(?i)\.webp$">
Header set Cache-Control "public, max-age=31536000, stale-while-revalidate=604800, stale-if-error=604800"
</FilesMatch>
</IfModule>
# Fall back to mod_expires if mod_headers is unavailable
<IfModule !mod_headers.c>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 31536000 seconds"
</IfModule>
</IfModule>
# Set Vary:Accept header if we came here by way of our redirect, which set the ADDVARY environment variable
# The purpose is to make proxies and CDNs aware that the response varies with the Accept header
<IfModule mod_headers.c>
<IfModule mod_setenvif.c>
# Apache appends "REDIRECT_" in front of the environment variables defined in mod_rewrite, but LiteSpeed does not
# So, the next lines are for Apache, in order to set environment variables without "REDIRECT_"
SetEnvIf REDIRECT_EXISTING 1 EXISTING=1
SetEnvIf REDIRECT_ADDVARY 1 ADDVARY=1
Header append "Vary" "Accept" env=ADDVARY
# Set X-WebP-Express header for diagnose purposes
Header set "X-WebP-Express" "Redirected directly to existing webp" env=EXISTING
</IfModule>
</IfModule>
# Register webp mime type
<IfModule mod_mime.c>
AddType image/webp .webp
</IfModule>
The “Live tests of .htaccess capabilities / system configuration:” section of this output indicate that the .htaccess file is not working in the /uploads folder. What do I need to ]o to fix this problem?
Hm. When the self test tries to request an image in the uploads folder, the request itself fails, which is indicated by message “The remote request errored”. One reason for the request to fail could be if the .htaccess in the folder contains directives that are disallowed in the current configuration (another is if it contains syntax errors).
You could try to remove the content of the .htaccess in the uploads folder and see if that gets rid of the “The remote request errored” message. If it does, then the hypothesis that it has to do with the content of the .htaccess file will be confirmed. Next thing would be to put back the content and remove parts of it gradually, until it is discovered which part it is that upsets the server.
You could also try to look in the log files.
I suspect the issue you are facing has something to do with the platform (WampServer). I unfortunately currently don’t have access to a WampServer. I would very much like to add WampServer to my test setup, but I’m currently very low on finances.
The only statements that are present in the .htaccess file that is created by WebP Express in the uploads folder are those that are generated by WebP Express. I have SSL/TLS redirection active in the .htaccess file that is located in the WordPress document root folder. I did not add this SSL/TLS redirection to the .htaccess file that was generated by WebP Express in the uploads folder. Could this be the problem?
I tried your suggestion about removing all statements from the .htaccess file located in the uploads folder. Nothing changed.
I’m not an expert with Apache configuration. So, if the Apache httpd.conf file contains directives that would prevent the statements in the .htaccess file located in the uploads folder from executing, I need some instruction on where to look in the Apache httpd.conf file to fix the issue.
I suspect the issue I’m having is an Apache configuration issue because I always get the following message displayed on the WebP Express settings page:
It seems your server setup does not support headers in .htaccess. You should either fix this (install mod_headers) or deactivate the "Enable direct redirection to existing converted images?" option.
I don’t understand what “… your server settings do not support headers in .htaccess.” means. I’ve checked phpinfo() and confirmed that Apache’s mod_headers is installed.
Thanks For Your Help!
One additional piece of information I forgot to place in my last post – redirection to existing .webp files is working, even though the redirection test itself fails. I have confirmed this using Chrome’s Developer Tools per your documentation. Both .png and .jpg files are being redirected to their respective .webp files.
I’ve continued to try to troubleshoot the issues I’m having with WebP Express. Here’s what’s transpired:
1. I put garbage in the .htaccess file located in the uploads folder. The website didn’t render any images
2. I put the .htaccess file that was generated by WebP Express back into the uploads folder and the site images rendered correctly. I used Chrome’s Developer Tools to see if .webp images were served, and they were. So, I know that the code in the .htaccess file that was generated by WebP Express does successfully redirect .jpg and .png images to their .webp equivalents.
3. When I run the redirection Live Test it fails.
4. When I run the test for the imagick converter it fails with a message about invalid path
It appears that image redirection is working properly but the tests are failing. I have WordPress installed in a subdirectory beneath the www folder in WampServer (the equivalent of public_html on a public server). So, my WampServer development environment is setup so that each of my clients’ website in located in a separate follder located beneath the www folder.
Hope This Helps,
Ok, thanks for your extensive testing.
Yes, it must be the Live Test that fails. The live test relies on a WordPress function to make a HTTP request (wp_remote_get). It would seem that it is the capability to make a HTTP request that are failing. This could also be the reason that WebP Express fails detecting that headers are working. That message is based on a live test, which is based on a HTTP request.
Perhaps the failure has something to do with you being on localhost?
From this thread, it seems there can be problems in that regard:
https://wordpress.stackexchange.com/questions/35826/using-wp-remote-get-to-retrieve-own-url-on-local-host
To get more info about the reason why wp_remote_get fails, you can edit the file plugins/webp-express/lib/classes/SelfTestHelper.php.
Line 204-207 is currently:
if (is_wp_error($wpResult)) {
$log[] = 'The remote request errored';
return [false, $log, $results];
}
Replace these lines with these lines:
if (is_wp_error($wpResult)) {
$log[] = 'The remote request errored';
$log[] = $wpResult->get_error_message();
//$log[] = print_r($wpResult, true);
return [false, $log, $results];
}
PS: I just confirmed that the .htaccess capability checks (such as the test that determines if mod_headers are working) actually reports “no” if the request errors. This is an error, as they should report “could not be determined”
I have fixed that the capability tests so there should be no more false warnings about headers. In the Live Tests, I added information about the error in case the request fails, as it does for you. I’m planning to release these fixes in a new release tomorrow.
Excellent! Thanks, Bjorn, for responding so fast to these issues. I look forward to the changes.
I’m aware that your issue has not been solved yet. But now there should no longer be a warning about headers AND the log should be more informative about the HTTP request error.
So. What does the Live Test button print now?
The test failed with a cURL error that the SSL certificate couldn’t be obtained. Here’s the exact message:
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://localhost/IST01/wp-content/uploads/webp-express-test-images/gE36d5.JPEG
The remote request errored
cURL error 60: SSL certificate problem: unable to get local issuer certificate
The test cannot be completed, as the HTTP request FAILED. This does not neccesarily mean that the redirections aren't working, but it means you will have to check it manually. Check out the FAQ on how to do this. You might also want to check out why a simple HTTP request could not be issued. WebP Express uses such requests for detecting system capabilities, which are used when generating .htaccess files. These tests are not essential, but it would be best to have them working. I can inform that the WordPress function wp_remote_get was used for the HTTP request and the URL was: https://localhost/IST01/wp-content/uploads/webp-express-test-images/gE36d5.JPEG
Deleting test images
I’m using a self-signed SSL certificate on my website and haven’t had any problems in the localhost environment.
Bjorn, it looks like the fix for the cURL error is using a particular CA certificate that prevents this error from occurring when the HTTPS request is made. Here’s the Stack Overflow post that discusses this.
I downloaded the curl cacert.pem file and added the directives curl.cainfo = "C:\WAMP64\curl_certs\cacert.pem" and openssl.cafile = "C:\WAMP64\curl_certs\cacert.pem" to both the Apache php.ini and the PHP php.ini files as instructed in the first solution in this post. I restarted WampServer (which restarts Apache and PHP) and the Live Test still failed.
Any ideas?
Sorry, the problem seems outside the scope of WebP Express and I have no experience with Wamp.
As you have tested that it works manually, you are ok. The .htaccess tests fails, but it is of no great importance.
