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.
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.
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?
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.
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.
@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! 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