Broken Links Images

I am having this issue as well. Dozens of images are not showing. Refreshing the media library page will show that a different set show/don’t show up (in other words, it isn’t always the same images which fail to load).

[Wed Nov 11 09:34:00.233275 2020] [:error] [pid 441418:tid 139927668381440] [client 216.228.176.197:0] SoftException in Application.cpp:630: Could not execute script “/home4/jytchlmy/public_html/wolfhoundpack/wp-content/plugins/webp-express/wod/webp-on-demand.php”, referer: https://wolfhoundpack.org/wp-admin/upload.php

This is a serious issue. Please advise.

I reactivated the plugin and did as you asked… the report is copied below. I also returned to the media library and did a hard refresh. All the images loaded this time. Any idea why it cleared up?

Thanks!

———

Skip to main contentSkip to toolbar
About WordPress
The Wolfhound Pack
00 Comments in moderation
New
Caching
Gallery
Autoptimize
UpdraftPlus
Howdy, Lisa Hakesley
Log Out
WebP Express Settings

Operation mode: ?
Varied image responses
In the “Varied image responses” mode, WebP Express creates redirection rules for images, such that a request for a jpeg will result in a webp – but only if the request comes from a webp-enabled browser. Note that not all CDN’s handles varied responses well (see FAQ).
System info
General
Scope?
Uploads and themes
Image types to work on?
Both jpegs and pngs
Destination folder?
In separate folder
File extension?
Append “.webp”
Destination structure?
Document root
Cache-Control header ?
Do not set

.htaccess rules for webp generation
Usually, in this operation mode, you would enable the two first options, which effectively enables the varied image responses (such that a request for a jpeg/png will result in a webp on browsers that supports webp). The first option makes this happen for images that are already converted. The second option makes it happen even for images that has not yet been converted, by redirecting the request to the converter, which converts, saves and delivers.

The third option is only relevant if you are using Alter HTML as well as serving varied image responses.

Enable direct redirection to existing converted images?? Live test
Enable redirection to converter? ? Live test
Create webp files upon request? ? Live test
Conversion
Jpeg options ?
WebP encoding:
Auto
?
Quality for lossy:
Same as the jpeg
? Limit:
80
? Fallback:
70
?
Quality for lossless:
Apply preprocessing
? “Near lossless” quality:
60
?
PNG options ?
WebP encoding:
Auto
?
Quality for lossy:
85
? Alpha quality:
85
?
Quality for lossless:
Apply preprocessing
? “Near lossless” quality:
60
?
Metadata?
No metadata in webp
Conversion method ?
cwebpconfiguretestdeactivate
Vipsconfiguretestdeactivate
ImageMagickconfiguretestdeactivate
GraphicsMagickconfiguretestdeactivate
Remote WebP Expressconfiguretestdeactivate
ewww cloud converterconfiguretestdeactivate
Imagick (PHP extension)configuretestdeactivate
Gmagick (PHP extension)testdeactivate
Gd extensionconfiguretestdeactivate
Convert on upload ?
Bulk convert ?
Bulk Convert Delete converted files
Alter HTML
Enabling this alters the HTML code such that webp images are served to browsers that supports webp. It is recommended to enable this even when the redirection is also enabled, so the varied image responses are only used for those images that cannot be replaced in HTML. The varied responses generally leads to poorer caching in proxies and CDN’s. And if users download those images, they will have jpg/png extension, even though they are webp.

Alter HTML??
Two distinct methods for altering HTML are supported. View comparison chart

What to replace:
Replace tags with <picture> tags, adding the webp to srcset.?
Dynamically load picturefill.js on older browsers?
Replace image URLs?
Only do the replacements in webp enabled browsers?
Reference webps that haven’t been converted yet?
How to replace: ?
Use content filtering hooks (the_content, the_excerpt, etc)
The complete page (using output buffering)
CDN hostname(s) / hostname alias(es) ?
http(s)://

Web service
Enable web service??
No sites have been authorized to use the web service yet.

+ Authorize website

Thank you for creating with WordPress.Version 5.5.3
Testing redirection to existing webp
Close
Testing redirection to existing webp
UPLOADS
Copying files for testing
Copying JPEG to uploads folder (webp-express-test-images/pK1z7Y.JPEG). ok
We now have a jpeg stored here:
/home4/jytchlmy/public_html/wolfhoundpack/wp-content/uploads/webp-express-test-images/pK1z7Y.JPEG

Copying dummy webp to the cache root for uploads. ok
We now have a webp file stored here:
/home4/jytchlmy/public_html/wolfhoundpack/wp-content/webp-express/webp-images/doc-root/wp-content/uploads/webp-express-test-images/pK1z7Y.JPEG.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://wolfhoundpack.org/wp-content/uploads/webp-express-test-images/pK1z7Y.JPEG
Response: 200 OK
Response headers:
– date: Thu, 12 Nov 2020 17:02:21 GMT
– server: nginx/1.19.0
– content-type: image/webp
– content-length: 7022
– vary: Accept,Accept-Encoding,User-Agent
– last-modified: Thu, 12 Nov 2020 17:02:21 GMT
– accept-ranges: bytes
– cache-control: max-age=31536000
– expires: Fri, 12 Nov 2021 17:02:21 GMT
– content-encoding: gzip
– host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
– x-endurance-cache-level: 2
– x-webp-express: Redirected directly to existing webp
– x-server-cache: true
– x-proxy-cache: MISS

Alrighty. We got a webp. Just what we wanted. Great!

Now lets check that browsers not supporting webp gets the JPEG
Making a HTTP request for the test image (without setting the “Accept” header)
Request URL: https://wolfhoundpack.org/wp-content/uploads/webp-express-test-images/pK1z7Y.JPEG
Response: 200 OK
Response headers:
– date: Thu, 12 Nov 2020 17:02:21 GMT
– server: nginx/1.19.0
– content-type: image/jpeg
– content-length: 3195
– last-modified: Thu, 12 Nov 2020 17:02:21 GMT
– accept-ranges: bytes
– cache-control: max-age=86400
– expires: Fri, 13 Nov 2020 17:02:21 GMT
– host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
– x-endurance-cache-level: 2
– vary: Accept
– x-server-cache: true
– x-proxy-cache: MISS

Alrighty. We got the jpeg. Great!.
Performing same tests for PNG
All tests passed for PNG as well.
(I shall spare you for the report, which is almost identical to the one above)
Results for UPLOADS
Everything seems to work as it should. However, a couple of things were not tested (it is on the TODO). TODO 1: If one image type is disabled, check that it does not redirect to webp (unless redirection to converter is set up). TODO 2: Test that redirection to webp only is triggered when the webp exists.
Deleting test images
THEMES
Copying files for testing
Copying JPEG to themes folder (webp-express-test-images/5LnUYI.JPEG). ok
We now have a jpeg stored here:
/home4/jytchlmy/public_html/wolfhoundpack/wp-content/themes/webp-express-test-images/5LnUYI.JPEG

Copying dummy webp to the cache root for themes. ok
We now have a webp file stored here:
/home4/jytchlmy/public_html/wolfhoundpack/wp-content/webp-express/webp-images/doc-root/wp-content/themes/webp-express-test-images/5LnUYI.JPEG.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://wolfhoundpack.org/wp-content/themes/webp-express-test-images/5LnUYI.JPEG
Response: 200 OK
Response headers:
– date: Thu, 12 Nov 2020 17:02:21 GMT
– server: nginx/1.19.0
– content-type: image/webp
– content-length: 7022
– vary: Accept,Accept-Encoding,User-Agent
– last-modified: Thu, 12 Nov 2020 17:02:21 GMT
– accept-ranges: bytes
– cache-control: max-age=31536000
– expires: Fri, 12 Nov 2021 17:02:21 GMT
– content-encoding: gzip
– host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
– x-endurance-cache-level: 2
– x-webp-express: Redirected directly to existing webp
– x-server-cache: true
– x-proxy-cache: MISS

Alrighty. We got a webp. Just what we wanted. Great!

Now lets check that browsers not supporting webp gets the JPEG
Making a HTTP request for the test image (without setting the “Accept” header)
Request URL: https://wolfhoundpack.org/wp-content/themes/webp-express-test-images/5LnUYI.JPEG
Response: 200 OK
Response headers:
– date: Thu, 12 Nov 2020 17:02:21 GMT
– server: nginx/1.19.0
– content-type: image/jpeg
– content-length: 3195
– last-modified: Thu, 12 Nov 2020 17:02:21 GMT
– accept-ranges: bytes
– cache-control: max-age=86400
– expires: Fri, 13 Nov 2020 17:02:21 GMT
– host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
– x-endurance-cache-level: 2
– vary: Accept
– x-server-cache: true
– x-proxy-cache: MISS

Alrighty. We got the jpeg. Great!.
Performing same tests for PNG
All tests passed for PNG as well.
(I shall spare you for the report, which is almost identical to the one above)
Results for THEMES
Everything seems to work as it should. However, a couple of things were not tested (it is on the TODO). TODO 1: If one image type is disabled, check that it does not redirect to webp (unless redirection to converter is set up). TODO 2: Test that redirection to webp only is triggered when the webp exists.
Deleting test images