markussss

I just had the same situation again on a different website (and different Cloudways account).

Something was off after updating plugins. I cleared / purged all cache.
It did not help. Cache did not get purged.

I needed to go to Cloudways Platform to manually purge Varnish cache.
I could notice immediately the difference. Cache got purged.

I have no explanation for it. Only that it obviously does not work.

I am just not sure if Cloudways could do something about it. Or if there is something to do on the plugin to make it work.

I double confirmed now with Cloudways that the port is still 8080. Also they told me that Varnish will be auto purged every 4 hours.

I did not test with changes in Posts/Pages, but changes on widgets definitely required some additional purging & clearing.

I’ll let you know if I figure out more when testing. If you have any idea please also let me know.

Thanks

Thanks Saumya for getting back to me. I can’t talk for the original poster but it’s not fully clear to me if Varnish gets actually purged.

– The system will only auto-purge if you post or update any pages or posts or CPTs. But if you are making any changes in the Widget or Menues or some plugin settings etc. you have to manually Select Purge Whole Cache from the top admin bar or from Plugin settings page. That should purge your Cloudflare cache as well as Cloudways Varnish Cache.

Exactly. However, I am not sure if the manually purging the entire cache works. The setting to include Varnish is enabled. Even if I manually click on Purge Varnish Cache I am not sure if it actually works.

I wonder if there is a reliable method to test if Varnish got purged or not.

Scenario 1:
1. Added new widget
2. Manually purged whole cache including varnish
3. Widget not visible
4. Go to Cloudways and purge cache there
5. Widget visible

Later I tried the exact same thing again the other way round but the result was different
1. Deleted new widget
2. Manually purged whole cache including varnish → no difference
4. Manually purged fallback cache, varnish cache → no difference
5. Widget still visible even though I deleted
6. Check URL with /?nocache → shows the expected result
7. Cleared Redis Cache → no difference
8. Deleted Redis → no difference
9. Restarted Memcache → no difference
10. Restarted Redis → now that worked

I tested many different scenarios. It’s just not fully clear yet as the outcome is not obvious to me.

Do you know if I can reliably test if Varnish got really purged via Cloudflare Super Cache “purge whole cache”?

Can you do something with the hint that /?nocache does work from the very beginning? With several cache levels (browser cache, fallback, cloudflare, varnish, redis, memcache) I am not sure what /?nocache actually means

Thanks so much!

Markus

Chiming in here … I remember Cloudways support told me their services (including Varnish) run on port 8080, however, I can see the same issue.

E.g. If I change widgets in WordPress I need to go to Cloudways to purge the Varnish cache manually from there.

Would love to learn more how to troubleshoot / solve this.

Is there a reason why there is an additional setting only for Cloudways Varnish?

Thanks Marho,

I am in contact with your colleagues via email. Still did not solve it but we are one step closer to it. It works on a duplicated version of the site on a different hosting, so we assume something must been off with permissions.

best regards
Markus

Thank you very much, Saumya!

Thanks Saumya for getting back to me … after lots and lots of research, I understood how caching works for static sites. Basically, WP sites become almost as fast as handcoded HTML sites.

Then on the other hand, I ask myself how all those member platforms work when they do hardly get the support from cache (except for images, etc.)

As I see it, it would be extremely helpful to decide as an administrator which pages will get served from cache in which not even though members are logged in. But that could also be risky to put this responsibility into the website admins hands.

For a membership site, logged in members access:
– the exact same pages as non-logged-in users → keep static from cache
– additional pages for members only → load dynamically from origin server

I understand this has nothing to do with Cloudflare or the plugin but is a more general topic (I do not know yet how to solve).

Hi Geoff,

did you run into 503 error with the Event Manager?
It’s the only issue I face, and I have no explanation for it. I only tell the NPO client – “please do not click there” – which is not the best workaround.

Tested with PHP 7.4 and 8.0, latest WP5.8, of course https, pretty permalinks, and Internet connection, no additional firewall or security plugin.

Any other idea? I would assume it’s not the first time that this happens.

Thanks
Markus

Email sent. Thanks!

Thanks – I could not get RSVP to work how I liked it, so I go with a workaround and still use the good old Doodle.

Issues (fyi as this is a different topic)
– Attendees do not show in frontend
– No opportunity to show attendees, only to logged in users

My goal was to show the event public, but RSVP + attendee list only to logged in users.

Hi Adam,

I think answering via email does not work with the wordpress forum.

That did the trick and works as a workaround. I still do not understand why the form would look differently.

Even now, the form looks slightly different when embedded directly on a page vs as a popup.

However, now at least the label moves up enough when active and the inputted text is not on top of it anymore.`

Are you able to edit the posts? I as the thread creator cannot delete or edit anything. Would like to get the URL removed.

You can have a look at the live site at … and click “Kontakt” in the menu to trigger the popup with the Forminator form.

Hi Nebu,

the plugin used for the popup is https://www.ads-software.com/plugins/popups-for-divi/

You can have a look at the live site at {link removed} and click “Kontakt” in the menu to trigger the popup with the Forminator form.

best regards
Markus

• This reply was modified 3 years, 2 months ago by Yui.

Why is it marked as spam? It’s definitely not spam. Lessons learned: do not edit a post twice in a very short time.

Wow @wpmudevsupport12 Patrick! That is impressive and actually quite easy.

What could I do to make the date read only?

I did not use the “prepopulate” feature but only show the current day as default value. That is actually fine, only that the user could change it.

One option would be probably just to “hide” the field – or is there any better option?

best regards
Markus

Thanks for getting back to me Patrick,

I had already such a feeling that it’s not that easy to accomplish.

In this case, I stick to the manual work and just switch the text for the client.

best regards
Markus