Takis Bouyouris

Hello again, @defxs,

Thank you for the update!

Now, I see that the cookie the plugin is expected to set is indeed set, but hitting a debug url like https://mantelzorggoedgeregeld.nl/wp-content/uploads/2021/09/4.jpg?debug=true just shows the image and not the expected debug info.

I see that you are using NginX as your web server. This probably means that Nginx is not configured as necessary. In Apache the necessary configuration can be done automatically, but in Nginx one needs to edit the conf file manually. What you need to add there is mentioned in the success message presented to you when you save the plugin settings.

Is this something you could manage? If not, perhaps you need to contact your server admin for help!

Cheers,
Takis

Hello, my friend,

Thank you for your message!

Unfortunately, our plugin does not support this feature. We try to keep its features at a minimum, so that it is as lightweight as possible.

Cheers,
Takis

Hello, @nmcgovern,

Sorry for my late reply, but I did not get the notification, Also, thank you very much for your feedback, it is much appreciated!

The initial idea was that the L flag would terminate the current set of rewrite rules, but would also allow for possible further processing, for interoperability reasons, in case some other piece code needed to do something. Doing so, of course, could be quite complex, but… that was the idea.

Could you possibly name some of the security tools you mentioned, so that I might take a look at them?

Now, indeed this is all hardcoded in the plugin as, we never expected it would be an issue. And I cannot make any promises that making it an option is on our roadmap yet. But it is noted! 🙂

Cheers,
Takis

Hello, @jladkins0824,

I think this has to do with your theme, its layout and its CSS. Even if you had the the Adaptive Images plugin enabled, it would not be able to help in this issue. I am not sure how I could help any further…

Cheers,
Takis

Hello, @jc123, thank you for your message!

The bit of code you see in your htaccess file is added automatically by the Adaptive Images plugin. It is required so that the plugin can function when the web server is Apache (or compatible servers, like Litespeed). So, if this bit of code is already there, you do not need to add anything more to it.

The discussion in this thread was mostly about NginX and how it should be configured. Actually, you may want to read my message some days ago here where I explain it more thoroughly.

As far as how to test, you can look at the “How to test” section in the main plugin description page. Inspect element should show the correct image if all things are set up properly and all caches have been cleaned. But you need to look at the dimensions of the downloaded image, not its url (the url will remain the same).

Cheers,
Takis

Hello, @remmar00,

The code necessary for NginX appears in the plugin settings page after you save them in the success message. You do need to tweak it a little bit according to your specific installation, though.

The code for the htaccess file is in the same place!

However, you shouldn’t need to set up Apache and NginX at the same time. Your main web server is one and that is what you need to set up.

So the first thing you need to do is clarify with Siteground which one is your main web server. NginX or Apache?

There is a case where they might be using NginX on top of Apache, as a caching server. This is an entirely different case altogether in which NginX acts like a small CDN. This case is only experimentally supported by our plugin, if you enable the CDN support option in the plugin settings page. And you need to make sure with Siteground that NginX allows cache busting on image urls via GET parameters. (Experimental does not mean that something will break, but the plugin might miss some images and not downsize them.)

Let me know if I can help any further.

Cheers,
Takis

Hello, @roadlink, thank you for your email!

I am quite sure the issue is not the lazy loading of the images, because the plugin works on the server right at the point where the image requests are handled.

I think the issue is the combination with Cloudflare. If you are indeed using it, then I am afraid that our plugin cannot work with it. We have tried to explain this a bit in the description of our plugin, but it is a little tricky. CDNs like Cloudflare completely intercept image requests, so our plugin does not get the chance to handle them. Sorry if this is not very clear.

This is the reason why we have marked CDN support as “experimental” in the plugin settings page. You can enable this setting, but only with CDNs who keep url parameters on image requests. If you can configure Cloudflare to do this then it should work and then you can check it out.

Let me know if I can help any further.

Cheers,
Takis

Hello, @mike-a,

Thank you for your message and for sharing all this info with us!

I see from your page that the content is delivered via Nginx, although your debug info mentions Apache. This probably means that in your setup Apache is the main application server, but Nginx is used as a proxy/caching server in front of it. Is that correct?

So you have three options:

• Remove Nginx and use only Apache, if this is supported by your hosting environment.
• Remove Apache and use only Nginx, if this is supported by your hosting environment. In this case some additional setup is required manually in the Nginx conf file (we mention it in the message that appears in the /wp-admin after you save the plugin settings.
• Use Nginx as a CDN. In order to do this you need to enable the CDN support parameter in the plugin settings page. However, this is an experimental feature.

Let me know if I can help any further!

Cheers,
Takis