Imagify not working, $_POST requests blocked

I’m trying to use Imagify on my local development site, as I need to make sure all images are optimized before I deploy this new website to the server, and also I want to try things like webp images and picture tags etc. in my dev environment for proper testing.
I’m using the Imagify Wordpress plugin but I can’t optimize any images. When I optimize an image it says “optimizing…” and the icon starts spinning but it keeps spinning forever and never stops or does anything.
I installed the “Imagify Tools” helper plugin to determine the issue. This performs a list of tests and indicates which fail.
The ones that are failing are:

$_POST requests to https://mysite.local/wp-admin/admin-ajax.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 443: Connection refused

$_POST requests to http://mysite.local/wp-admin/admin-ajax.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 80: Connection refused

$_POST requests to https://mysite.local/wp-admin/admin-post.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 443: Connection refused

$_POST requests to http://mysite.local/wp-admin/admin-post.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 80: Connection refused

$_POST requests to https://mysite.local/wp-cron.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 443: Connection refused

$_POST requests to http://mysite.local/wp-cron.php blocked	Yes	Request returned an error:
cURL error 7: Failed to connect to mysite.local port 80: Connection refused

Imagify support has advised me that it should be something in the local server config which results in the requests getting blocked.

I tried a solution like this enable cross-origin resource sharing (relaxing the access controls) and changed the Nginx configuration accordingly, and reloaded Nginx from inside the container via CLI, but it doesn’t help.

Any suggestions on how to resolve this issue?

Hi @GoldyOnline, thanks for reaching out!
Do you know how Imagify works/optimizes your images? Is the plugin performing the optimizations locally or are files being transferred to/from Imagify servers?

I ask because it sounds like Imagify is trying to POST to https://mysite.local which won’t be possible since that domain only exists within your computer/local network.

If that is what’s happening, then you’ll only be able to use Imagify when your site exists on Kinsta’s Staging/Live.

There are also other plugins that handle the WebP conversions locally like WebP Converter for Media – Convert WebP and AVIF & Optimize Images – WordPress plugin | WordPress.org

Hi @Kevin , thanks for your answer.
Today, I have double checked with Imagify support and they confirmed to me that it is possible to set up a local test/dev site which is not publicly accessible and with a local test domain which is not in any public DNS, so exactly the type of setup we are using with local Devkinsta sites.

The tests that are failing, which I listed in my initial message in this thread, are local self requests. That means the Imagify Tools plugin which does the test is running these tests locally, and a POST request is done towards the same local test domain. ( mysite.local in this example )

I also dived into the PHP code of the Imagify Tools plugin and found exactly the test that is being done to see if the mentioned POST requests are working. (and displays the errors if not successful)
They are simply using the Wordpress function “wp_remote_request” to make a local POST request towards mysite.local/wp-admin/admin-ajax.php and so on.

So the plugin running on mysite.local is making these requests (via the function wp_remote_request) towards the same mysite.local site.

Somehow the connections are refused which seems to be due to the specifics of the Devkinsta configuration, i.e. the way Nginx is configured, etc.
I’d like to change the config so that the tests go through successfully, which should be possible as these are local requests. Once all tests are successful, I believe Imagify should work as intended.

Hopefully you can advise further based on this info?

Thank you for that breakdown @GoldyOnline!
Looking at this again, I think it’s related to this issue

Which is due to how Docker works. I’m going to do some testing and bring this to the Devs’ attention again. I feel like there should be a workaround.

Thanks for looking into this further! I agree that it should be related to the issue you referenced. I read through that thread just now and the issues reported there are very similar and even the same error message is mentioned there several times.
In the last post there Site Health: REST/loopback requests are failing, scheduled event failed - #28 by Dan0sz several links are given with potential solutions. I have a feeling those are in the right direction for solving this and might actually already point to a solution?
Unfortunately, I don’t have the required knowledge of these kinds of configs, so hopefully you can find out something on your end based on all this?

So for now I would recommend handling the WebP conversion on Staging/Kinsta since the Docker solutions aren’t very straightforward. I attempted it once and ran into a lot of issues.

The good news is that I’ve gotten confirmation from our Developers that the fix for loopback/cURL issue will be coming out either with the next DevKinsta release or very soon this year! It’s being actively worked on and tested.

@Kevin that sounds great that the issue is being resolved by the dev team! But when is the next DevKinsta release planned for? Which date?

“This year” sounds like it could potentially take many months still but I hope that is not the case?

I unfortunately can’t give a definite ETA, but you can see the rate that we have been releasing new minor versions this year: DevKinsta Releases (Minor) - #8 by Kevin

I said “this year” just to be safe, but this is definitely high on our list of fixes for version 2.6.0. The fix will still need to go through texting/QA before it is released.

1 Like

Ok thanks for the info! much appreciated, let’s hope the development and testing will go smooth :crossed_fingers:

1 Like

We do not block those requests, you’re probably passing a post request with empty referrer or something else.

@jackdoe thanks for the reply. I did a quick test by amending the code so that the Referer header is set but this doesn’t solve the issue. Also tried setting the Origin header but this also doesn’t have any effect.

@Kevin I installed version 2.6.0 and re-tested the issue I described in this ticket. The issue is addressed! :smiley: as you also announced in the release notes for this version.
The Imagify plugin is now working fine on the local Devkinsta environment, it’s communicating with the Imagify server and optimizing images. Also, the Imagify Tools plugin I installed to check for errors now doesn’t show any errors anymore, all tests pass.
Awesome! Thanks for fixing this :ok_hand:

2 Likes

Awesome, @GoldyOnline! I’m so glad this is finally resolved as well!

I’ll forward your appreciation to our Devs!

1 Like