markussss

Yes, I installed the plugin just yesterday from the WP repository – did not even change a single setting, just run it once.

I forgot to mention that I also have reSmush.it installed and Process optimize on CRON job enabled. However, I could replicate the error without even touching reSmush.it (it was on all the time).

So I assume it’s only about you plugin and the Bulk Image Resizer plugin (when automatic resizing on upload is enabled)

Hi there Mateusz,

I get the same error when I use the plugin https://www.ads-software.com/plugins/bulk-image-resizer/ simultaneously.

Images or PDFs get uploaded to the media gallery but it throws this error.

This happens only when resizing at upload is enabled at the mentioned plugin.
I am not sure if this error is something that must be prevented on your end or the end of the other plugin.

The Beta from 3 months ago is not available anymore to download, so I am not sure about the current development about this kind of issue.

Hope this can be sorted out as it makes sense to first resize the images that gets uploaded and then convert them to webP

best regards
Markus

Duplicator Pro support told me they are not touching those fields in the DB, so it looks like it is more likely an issue with the plugin

Hi there,

I want to add something as I just realized the same behavior with Duplicator Pro. I thought about letting Duplicator Pro support know, but then I realized the same happens with Migrate Guru.

There is a difference though – Duplicator Pro Migration overwrites the date to the migration date.

Migrate Guru overwrote to another date 2 weeks in the past which is strange, but perhaps that also depends on the server. My two test migrations of the same instance went to two different hosting providers.

So it looks like there is an issue with the Email log plugin in the end.

Yes, I know … but it was a suggestion (without explanation) from Cloudways to try 127.0.0.1 instead of localhost.

I did ask them if they could please provide me with an explanation. If the information I’ll hopefully get is of value I’ll again post it here, so that others also have the chance to learn about it.

I want to add one more thing should someone run into the same issues.

I figured out when I enter 127.0.0.1 instead of localhost it also seems to work.

I changed it in the settings of your plugin …

I am going to inform CW and ask them what they think this means.

Because obviously the other plugin to purge Varnish did not work either with the default plugin setting “localhost”. The actual IP address must be entered.

[response] => Array
        (
            [code] => 200
            [message] => OK
        )

I just run another test. I do not have an explanation but this time it worked).

I changed the settings at WP Cloudflare Super Page Cache → Advanced → Varnish Settings → Hostname

Instead of localhost I added the actual server IP from Cloudways.

That way, it seems to work.

I run only one test and it did not work either with the Proxy Cache Purge plugin.

Now I think the problem is that the PURGE request never reaches the Varnish server of Cloudways. The PURGE will be probably sent to Cloudflare instead (and there is no Varnish cache at Cloudflare).

• This reply was modified 2 years, 11 months ago by markussss.

Hi again,

I contacted the Cloudways Support. I want to share with you exactly what they told me.

Basically, it seem you think there is something off with Cloudways, while Cloudways says there is something off with the plugin.

We believe that your Varnish and the cache plugin you are using wp-supercache is not integrated in a correct manner so Varnish is warming its own cache and wp-supercache saving its own under wp-content/cache due to which you need to manually purge varnish when any changes are pushed to frontend.
In your case, you need to purge wp-supercache from the admin side and Varnish cache from the Cloudways console independently to get rid of cached content.
Appreciate it if you can verify with wp-supercache if they have any documentation to integrate the plugin with Varnish the PURGE and UNPURGE is not being blocked via Cloudways server as the other cache plugins work well with Varnish. I would recommend you use the Varnish HTTP plugin if you are struggling with wp-supercache, this plugin doesn’t install the web application Varnish on your website. It only sends a PURGE request to the URL of a page/post when they are modified. This means that it clears the page’s server cache and rebuilds the page https://www.ads-software.com/plugins/varnish-http-purge/#faq.

Can you do something with that additional information?

• This reply was modified 2 years, 11 months ago by markussss.
• This reply was modified 2 years, 11 months ago by markussss.

I see… that basically means it won’t work with Cloudways until Cloudways changes something right?

And I learned something today. Caching is really complicated with all those different cache levels. Learned a lot already but did not know that.

Then I could disable Varnish in this case.

There might be situations though when several sites run on one CW server. Some with Cloudflare, some without … in this case I could not use Varnish at all.

So, you are saying that if you purge the varnish cache from the plugin settings page then it is getting cleared but automatically it is not getting cleared?

No, varnish cache does not get cleared at all with the plugin. I must manually purge varnish at the Cloudways Platform itself AND additionally also purge all cache with the plugin.

Also it must be done in this order.

Attached the log file – I only added the part when I clicked ‘purge varnished cache’
https://www.dropbox.com/s/ss5a7b61euamzxz/varnish-log.txt?dl=0

I figured something out that might help.

Clear all cache when using Cloudways + Cloudflare + Cloudflare WP Super Plugin
1) Manually purge Cache in Cloudways Platform (platform.cloudways.com)
2) Purge whole cache from Cloudflare WP Super Plugin
→ then really all cache is cleared.

e.g. I change a product from in stock to out of stock and it shows correct.

What does not work?
– Only Purge whole cache from the plugin (even though its set up correctly with Varnish Cloudways setting and port 8080)
– Manually purge Cloudways varnish via plugin and then again purge whole cache
– Only purge varnish cache from Cloudways platform

It requires the combination of purging varnish at the CW platform and only after that purge whole cache from your plugin.

I hope that makes sense to you and you can do something with this information.

cheers
Markus

That’s a good idea… it happened on both of those sites I mentioned. I do have other sites as well with Cloudflare, Cloudways, and your plugin

https://safenote.co/r/61928f2ae02163@24867953

I learned it the hard way already to add sensitive information here, as I am not allowed to delete it afterwards. Can I somehow send this private to you?