[Curtis B.]

Curtis B.

July 20, 2021 at 9:55 pm #3531241

David, I want to thank you for all of your excellent and detailed articles/videos about your decision and your actual move to Cloudways. I’ve had my membership area and blog on my single website using WPEngine for a couple years now, and for the “most part”, haven’t had any issues.

But, the desire for (even) faster page loads (lots of active plugins of course) has inspired me to follow your advice, and over this past weekend I moved my website to Cloudways.

(I made sure to click through your Cloudways referral link as I signed up and paid, so I do hope you get credit for it with them!)

I’ve read and heard you mention you personally don’t use their included “Breeze” cache plugin with BMA. Is this still the case even now that you’ve merged your blog and membership WordPress installations together?

I have spoken with at least two or three different tech support agents with Cloudways (in chat) and they have all said they suggest (or insist) I use Breeze — even when I stated I am running a membership website with dynamic content.

When I pressed them on it, I got answers like this when I asked what would happen if I deactivated Breeze:

Breeze is a cache plugin so you will not be able to purge cache and your site will show old content to your visitors. If you are not using breeze use other plugin instead.

I followed your server setup advice and went with the Vultr “High Frequency” 2gb/64GB server. My membership software is (ahem, your favorite) MemberMouse (though you’re persuading me quite well to consider the “WP Fusion/WooCommerce Subscriptions” changeover at some point soon).

As of tonight, while I try and figure out the decision to keep running Breeze or not, I followed MemberMouse’s advice to add all the MM Core pages to the Breeze plugin setting’s page “Never Cache these URL’s” field list.

But, now I wonder if I would need to do the same with their Varnish cache “system” as well… Ugh. A bit over my head to make a sound decision.

Long story a little shorter, because I know you’ve been down this exact path yourself saddling MemberMouse on top of Cloudways, should I just deactivate Breeze, cross my fingers and never look back?

And if so, is there anything else you can think I should set — such as something in Varnish — to keep my membership website dynamic?

Thanks, David!

[David Risley]

David Risley

July 20, 2021 at 9:55 pm #3531262

I didn’t use Breeze (or any caching) when the LAB was separated. That’s because there was literally no traffic on the site which wasn’t logged in. Now that the sites are put back together again, I am using Breeze. I simply exempt logged-in users from the cache so that all the dynamic stuff for members works as it is supposed to.

You can do the same thing. And, as for pages you need to exempt from the cache, that’s only for dynamic pages where they are NOT logged in when they get there. For instance, a checkout page. So, you would want exemptions for those things MemberMouse gives you.

As for Varnish, you can set up those exemptions within your Cloudways account. Although, it could be that the exemptions within Breeze are all you need because Breeze is designed to work with Cloudways so closely.

[Curtis B.]

Curtis B.

July 20, 2021 at 9:55 pm #3531376

Thanks David, I really appreciated the detailed answer. Knowing (for sure) that you didn’t use caching on your “Lab” installation before, but you do use “Breeze” now that it’s been combined with your blog installation, really helped me understand how this all works.

So, this past week I went in and added my list of MemberMouse dynamic “core” pages to both Breeze and Varnish in Cloudways settings (just in case).

For anyone who comes across this thread in the future and is still having problems preventing pages from not caching, after adding to me “excluded” list(s), my login page still kept giving me problems. After several days of back and forth with MM and Cloudways support (both who couldn’t figure it out) I finally figured out (on my own) the issue was that I was following MM’s support page exactly and I actually needed to add a “/” at the very end of each of their “core” pages that I didn’t want to be cached. So for example, the login page should actually be listed in the exclude list as:

https://www.[my domain]/login/

Now, when I type in a wrong password, since it’s no longer being cached, the login page now shows me the error codes that before were being hidden by reloading a “clean” cached version of the page (without the codes).

At least, so far so good a couple days later. 🙂

[David Risley]

David Risley

July 20, 2021 at 9:55 pm #3531378

Glad you got it all figured out. 🙂

[Author]

Posts