CloudFlare Releases Major 3.0 Update to Official WordPress Plugin


Last week CloudFlare released the first update to its official WordPress plugin in approximately six months. Although the release post refers to the update as “CloudFlare’s new WordPress plugin,” it is essentially a major rewrite and a jump from version 1.3.25 to 3.0. The previous changelog has been wiped out and replaced with notes for the 3.x releases only.

CloudlFlare 3.0 introduces one-click optimized settings for WordPress. These defaults include security set to medium, auto minify for JS, CSS, and HTML, 4-hr cache expiration, and email address obfuscation enabled, among other settings.

The latest update also adds an optional setting for automatic cache purging that will happen in the background when users make changes to the appearance of their websites. This feature hooks into switch_theme and customize_save_after to purge the cache upon theme changes and edits saved from inside WordPress. Users can still manually purge the cache on the settings page.


The “More Settings” page allows users to tweak CloudFlare settings within the WordPress admin, as opposed to navigating to the dashboard. Users can also view analytics for total visitors, bandwidth saved, and threats blocked.

CloudFlare 3.0+ adds Web application firewall (WAF) rulesets for users on a commercial plan. The WAF includes rules that mitigate WordPress-specific threats and vulnerabilities.

There are some important changes listed in the plugin’s changelog that CloudFlare neglected to mention in its release post. The 3.0 release removes submission of spam comments as well as the ability to toggle Development Mode on/off.

It also removed HTTPS protocol rewriting and added HTTP2/Server push. After HTTP/2 Server Push led to 520 and 502 errors for some websites, CloudFlare removed it in a subsequent maintenance release (3.0.2). The feature has not yet been re-added to the plugin, but CloudFlare developers are in the process of rewriting it. The plugin’s author explained why users were seeing excessively large headers with the update:

We did a lot of QA on this latest release. It was in beta for about a month with over 55 beta testers. The root cause of the 520 and 502 http error codes was because our implementation of HTTP2/Server push created too many headers for websites with lots of resources to load. We never saw this during testing because by chance none of our beta testers had front ends large enough to trigger the header bug.

Feedback in the plugin’s support forums indicate that many users were unable to log into their sites after the update and unable to configure settings. Other users are reporting mixed content warnings. In one month’s time the plugin’s ratings have dropped from 4.1 to 3.8, but CloudFlare appears to be responsive in the support forums. The company is actively working on rewriting the features that are causing issues.

CloudFlare is installed on more than 100,000 WordPress sites. Users should be prepared to make a backup of their sites before applying this major update.


18 responses to “CloudFlare Releases Major 3.0 Update to Official WordPress Plugin”

  1. It is nice to see CLoudflare working on better integration with the WordPress platform. It will be interesting to see how this impacts other such plugin such as WordFence which handles WAF rules for well over a million or more WordPress sites.

    As a user of both Cloudflare’s services and WordFence, it means I will have to do that much more investigation to determine which options from each will become more viable on a case by case basis.

    Thanks for the great update.

  2. I am one of the people who experienced this 520/502 error, with plugin auto-updates turned on it took me the whole of 5 minutes to recognise that the Cloudflare plugin was the culprit. This is the second time that I have been burned by auto-updates and while I appreciate how responsive Cloudflare has been in solving this issue it is indicative of a common problem in the developer community.

    The problem as one person once put it to me is this:
    The developer has a high end mad specs laptop/computer that they use to develop with superfast internet and superfast/supercharged everything. They develop this awesome product and proceed to test it on this awesome set up without ever considering the simple fact that Joe the user has got a puny device. Developer is shocked people think their product is crap even though it’s awesome on their end.

    Morale of the story: Always put yourself in the user’s shoes.

  3. Cloudflare support is responsive, but the issues go on forever.

    I dropped Cloudflare for CPanel altogether because their IP’s have to be whitelisted and all traffic comes through those IP’s. There is no way to ban offenders without banning everyone accessing the website through that IP. That leaves hackers to keep hammering away to their heart’s content and using up precious server resources.

  4. I really wish WP had a core method for major plugin updates like this that were likely going to break things. It’s come up before (ACF).

    I’ve only been testing the new CF plugin on a few “non-critical” sites (like my blog, and a few low traffic cliets). I’ve had mostly failures (no controls on settings page, or if the controls show they don’t work).

    I love the design and that we can _finally_ (in theory) purge that cache from the WP dashboard, that’s a huge win. The plugin should have had a more extensive beta test through because it’s clearly a problem for a lot of users, most not savvy enough to troubleshoot/rollback on their own.

    My biggest concerns are that:
    #1 it’s been stated it doens’t support multisite. I’m not sure what that really means though since I’ve got it working on 2 small multisite installs… maybe they just mean there is no global configuration for multisite, it’s configured sub-site by sub-site… it’s not clear, but it sure _should_ support multiste.
    #2 I have over 15 CloudFlare accounts (mine, plus clients). Not sites, heck I have 15 sites in my own CloudFlare account, and some clients have just as many. Per the support threads it seems like the plugin actually cares which CloudFlare account your logged into, which is crazy, what’s the point of the API Key. Maybe… it just cares what account your logged into when you install? or when you upgrade? again, that’s not really clear.

    Thankfully, while the settings page still doesn’t work across a dozen sites I’ve tested on, the sites all load and perform just fine. I haven’t seen any 5xx errors or site down conditions (I thankfully missed the HTTP2 push header bug)

    • Plugins themselves can warn of problematic upgrades. I don’t think WordPress core needs to provide additional functionality for that.

      All the plugin needs to do is keep the old functionality running in a legacy mode, then only upgrade you to using the new code base when you click an upgrade button.

        • It seems perfectly realistic to me. Different circumstances warrant different options. I just gave one option above.

          Another option would be to set the plugin to switch itself to being updated from an external repo, but prompt the user to bypass this and upgrade to the latest one on, although with an appropriate warning to test before doing the upgrade.

          There are lots of other ways of handling this too, but I don’t think any of them warrant inclusion into WordPress core.

        • It is in the end an halting problem. A code can not reliably decide for itself if it will successfully run or not by the laws of computer science, and it has to run to figure that. At that point DB changes had been made and there should be a mechanism to rollback changes.

          If the plugin itself can not run at that point obviously it can not do the role back of data. Running different versions from a different source do not solve the problem that once DB changes were done there is no trivial way to get back to the previous data configuraion and the plugins will have to include a conversion code from any version to any other version data format, which makes it not realistic as it is too much work for no real gain (you should run the latest version of the plugin, right? sooner or later it will break your site if you don’t update)

          core can help by doing an automatic backup before upgrades, but in the end it is the responsibility of site owner not to buy into this stupid “automatic update” and do their own backup before upgrading (or even better test on a test server first).

          But then, when you manage 40 sites for peanuts you obviously do not have the time to properly do anything and you just cross your fingers and go with the fast way, so you get into a position of trusting code you never paid for and don’t have any support agreement for it.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.