18 Comments

  1. Derek Wood

    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.

    Report

  2. Garikai Dzoma

    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.

    Report

    • Ryan Hellyer

      The developers hardware has no bearing on this. Their inability to recognise that they’re about to break peoples sites due to modifying how existing features work is though.

      Report

  3. Cameron Jones

    I thought it was very suspect for the version number to jump from 1.3 to 3.0, especially just after having released a maintenance update. It’s already up to 3.0.3, I’ve held off updating until it’s become more stable.

    Report

  4. Sallie Goetsch (rhymes with sketch)

    Made the update to 3.0 and noticed problems with the mobile view of several pages. Deactivated it and decided to use WP Rocket to manage interactions with CloudFlare. That’s working fine.

    Report

  5. John

    Hi,

    I’m one of the developers of the CloudFlare WordPress plugin, just wanted to mention we’ll be adding protocol rewrite back in the next update.

    https://wordpress.org/support/topic/announcement-about-protocol-rewrite/

    Report

  6. Jeffrey

    Oh no, I updated and now it does not load the settings page, only blank page.

    Report

  7. Corey

    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.

    Report

  8. Jon Brown

    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)

    Report

    • Ryan Hellyer

      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.

      Report

      • mark k.

        That is not realistic. When the code was changed you have upgraded even you you run in some kind of “compatibility mode”. Go back and read how ninja forms were hacked exactly because of the system you suggested

        Report

        • Ryan Hellyer

          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 WordPress.org, 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.

          Report

        • mark k.

          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.

          Report

Comments are closed.

%d bloggers like this: