Cancel

Sarah Gooding

WP Rollback Adds Multisite Compatibility and Changelog Preview

In the two years since WP Rollback launched on WordPress.org, the plugin has racked up more than 30,000 active installations with nearly all 5-star reviews. It allows users to roll back any WordPress.org plugin or theme to a previous version with just a few clicks and also supports beta versions of plugins.

It’s easy to see why the plugin is so popular. Navigating buggy updates is a natural part of life when maintaining a self-hosted website and not all users have a separate testing environment for their websites. This tool gives them a basic diagnostic tool and the confidence to apply updates knowing they can easily roll it back in case of a problem. Many reviewers cite the plugin as having been “a lifesaver” when applying WooCommerce or Yoast SEO updates that had unexpected results.

The lone one-star review of WP Rollback was given because the user anticipated multisite compatibility and was unable to get it to work. That issue has been solved in the latest update.

WP Rollback 1.5 is fully compatible with multisite networks, giving super admins the ability to roll back extensions from the network plugin/themes screen or from the the plugins/themes screen of the primary site in the network. Sub-sites do not have the ability to roll back plugins and themes for the entire network. The UI for rolling back themes on the network admin screen is identical to the plugin screens, as multisite doesn’t have the fancy theme preview screen that single site installs have.

Version 1.5 also adds the ability for users to preview the changelog for previous versions of a plugin. This makes it convenient for users to quickly view the changes for each version without leaving the admin.

WordImpress, the folks behind WP Rollback, have considered adding core rollbacks and database savepoints, but both features have serious potential drawbacks that could turn it into a high support-demanding plugin. In its current state, the plugin is virtually support-free.

Matt Cromwell, Head of Support and Community Outreach at WordImpress, said the team thought about monetizing the plugin in the beginning, but is not pursing any plans to do so at this time.

“We think of it as just one of the many ways we are giving back to the WP community,” Cromwell said. “Our preference would be for the core team to consider it as a potential feature plugin for eventual core inclusion.”

Cromwell said WordImpress hasn’t made any intentional steps to see if core folks are interested in WP Rollback becoming a feature plugin, but the team has purposely built it to be as close to core standards as possible. He believes it would be relatively easy to implement in WordPress.

Suggestions for new features, general feedback, and bug reports are welcome on WP Rollback’s GitHub repository. The plugin’s authors recommend backing up your site before using it to rollback plugins and themes or testing rollbacks on a staging site first. WP Rollback is not capable of rolling back changes a plugin update has made to the database, so a backup can come in handy if the database changes are incompatible with previous versions.

Category: ,
Tags:
10

10 responses to “WP Rollback Adds Multisite Compatibility and Changelog Preview”

  2. 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.

    Create forum topic from comment

  4. “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.

    Create forum topic from comment

  5. 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 :)

    Create forum topic from comment

  6. 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.

    Create forum topic from comment

    • 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.

      Create forum topic from comment

      • 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.

        Create forum topic from comment

  7. 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.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

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