In his 2012 WordCamp SF Keynote, Matt reiterated his vision of of WordPress as a system that silently updates itself without requiring user input. This delightful utopian dream, however, relies on excellent code contributions from the massive international WordPress developer community.
The problem is, this community has formed precisely because of the low barrier to entry that WordPress provides. I posit that we will NEVER achieve this vision if it is dependent on improving code habits among developers. What we need in order to achieve this vision is a system to support it. This system may consist in part of a review process for plugins and themes and some automated testing. But above all, I propose that WordPress needs an upgrade history / versioning framework for plugins, themes and possibly even core.
Picture this scenario:
I am a blogger. I have a self-hosted site with some plugins and a theme. Either I manually update core, plugins, and the theme or perhaps it automatically updates. Either way, I’m shocked to find that after my last update, my site crashed. My first thought is that I need to undo that update. But I have no idea how to revert!!!
Ok, picture this alternative scenario:
My site upgraded itself and its various components and ran a test on itself after each component upgrade and figured out that PluginX caused a fatal error. It reverted pluginX and sent me a notification with a link to the versioning dashboard. It also sent the developer a notice and since the developer received dozens of these notices soon after a deployment, the developer is already working on a fix.
Let’s provide peace of mind by building a system that can foster a retractable upgrade of any plugin, theme or WordPress core. This system will implement the following components:
- Upgrade versioning history UI and framework with the ability to revert a plugin/theme/core to any recent prior version.
- An automatic test of various screens after an upgrade including at least the following screens thus ensuring that we can undo the damage if there are any problems:
-
- Home
- Plugin admin
- Theme admin
- Upgrade admin
- History manager
- WP administrator notification
- Optional plugin developer error report ping
- Bonus: offer a url endpoint to run the site in “safe mode” thereby offering a simple and secure back door to the site for administrators. (This would not make WP run in safe mode for everyone, just for one logged in admin)
User Interface
Plugin / Theme / Core UI Integration
- Link the version number to the history window.
- Add a “History” link (to be explicit).
- Possibly make other updates – but for gen1, that’s all we really need.
History Lightbox
This lightbox is opened by clicking the version or history links on any plugin, theme or on core.
- Contextual settings:
- Developer Notification override (default, auto notify, manual notify, never)
- Upgrade setting override (default, auto, manual, never)
- Table of the version history:
- Version
- Date
- Status (works, broken, new, n/a, error – links to what caused the error)
- Change Log (links to the change log per version)
- Action (Update, Installed, Not Supported?)
Admin Settings
Some settings that might be nice in the admin for this include:
- Default setting for Developer Notification
- Default setting for Auto Upgrade (default) / Manual Upgrade / Never Upgrade
- Notification settings for auto upgrades (who should get emailed and on what conditions)
Configuration
Many of the settings could conceivably be configured in wp-config.php or functions.php. At a minimum, we’ll want to be able to completely deactivate the system for deployed production sites.
Common Concerns
Thus far, I’ve encountered three primary concerns to regarding this proposal:
- What happens when you revert and there has been a DB change?
- What happens when an upgrade causes the infamous white screen so that the system can no longer fix itself?
- Won’t this make it even MORE likely that people will stop upgrading?
- What about sites with a lot of custom code (plugins and/or themes)
1. Database Sanctity
One of the biggest concerns with regard to reverting code is that the code may have altered data. Ideally we would do something like make a backup so we could revert to it but this won’t work for most cases. Some WP installs are simply too big to demand a backup. Or they are sharded. Or… one may want to revert by more than a single revision. Or revert back to something from a couple days ago even though there has since been a lot of site traffic, posts published, etc.
In short, the database problem is certainly the weakest part of this proposal. However, here are a few approaches we can take to addressing this:
Don’t worry about it.
Even if we ignored this problem completely, we’d be better off than we are today by a long shot.
I suspect that the vast majority of upgrades don’t require any changes to the db. Today, people upgrade and not only do they not have a simple way to revert, they are blindly taking a chance with the new code and its effects which sometimes result in partial or even complete system failures. Even without worrying at all about the db problem, we’d be reducing the risk involved in upgrades dramatically simply by offering a mechanism to undo the upgrade.
If a new version of a plugin causes 90% of sites to crash, odds are that reverting it will only leave a small fraction in the dumps. Even if it leaves 10% damaged, that’s a reduction of crashes on that plugin version from 90% to 10%.
This is especially true if the upgrade causes a fatal error. It is likely that the fatal error is actually preventing the db updates from even being executed in the first place.
Negligence is not the best way to handle this, but it shouldn’t be a showstopper.
Data version API ( and testing suite )
The cleanest way to handle this is to build an API that supports upgrading the database as well as reverting it. The only problem with this is that it again puts the responsibility of customer confidence on the masses of contributing coders.
This is better than simply not worrying about it, but if a dev is sloppy enough to have baked a fatal error into a plugin they probably won’t have implemented the data versioning API. And frankly it might be a lot to ask unless we also make an easy to use versioning testing suite so people can test their work.
I’ve looked over how core handles this in wp-admin/includes/upgrades.php and wp-admin/includes/schema.php and in both cases it’s pretty well manually managed with a giant conditional and a bunch of version numbered functions.
What if we did something, dare I say, a little more like the Ruby on Rails ‘migration’ in this regard?
http://guides.rubyonrails.org/migrations.html#migrations-are-classes
If nothing else, we should at least provide some hooks for versioning to set a standard.
Conditional Upgrades
Another idea is to give some easily managed power to the developer such that they can define a simple toggle in the readme/plugin header that declares a version as having db changes and requires the admin to actively upgrade (hopefully prompting people to make db backups). This is not mutually exclusive with the versioning API.
Any Other Ideas?
If you have any other ideas on how we can manage to safely revert code without causing database problems and without relying on the developer, please let me know.
2. Defense Against the Whitescreen
In order to ensure that the upgrade system works even when the rest of WordPress doesn’t, the upgrade will have to run on as little core code as possible and without activating the theme or plugins. In fact, it should probably run in SHORTINIT mode. We can probably assume that whatever happens before SHORTINIT is safe from the whitescreen in its own right.
Independent Upgrade Endpoint
One key ingredient to this proposal is an independent upgrade endpoint. This is a php file or WP endpoint that relies only on WordPress to the extent that it has loaded in SHORTINIT mode, that can securely manage to revert recent upgrades in the event that the fully loaded WP site is crashing.
Upgrade Test Ping
When an upgrade is performed, WordPress will spawn an independent CURL to the upgrade endpoint url to start up an independent test process. If the tests fail, then the code is automatically reverted and appropriate notifications are sent.
This request is made independently so it should not, itself, fail. In the unlikely case that the request itself fails due to timeout or miscellaneous server error, we’ll need some sort of method for re-invoking the test automatically. Here’s one idea:
When an upgrade is initiated, an autoloaded option is set indicating that a test of the upgrade is needed.
When a test is started, that option is updated to be the timestamp of the start of the test.
If that option is subsequently read AND the timestamp is older than X, then we can assume that a test was attempted and died. We can either try again (a limited number of times) or we can assume that we need to revert the last upgrade.
WordPress can take on this logic during load but it would probably be best to try and use cron for this.
3. Don’t Stop the Party
Mike Schroder, who is a bit of a liaison between WordPress and Dreamhost, voiced a concern stating that currently it is very common that users and developers install a WP site and then never upgrade it. This proposal attempts to address this in a few ways:
- Fundamentally, this is a system that is intended to set the groundwork for auto upgrades. By giving people a way out, we can move forward with opting them in. But the key words here are auto upgrade 🙂
- I am proposing a default of being opted in. You have to choose to opt out of auto upgrades.
- If an upgrade fails, and you have auto upgrade on, it should revert the offending code and await another upgrade so that it can skip the offending upgrade. It should NOT simply stop upgrading.
In effect, this is a framework that can be completely ignored by the consumer. They install WP and install plugins and themes and never even know that this feature exists. Because the upgrades are checking themselves for errors, often when an auto upgrade happens, the consumer won’t even notice. If it fails silently, the consumer can revert that upgrade when they notice the problem and in doing so, they will likely be notifying the developer. The developer will likely be getting lots of these notices and will be quick to fix the problem. As such a small % of consumers are protecting the masses. Most consumers won’t even know there was a dud upgrade because the developer will have been prompted to quickly fix it.
4. Upgrades Might Break My Custom Code
Here’s another scenario:
I am a blogger and I hire a developer to make a custom plugin / theme. Once they’re done, I’m afraid to upgrade other code because it might not work with my aging custom code.
The thing is, the blogger can let the updates role until an update fails or until the blogger happens to notice a bug on the site. In either case, whatever update caused the problem, it will be reverted and the blogger will likely have been notified of this if they didn’t intentionally do it. In the mean time, the blogger can arrange for the developer to take a look and once resolved, the upgrade process will continue again.
If anything, this system offers a way for the blogger to have enough control that there is some chance that they will continue to upgrade whereas the existing system is so terrifying that there is no way that the blogger would attempt upgrades on their own.
Wrap it Up
As I write this I can see a lot of opportunities to expand on the proposed feature set. For the time being, let’s keep it simple and to the point. The goal is to take the stress and maybe even the entire consciousness out of upgrading code. If it upgrades by default and people don’t have to worry about it, then people will surely be more likely to keep up to date.
Cheers from Tybee Island, GA!
Postscript: I’m honored to be writing this from a hotel in Tybee Island, GA at the WordPress Community Summit. I would have liked to have refined this a bit more before publishing, but I found out tonight that “automatic upgrades” will be a large part of tomorrow’s conversation. This topic, possibly this post, and probably all the ensuing conversation really ought to live here: http://make.wordpress.org/plugins/. But for the time being, I am posting it on our blog. I will likely make updates to this post over the next few days.