The fallout over the automatic update of Yoast’s WordPress SEO plugin shows the WordPress community is suffering from a severe case of Developer Goggles.
Yesterday (March 11th, 2015) Joost de Valk released a security update to the popular WordPress SEO plugin, currently running on over 1 million WordPress sites around the world. The release came after a responsible disclosure by Ryan Dewhurst of the WPScan team that detailed a significant and serious vulnerability in the plugin that could allow a hacker direct access to your database.
In the immediate wake of the update several hosting companies specializing in WordPress started either updating hosted sites with the plugin automatically or put in place safeguards to prevent hacker incursions.
A few hours after the initial release the WordPress.org team started rolling out an automatic (“forced”) update to all sites running the plugin. This means if you are using the WordPress SEO plugin you are now running
the latest a secure point-release version whether you updated it manually or not. In other words your WordPress site is safe.
While not entirely unprecedented this is a rare occurrence. Reportedly such automatic plugin updates have happened only about 5 times:
@carlhancock @EricMann @pbaylies @zamoose @ronalfy We've done this only about ~5 times. I'll update the page to reflect exactly how it works
— Andrew Nacin (@nacin) March 12, 2015
Since version 3.7 WordPress itself has automatically updated whenever a security release has been published. There has also been a lot of talk in the community about instigating similar automatic updates for themes and plugins, much of which has been met with strong resistance.
In the wake of the automatic update many WordPress developers and community contributors have voiced concern, anger, even outrage.
The more I think about it, the more infuriating the auto-update of WP SEO gets.
— Ad-less Douglams (@zamoose) March 12, 2015
Nick Haskins summed up much of the concerns quite nicely in his post “On Automatic WordPress Updates“:
An update, is an update, and WordPress automatically updated a 3rd party plugin without my consent.
This constitutes a breach of trust, plain and simple.Nick Haskins
Haskins notes in an update to the post that the wording on the Codex page about automatic updates has been updated to clearly state that “Automatic background updates currently only happen for plugins and themes in special cases (determined by the WordPress.org API response)” and provides an example of how to permanently disable all automatic updates.
However, this Codex update does not diminish the core of the criticism of the update. The reason many developers are upset is that an automatic update of a plugin blurs the line between “self hosted” – as in autonomous – WordPress and “managed” WordPress. Haskins cites examples of plugin updates crashing sites. Others cite examples of plugin updates changing core functionality or behaviors without notice.
All of these are great arguments, but they run counter to an oft overlooked reality of the WordPress community: We, the people who develop and talk about WordPress on a daily basis, are not the typical user. We are the WordPress One Percent. And automatic updates are not for us. They are for everyone else.
Developer Goggles and the Real WordPress User
WordPress development runs on what’s known as the 80/20 principle. In this context it means anything that is done with WordPress core should be of benefit to 80% of the users. It would be hard to argue that a significant security update like the one released for WordPress SEO does not pass this test.
Though I don’t have any numbers I would venture a guess that the vast majority of WordPress users a) never read WordPress news, b) never monitor conversations about WordPress security issues, and c) rarely if ever check to make sure their plugins and themes are up to date. In fact every time there is a new full release of WordPress or major update to a plugin I get hundreds of questions by Twitter, Facebook, and email from regular users about whether it’s “safe” to update. In the real world many WordPress users are deathly afraid of any update and are clinging to ancient installs with out of date themes and plugins because they are worried an update may take their site down. Jeff Chandler posted some telling stats about this in his aforementioned, and strangely prophetic, article about the need for automatic plugin updates.
There are also a large number of WordPress users who have no idea whether a particular plugin is installed. In many cases the plugins are installed by the contractor they hired to build their site, and once the site is built they are left to maintain it. A warning about a security update would go unnoticed by them unless someone called or sent an email, and even then it is not certain that they would know how to or even have access permissions to run the update.
With this in mind it is clear the outrage over the automatic rollout of a significant security update to a popular plugin is one that only makes sense if you wear pretty thick developer goggles. The update is not for the WordPress Literati – it’s for the people we build WordPress for: The blogger, the small business owner, the people around the world who have something to say and want to say it without having to become a professional web developer in the process.
We can talk until the cows come home about whether all plugins and themes should be auto-updated. But the more important conversation we need to have is about how we define the typical WordPress user and how we serve them best. Let’s be honest here: If you are reading this you are in the WordPress 1%. And WordPress, for better or worse, is not really built for you.
26 replies on “Plugins, Automatic Updates, and the Average WordPress User”
If WordPress.org wants to do this for the 99% of WordPress users, that’s fine. Give the 1% a setting to opt out of automatic updates of plugins and themes even in “emergency” situations.
But to blatantly ignore settings on my site is absolutely irresponsible and not something that should ever be done without my consent.
define( ‘AUTOMATIC_UPDATER_DISABLED’, true );
Me too, I’ve got 7 pieces, and the last was pretty tricksy as I’d scanned the pages a couple of times before it hit me!REally good fun! I’m quite excited to search for the final piece!Brilliant way to make us comb through the Cake site!
There are several well-documented ways to opt out of the different kinds of updates (either adding a constant in wp-config.php or using various filters in a must-use plugin). All were widely announced and explained when automatic updates were implemented in version 3.7.
No they weren’t. Plugins were explicitly listed as not being automatically upgraded yet. That functionality was to come future, so many people would have no bothered to block them, since they weren’t possible anyway.
It isn’t that Black or White. I appreciate that WordPress cares for the normal user. But you have to keep in mind that changing files on someone else server is something that should be done very carefully if at all. I think it is a good thing for the normal user. Buy it also needs to be properly documented and transparently handled. Forcing updates when the Codex says something different isn’t ok at all.
I am really unhappy about how this went. But what really needs to be fixed (and already has been thanks to the community) is the Codex so everyone can read the actual facts and make an informed decision.
AFAIK these updates are only for severe security issues and nothing else. In those cases it’ll typically be updates to just a few files and should have no impact on the user experience. It’s similar to a security background update to your regular OS.
I get that. Still. If I choose not to auto update my OS I want my OS to honour that. And my OS should tell me the truth about what choices I have. That is all I’m saying.
Automatic updates of themes is a terribly stupid idea, and no one in their right mind would do such a thing.
That said, WordPress has matured to a point where I believe we should allow automatic updates, but only if the plugin developer “opt’s in.”
Let’s face it, not all plugins are built alike. The quality of coding remains variable, and Theme X may not be compatible with plugin update Y (unless the shop who wrote the plugin are particularly good and thoughtful folks).
So this could call all be brought to a level playing field fairness and transparency wise, if the folks at WordPress.org would add an an option to the repository whereby a given plugin developer “opt’s in” to auto updates. At that point, we would all see the auto update has been “opted in” right there on the plugin page, and expect automatic updates to occur in special circumstances.
I agree on version updates. Security updates on the other hand is a different issue. These security updates would be rolled out by the core team after proper code review and should plug security holes rather than bundle new UX or feature updates.
Outstanding post. One note of correction: it was even more mild that you suggest.
1.5, 1.6, and 1.7 each received point release updates, so that no major version was updated to another major version — nearly eliminating all update failure potential. Everyone is not running the latest version.
Good catch. I will correct immediately. Thanks Brian!
Great read. I was telling my colleagues at work this same argument. Developers are a loud and vocal minority. While I can see both sides, I think the core team did the right thing here.
On a semi-related note, I’ve been working on a plugin that does allow you to enable/disable individual plugin/theme updates. It’s still in the testing phase gearing up for a final release, but you’re welcome to check it out.
It would be hard to argue that a significant security update like the one released for WordPress SEO does not pass this test.
Actually it is very easy to argue against that.
The plugin is running on only around million sites (wp.org data). There are around 80 million WordPress sites in the world, half of them are on WordPress.com. That leaves 40 million wordpress.org sites. Which means that the precedent that was made actually benefitted only roughly 2.5% of WordPress users, not even close to 80%.
So from now is 2.5% site usage enough to trigger a ‘God-intervention’ in case of a security patch? If a plugin is running on 1.2% WordPress sites (half a million) those people are left on their own ? How does one draw the line what is important?
The update is not for the WordPress Literati – it’s for the people we build WordPress for: The blogger, the small business owner, the people around the world who have something to say and want to say it without having to become a professional web developer in the process.
When mailpoet plugin had a security breach that affected 200,000 websites those users were left figure that out on their own. Or recently Fancy box with 100,000 active websites. Is that negligible? What makes users of WordPress SEO special?
In other words your WordPress site is safe.
That’s a pretty bold statement 🙂
Because you are running 25+ plugins (on average) remember? All of them which are plugins that are ‘below the census’ for ‘automatic update’ trigger when they release a security patch.
Plus auto-update has a chance to break a site due to a partial or failed download/unpack/copy (we’ve seen this in practice, some configurations seem to be especially susceptible to this like those running Litespeed). It would be interesting to get data how many of those million sites were broken as a result of the auto-update failing/breaking. We are working on solving this concrete problem, and it is an interesting and difficult problem to solve.
If this is a first step in taking WordPress security to the next level then I am all for it. I think what caused the stir was the fact that it did not appear to be run as a part of priorly communicated strategy but as a random, sudden, unplanned for event. It is certainly good that the community asked questions and would like to have a say in this matter.
@Vladimir, you are answering most of your own questions:
The percentage of WordPress.com to WordPress users is irrelevant in this context. The plugin only runs on self-hosted sites. The benefit is for the 80% of the self-hosted users.
The reason the WordPress SEO plugin is different from the others you listed is that it’s active on well over 1,000,000 (one million) sites. The others are live on only a fraction of those sites.
The statement “your WordPress site is safe” obviously only refers to this particular plugin and its security flaw. You have to read it in the context of the article.
Finally they actually run stats on how many sites break during auto updates. The number is infinitesimally low.
There are 40 million self-hosted sites. Which makes this plugin relevant to only 2.5% of those. Not even close to 80%.
Do you have a link/reference to those stats (for sites broken during auto-update?)
“There are 40 million self-hosted sites.” of which 100% could run the plugin. This is a question of security updates as a whole. You know as well as I do that one of the biggest problems facing the WordPress community is outdated versions of WordPress and outdated versions of insecure plugins. The debate here is whether security patches should be pushed out en-masse. This would benefit 80% of the users in my opinion. The WordPress SEO example is just the most extreme example.
I, for one, appreciate these security (only) updates. Most of the plugins I use have an explanation of the changes in a link with the update notice. I often don’t understand the technical reasons, but they seem to be rational so I update. I am glad that WP developers theme designers, and other experts are looking over my shoulder.
I count myself as one of the wp 99 per-centers. With my skill level it was easier to take an existing gpl theme and run a search and replace on all the files to alter original_theme_name to my_theme_name rather than figure out how to mess about creating a child theme.
(I know you have a couple of courses on this Mor10, but Creating a Child theme is wp 3.0 and @import is deprecated. And WordPress Developer Tips: Enqueuing Styles and Scripts does not address adding modified functions.php and footer.php to a child theme pkg. )
After spending a lot of time carefully perfecting the css on a new site, I wanted to protect the theme files from any future upgrade request. My solution may be unorthodox but it worked.
I run the WordFence security plugin. It sent me a notification last week on the Yoast vulnerability. I went to the site this morning to update and found it had already been taken care of. Spent an hour or more trying to determine what had happened and finally wound up here.
I spent 12 years as a support engineer with one of the largest IT firms. We always knew when MSFT had delivered a security roll-up as the call volume went through the roof. Server farms round the world called to complain everything was now broken. And those calls came from informed and knowledgeable admins. The 1% of the server world.
If Automattic delivers an involuntary update and it breaks an e-commerce site that is running at a high dollar volume then Automattic may be liable for the breakage. Looking at the success of woo-commerce, it is likely that there would be grounds for a class action suit from thousands of small e-commerce operations.
Am unable to make a positive recommendation. But anyone intruding on someone else’s property and livelihood without their permission is likely in for a world of hurt.
Just semantics, but Automattic had nothing to do with the auto-update.
Just to your comment about the Child Themes course, the new method for adding parent theme stylesheets is problematic. See . This has yet to be resolved in a consistent way so it’s hard to update the course without adding a myriad of conditions and “except in certain themes where this doesn’t work” etc. Currently there are no fully functional solutions.
Currently there are no fully functional solutions.
As one of the 99% I have been trying to puzzle this out and thought it was just me being incompetent. My workaround does work. In fact the readme file on _s actually suggests this approach when using _s as the base for a new theme.
Your course on wp and assistive technologies was great. Please consider doing a follow up and / or doing one on how to perform a translation and include translated files in the theme.
Many of the comments above are missing the crux of the issue. The issue is not over whether automatic updates are a good idea or not, the issue is over us being told one thing, when the truth was the opposite.
Plugin updates were opt-out, whereas the documentation (including the blog post some believe says otherwise) all say that plugin updates are opt-in.
It’s not the updates which are bad, it’s the fact that we weren’t informed this could happen which is bad. If people had known it could occur, some would have taken steps to deal with it, and wouldn’t have been caught scratching their heads wondering what caused files in the plugins directory to change.
Let’s be honest here: If you are reading this you are in the WordPress 1%.
Rather, I would argue that the WordPress 1% are extremely knowledgeable individuals, while anyone trying to learn about WordPress can (and will) seek out sources of information such as this one.
This isn’t the only place I’ve seen an opinion such as this one being expressed, and it’s problematic. You’re probably right that the issue is caused by developer goggles. It seems that developers think in dichotomies — apparently, there are only developers and beginners. Where’s the middle ground?
I rarely see WordPress-related content targeted towards intermediate users specifically — not in the same sense that this article targets developers. So, those who aren’t part of the WordPress 1% are still accessing resources meant for the 1%, because it seems the rest of the resources are meant for the 99%.
But that 99% figure is completely invalid in the WordPress world. How can all levels of knowledge except “expert” be lumped together into one group, and still be served well?
Looking forward to your response!
I think you misunderstood my point Julie. The uproar about the automatic security update of a popular plugin came from the 1% – the people who see WordPress as their own personal platform that nobody should mess with. The arguments brought forward were largely based on issues only extremely advanced users would ever encounter, usually because they have made massive modifications to their site that might cause problems. For the vast majority of WordPress users – and especially users of the plugin in question – the automatic update likely saved them from a potential massive security breach. And had the update not been automatically pushed they would likely never update.
As for content targeting intermediate users specifically, most of my content is of that type. I focus mainly on building a steady ramp from beginner to advanced and try to fill in the gaps.
Oops — missed replying to you somehow. Can we blame the holiday weekend that just passed? 😉
Indeed, I didn’t misunderstand your point — my comment was meant to be taken more generally, not specifically in regards to the auto-updates issue. What I’m trying to get at is that there are people who are not beginners who are reading more advanced materials such as this one in order to learn and improve. These people don’t fit in the 99% nor the 1% — because neither exist. There’s a middle ground that’s not being addressed at all. And I’m talking specifically about this kind of informational article, not tutorials and how-to articles.
(BTW, a few of your how-to/tutorial articles have already helped me out a lot, so thanks very much, and keep up the great work!)
You see, the reason I started following this type of WordPress news was to help me learn and to help me stay on top of things when new versions come out, so they wouldn’t throw me for a loop so much. Smart move! (And there have been other benefits.) But these articles all assume I’m not part of the target audience. And yet, I’m sure I’m hardly unique.
As an aside, I’d like to posit that one of the reasons discussions tend to revolve around the 1% vs. 99% idea is that there is no clear way to define skill levels in WordPress. In truth, there is a whole spectrum of skill levels, but they’re not easy to identify within any well-known paradigm. I see it as a problem on par with the challenges of naming WordPress job titles.
Thanks for taking the time to read my comments. Cheers!