Tests succeed, but PHP errors abound and site images not converting

The second error in test-run.php sounds like the “source” argument in the query string is missing. It is perhaps swallowed by a firewall. This surprises me though, because from in version 0.8.0, the query string is encoded, so it should not look suspecious anymore. It could be that the whole query string is lost for some reason.

Ahh. the line number reveals that you aren’t using WebP Express 0.8.0, but perhaps 0.7.2 ?

Upgrading to 0.8.1 actually might solve that problem. And it might also solve that site images aren’t converting, because that problem may also be a firewall thing, and I implemented a change in 0.8.1, which reduces the risk a little. We however have ideas for how to eliminate the risk of issues with the querystring being blocked by firewalls in #98

The first error in test-run.php sounds like the vendor library is missing. If you have installed from github, you need to run `composer install’ in plugin path, as [described here](https://github.com/rosell-dk/webp-express/blob/master/docs/development.md) (it is on the roadmap to fail more informatively: #113)

The green checkmarks however indicates that conversions have been made successfully. So this means that the vendor library should be in place…
Ahh.. I see. The offending line is this:
$converterClassName = 'WebPConvert\\Converters\\' . ucfirst($converter);

And the error goes: `Class ‘WebPConvert\\Converters\\’ not found’

This indicates that $converter is empty. The converter variable is set like this: $converter = $_GET['converter'];. So even that query string is swallowed, even though it is quite innocent – the converter argument is a simple string like “ewww” or “gd”

Oh, for 0.8.0, the slightly less prone to firewall blocking rule needs a couple of x’s (“xsource” rather than “source”, and and x before $document_root)

`
if ($http_accept ~* “webp”){
rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$document_root$request_uri&wp-content=wp-content&%1 break;
}
`

But actually, as there seems to be problems with passing querystrings on your setup, lets try out the idea in #98 (https://github.com/rosell-dk/webp-express/issues/98).

I will provide some code changes for you to try.

Try replacing wp-content/plugins/webp-express/wod/webp-on-demand.php, with this update:

https://github.com/rosell-dk/webp-express/blob/master/wod/webp-on-demand.php

If no ‘source’ parameter is passed to it, it will now fall back to REQUEST_URI.

So please also update the NGINX rule, to neither pass source nor xsource:

if ($http_accept ~* “webp”){
rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?wp-content=wp-content&%1 break;
}

I just asked WPEngine for a free account for testing the plugin. They don’t do that, but they have a 60 day money back guarantee, so I will create an account and try to fix this.

I have other work to do (paid work), which I probably should get started doing… I will get back to this, when I get the time.

I have other work to do (paid work)

Aside: Have you considered a “donate” link for this plugin? I really think you’ve got a potential winner here.

Yes, I not only considered, but already have added a donation link ??

I received a single donation for five cups of coffee, which is nice, and made be really happy. But it doesn’t seem likely that donations are going to pay other bills than my coffee bills. Well well. I don’t think I ever pressed any donation button myself either…

As to this issue, I have purchased a WPEngine account.
1. The Gd converter is working out of the box.
2. I do not have any problems when clicking the “test” buttons. Perhaps that issue has disappeared in 0.8.0 – where the path is encoded in the query string
3. I asked the support to add the rewrite rule (the one with “source” parameter). It however did not work – images where not redirected to the PHP script

I will now start testing on a local Nginx

Ok, good news!

I found two bugs in the rules.

Firstly, the quotes were that slightly slanted variation, which sometimes creeps in and stops things from working. It was: ” It should have been: ”

Secondly, we should use $uri rather than $request_uri, because $request_uri includes the query string (docs:
https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri)

The following rules works for me:

if ($http_accept ~* "webp"){
  rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$document_root$uri&wp-content=wp-content&%1 break;
}

– where wp-content argument is set to the relative path from root to my wp-content dir.

In the next release (0.9.0), it will probably not be necessary to pass xsource argument at all

• This reply was modified 6 years, 3 months ago by rosell.dk.

Instead of $document_root$uri, it seems, we can use: $request_filename

I’m changing the docs to this:

if ($http_accept ~* "webp"){
  rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content&%1 break;
}

One more thing:

%1 doesn’t seem to do anything in Nginx. In the Apache rules, it was there to pass the original query string on. But it seems the querystring is available in PHP in $_GET without any trickery. Sorry that I have blindly posted Nginx rules which somebody else wrote.

We are now down to:

if ($http_accept ~* "webp"){
  rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content break;
}

I asked WPEngine to insert the rule above, and it works: https://rosellit.wpengine.com/?page_id=2

@adamwking: Does the new rules work for you?

Thank you for all the hard work.

Still no go for me in my bedrock installation. Nginx v1.1

Tried this:

if ($http_accept ~* “webp”){
rewrite ^/(.*).(jpe?g|png)$ /app/plugins/webp-express/wod/webp-on-demand.php?source=$request_filename&wp-content=app break;
}

• This reply was modified 6 years, 3 months ago by pixelcrook.

@pixelcrook, in the notification email, the ampersand in the rule was html-encoded. I can see you have modified your post, so perhaps it was just in this post?

Anyway, let this be a warning. When you copy the rule from the FAQ, there is a risk that you get “…$request_filename&wp-content…” instead of “…$request_filename&wp-content…”.

@roselldk, no, I rote the whole thing based on your post, just because i know that chars would change copy/pasting between programs. The modification was just because i forgot to check i wanted email confirmations. ??

Will continue to work with this on my end, and will tell you if I make any progress.

Thank you!