Support » Plugin: WP Cloudflare Super Page Cache » [FR] Switch plugin off temporarily

  • Would be a nice to be able to switch off WP Cloudflare Super Page Cache temporarily (not just the fallback page cache), like other Cache/Optimization plugins do. That’s very useful when one’s testing/debugging something and needs to make sure it isn’t a cache/CF issue. Just disabling the plugin from the plugins page isn’t good enough, as all settings get lost and one needs to redo all the wizard and fine-tuning again.

    EDIT: Nevermind, it seems I haven’t understood correctly. “Disable Page Cache” seems to disable the plugin and at least some of the optimizations happening at the CF site, like the Worker script. But still, if one has two sites under the same domain (one live and one dev/localhost) this can get messy, as deactivating the plugin in one environment affects the other.

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    Disable page cache should disable the plugin from caching anything including Cloudflare. Cloudflare will still cache the static resources. For that, you can temporarily pause Cloudflare for this zone.

    Yes, thank you Saumya. The issue for me is, I have a mirrored copy of the live website on my laptop under the same domain (via hosts file). Noticed that disabling the plugin in localhost also wipes the Worker in CF, but the plugin in live isn’t aware of that and other errors start to happen. Would be nice to be able to just “pause” the plugin w/o touching the CF configuration, and so support such a many-to-one scenario, but perhaps that’s confusing for most users.

    Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    I totally understand your problem. This is why you should never set up a test site on the same domain just differentiated by HOST file. The best approach is making a copy of your site in a subdomain and use that subdomain site for testing and development. That’s how we do it. The main domain is for production and never should be touched.

    Would be nice to be able to just “pause” the plugin w/o touching the CF configuration, and so support such a many-to-one scenario, but perhaps that’s confusing for most users.

    This is simply not possible cause when you disable the plugin, it talks to Cloudflare over API and tells it that the user has disabled the plugin and so basically takes out anything that the plugin has added. Please don’t mind but you are setting up the test environment as wrong. We all have test environments/stagging environment but they always are in a different domain/subdomain or something. If you just copied the site to your localhost you can simply delete the plugin files from wp-content/plugins/ so your localhost site will not have the plugin. But as you didn’t disabled or deleted it from wp-admin the plugin won’t talk to Cloudflare and make changes.
    When you have your stagging site on a separate domain, both the plugin and Cloudflare will identify them as different. Please note both the plugin a Cloudflare is zone and path specific.

    I do understand most of the the drawbacks, Saumya. I do have too a stage env online on a different domain. One of the issues a same-domain approach has helped is with commercial plugins that are licensed on a per-domain basis. Other is having a mirror copy on a moments’ notice that may better help reproducing some obscure issue.

    Physically disabling the plugin (deleting/renaming the folder) is a good idea, forgot about this. Thanks!

    Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    You can use the premium plugins in your stage environment you just don’t add the license key. That’s it. The plugins are in GPL license so you can add it to multiple sites but you need the license key for auto-update and support.

    Unfortunately, not all commercial plugins follow that same guideline you mentioned. Many become crippled if not properly registered, and call home in intervals to check for license validity. In my humble experience, when team collaboration or politics aren’t a major issue, it’s easier and cleaner for me to keep the project under the same domain as live via hosts (and switch to live when needed) than to block/hack into plugin idiosyncrasies with every single update. Another example that comes to mind is the SMTP server plugin that I recall with an involved setup that I wouldn’t like to fix for a different domain (each time I’m taking a live backup back to localhost, or a localhost back to live in an emergency). Just many little things that have bugged me in the past and can’t recall atm had solidified into a preferred way of doing things, at least for personal projects. It also has happened to me that for every grand concept one gets enamored with of how things “should” be, there’s also the devil that hides in the little details, as the saying says.

    Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    In that case, I think manually deleting or renaming the plugin folder in your localhost is the way to go.

    Tried your renaming/deleting suggestion and it almost worked as intended.

    Renaming back (and re-activating, after WP complaints) kept the plugin settings intact, but it feels hackish doing so that way.

    Thinking a bit more about it, only deactivating a plugin shouldn’t delete any settings, and most other WP plugins seem to follow that guideline, so think this is actually a bug. Settings et al should be deleted only when deleting a plugin for good.

    Hope you’d consider looking into this. Thanks!

    Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    This is not a bug we need to clear connection with Cloudflare as soon as you deactivate the plugins as users might deactivate the plugin to test if the issue is causing by some Cloudflare cache or not. But again deactivating the plugin will not delete any settings/options you have set (except Cloudflare) like the things in wp-options table. They only get deleted when you delete the plugin. Other plugins work standalone and don’t create a bridge with Cloudflare as we do. Even other disk cache plugins will delete the advanced-cache.php as you deactivate the plugin. As those plugins are not talking to Cloudflare they don’t have to do anything else.

    But again deactivating the plugin will not delete any settings/options you have set

    I understand your point, but please mind that deactivating/reactivating the plugin does appear to delete settings from an admin perspective, as the wizard starts over again from Step 1: “Enter your Cloudflare’s API key and e-mail” etc. After re-enabling the plugin, one would expect to land on Step 3: “Enable Page Caching”, w/o losing any settings.

    Plugin Contributor Saumya Majumder

    (@isaumya)

    Hi @alx359,
    Please read my previous reply where I have clearly stated why that is not possible. After deactivate the plugin has already removed the bridge to properly deactivate the plugin. So when you reactivate the plugin the plugin again needs to setup the bridge. So you go through that step again. Finally all the inner settings you have selected earlier will still remain there.

    I see some settings appear to be there (e.g. “Don’t cache the following WooCommerce page types”) but other go to defaults (e.g. Worker mode, Enable fallback page cache, Add browser caching rules for static assets, etc.) In practice, one have to review the settings all over again. I understand the connection with CF needs to be redone, but re-adding the API, email, etc. shouldn’t be necessary, IMHO, as they would be in the wp-options table already. Hence Step 3 still seems a proper step after re-enabling the plugin, IMHO.

    My apologies if I come out as stubborn. Just trying to make the point across as clearly as I could, too, and/or learn something new along the way. 🙂

    Plugin Contributor Saumya Majumder

    (@isaumya)

    As far as I have seen that the API Keys doesn’t get deleted once you deactivate the plugin. But you need to reconnect the bridge with Cloudflare.

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.