10 Comments

  1. Matt Cromwell

    Thanks for the write-up Sarah! We would love to chat with anyone on the Core team about considering WP Rollback as a Core feature plugin. We’ve heard from many, MANY happy users that they would love to have this in Core.

    Report

  2. WP Tutoring

    I think having something like this in core would be phenomenal. It would make supporting WP much easier and help the “novice” user navigate WordPress more easily, while also helping larger businesses feel a little more comfortable using the platform because there will be an easier way to roll back.

    Report

  3. Brin

    So just to check: it doesn’t roll back any parts of the database (i.e. those related to the plugin you want to roll back), it only roll backs the plugin files? Is that right?

    Report

    • Brin

      – ah, sorry, I missed the last paragraph of the article on first read. I understand now. Thanks.

      Report

  4. David Anderson

    “a lifesaver” when applying WooCommerce

    Rolling back your files only, as a strategy for backing out of a WooCommerce upgrade, is not sensible. You are relying upon any problems in the upgrade being related to code in files only, and not to your database. The article does note that your database isn’t being rolled back, but I think the above line is unfortunate because it may encourage people to think that perhaps that doesn’t matter very much. Before applying WooCommerce updates, use a backup plugin.

    Report

  5. Peter

    Not sure what exactly this plugin solve to 30 000+ users, but probably something similar than Happy Dolly to 1 + million happy users. So how Matt wish, this should be in the core, that we can click here and there and have some fun with websites. It’s always refreshing to have some cool plugin installed on the site :)

    Report

  6. Alec

    This is a great defensive plugin. The ability to easily browse changelogs is a huge improvement to WP Rollback.

    WordPress has gone update crazy – update core to the latest beta, update WooCommerce to a beta 3, face security issues (WordPress 4.7.x through to 4.7.4), incompatibility, endless software renewal costs, troubleshooting. In the end, you have to hire professionals (us) to clear up the mess. Latest fun is in 4.8 where the flexible text widget was force replaced with a WYSIWYG widget which broke a huge number of existing text widgets and hence sites.

    How this user pain is supposed to result in higher WordPress satisfaction ratings and market share is a mystery to me.

    Our own defensive approach has been to give site owners back control of updates. Update what you want, when you want, while automatically applying security updates (which go back to 3.7.x still). With control over updates, we’ve reduced our clients’ maintenance burden by a factor of four – they are delighted to spend their budgets on real site and business improvements.

    Report

    • David Anderson

      It’s unfortunate that there’s no mechanism available for plugin/theme authors to mark an update as a security update, or to mark certain versions as insecure. WordPress core, as you point out, had security updates, pushed automatically, for years. But with plugins and themes, it’s not possible to indicate that an update is a security update in any way that core will recognise.

      Report

      • Alec

        David, you make a good point. WordPress.org while saying the wrong thing – “update to our latest beta all the time” as the current release is effectively beta software as both the 4.7 and 4.8 releases have demonstrated – actually does the right thing – maintaining security releases going back to 3.7.x (deprecating all releases pre-3.9 or even 4.0 would seem fair at this point). WordPress’s security czar Aaron D. Campbell told me at WCEU Paris that the security team would like to drop updates for a few of the trailing releases to reduce the burden.

        It would be really great if the WordPress plugins team could add a lightweight flag for security releases by plugin authors. For instance it might be that version 2.7.3 of a plugin is secure but 3.0.x to 3.1.2 are not (additional functionality). The issues is with self-policing. Those freemium plugin authors who create exclusively for money (I won’t list them this time as I’d like you to see this answer) will be tempted to mark everything except the latest release as insecure. There are ways to enforce less selfish behaviour from freemium/pro authors like temporary suspensions from plugin directory search for false alarms (just like for pulling a fire alarm when there’s no fire).

        It also would suggest that plugin authors should be able to release security fixes for a previous major release. I.e. if I were the author of the plugin above and I knew that I had a security fix for 2.7.2 which is easy to implement and that many of my users were still on 2.x family instead of 3.x for compatibility reasons, I’d be able to release a 2.7.3 version.

        Significant structural enhancement to the WordPress plugins space like this would have been more welcome than an almost year long tug of war over a mobile style appstore layout for the plugin directory – which finally had to be largely retired as it just made the plugin browsing experience worse.

        Even as matters stand, for a site owner or an agency who would like to reduce his/her maintenance burden, managing one’s updates in a controlled way can reduce that maintenance burden by a factor of four. Avoiding plugins with a history of acute security issues is a good start. Locking down your hosting to minimal required permissions to run WordPress is another good step (WordPress managed hosts do a good job with this if a site owner or an agency don’t have the scale to manage hosting themselves).

        Both Sucuri and WordFence weblogs (and often WP Tavern and ManageWP) cover almost all security vulnerabilities in layman’s terms (unlike say CVEdetails). There’s even an aggregate WordPress security blogs feed. If a WordPress site’s main admin (that might be the publisher) picks one of them to read regularly, s/he’ll know if they face any security issues with existing plugins. Reading occasional security bulletins is a lot less work than diagnosing software conflicts.

        In any case, the current situation of whack-a-mole between buggy core releases (really they are beta and should be embraced by cutting edge types and mature for six months before being declared production) and incompatible or paid upgrades to plugins is anything except efficient or professional.

        Working graphic designers and busy video production houses never run the latest version of their OS as they need stability to do their work. I’d say business and media publishers or just a guy/woman who want to publish regularly are no different. Let’s work together to make publishers/site owners jobs easier, not harder. Many of us joined the WordPress community to help democratise publishing and help people create more and better content. Let’s do just that instead of draining them with never ending “mandatory” software updates.

        Bringing the conversation back to WP Rollback – not all the necessary tools are in WordPress but it’s really great that companies like WordImpress are creating software to improve updates workflow with the existing tools which are there but not easily accessible.

        Report

  7. Kadai Crosshansen

    True, this plugin is a true life saver. Especially in some circumstances and with certain plugins.

    In my case, the last time I genuinely had to rollback was when Page Origin had a bug where page links were not converted.

    Despite the title of this, WP Rollback did “kinda” did work on multisite installations. Of course, the usage was tricky. As you needed to activate it only on a subsite to be able to work with it.

    Report

Comments are closed.

%d bloggers like this: