WordPress 4.2.3, a critical security release, was automatically pushed out to users yesterday to fix an XSS vulnerability. Shortly afterwards, the WordPress.org support forums were flooded with reports of websites broken by the update.

Roughly eight hours later Robert Chapin (@miqrogroove) published a post to the Make.WordPress.org/Core blog, detailing changes to the Shortcode API that were included in the release. According to Chapin, these changes were necessary as part of the security fix:

Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

The security team had no reasonable way of accounting for every single edge case, but the negative impact of these changes were far more wide-reaching than they had anticipated. This particular use case likely wasn’t covered in their testing. Unfortunately, plugin developers found out about the breaking changes only after the security release had already left a slew of broken websites in its wake.

“I fully understand this is an issue, but isn’t this a weird way of updating – almost all our clients are calling / e-mailing us at the moment as their sites seem to be broken,” one developer commented on the Shortcode API post. “Normally it would be better to announce such huge impact changes to the plugin and theme developers. This means I need to fully reschedule my agenda, which already is full during holiday season.”

Comments on the WordPress.org post are full of developers scrambling to find a way to fix client websites. Many were disappointed that the total secrecy of the security team, which is necessary in situations like this, was not immediately followed up with a public post on the important changes to the Shortcode API. Meanwhile, the email inboxes of agencies and plugin developers are filling up with urgent messages from outraged clients.

We are updating the Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

This is a straightforward change, which takes us one day to complete.

Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

What others have asked here, and I would like to ask, too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

We are your partners.

Without WordPress (secure, stable and reliable), we would not exist.

Without great themes and plugins, WordPress would not power 24% of the Web.

WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

User confidence in WordPress’ automatic background updates took a dent with the 4.2.3 release. Waking up to broken websites causes users to second guess automatic updates after being assured that maintenance and security releases would not include breaking changes.

When users get burned by automatic updates, in the end it doesn’t matter which party is at fault – whether it’s the core team or a theme or plugin. They simply expect updates to work and not break anything. Even in instances where a poorly coded extension may be at fault, the average user has no way of determining whether or not their active plugins follow WordPress best practices.

The aftermath of the most recent security release is one reason why many developers and users are still wary of automatic updates. Amir Helzer represents many other plugin developers who are eager to find better ways to work together with the core team to provide a better update experience for users. This is especially important for releases like this one where the Shortcode API changes directly affected users’ content. Hezler’s comment reaffirms the fact that development agencies, plugin developers, and core developers are all partners on the same team. It’s time to find better ways of working together to provide the best update experience possible for WordPress users.

Well, this is not a solution. Security Updates are automatic exactly because of their nature. You will have (eventually) broken sites after peoples (bad ones) recognize you didn’t update your sites. Also, #JustSayin’

Not having automatic updates does not mean that the developer is not updating it themselves. I personally would rather test the theme and plugins on an updated version of WP locally or in a staging environment (or both) before going live.

@george realistically, how many sites are gonna get hacked zero day? For 90% of us the chances are nil. So using BS scare tactics to suggest that You Will Get Hacked if you disable updates is why people are learning NOT to trust WordPress.

How many plugin authors are there? How far in advance should they be informed? Outside big security issues (like this one is), how long should WordPress allow for plugin authors to update their plugins?

What about plugins that have not been updated for over a year? How many of the plugin authors are active still?

Obviously there should be some communication but releases go through Alpha and Beta release stages. Can’t plugin authors download 4.3 Alpha/Beta/etc…and test their plugins?

I know when A/B releases come out, I am subscribed to more than 50 WordPress releases, RSS subscription boxes from WordPress developers and Twitter accounts.

That last part does not apply to extreme urgent security releases (4.2.3).

I agree there needs to be a standard and there are a lot of plugins that are outdated. However, as pointed out in the post, a lot of plugin developers who are very active and willing to help are out of the loop.

Sure, 4.3 Alpha/Beta/etc… can be tested. However, I would suspect the security release wasn’t part of the current Beta for testing, or was it? Curious since you brought that up and that would seem to be outside the scope of this particular situation. Or would it be?

For planned releases we all have that option to test. I get notices about upcoming releases and I test them for my own uses. I don’t have issues because I do manually back things up. I prefer being allowed to back up my sites and those I manage prior to updating. Just a habit I have picked up over the years.

I was basically told I didn’t belong in the discussion because I wasn’t a core contributor. Guess things do come back to bite you in the butt when you show your arrogance. Oh, yeah, got bozo-ed for that for a long time. LOL

Like I told them back then, it only takes one time things failing to prove my point.

I knew the comment was going to sound abrupt, as I noted right off the bat, and it still reads as being abrupt even to me. I think the threading limit makes it seem rude and/lacking context – I believe I was addressing the suggestion directly above from AITpro about creating a separate post for “non-developers”, which wouldn’t really fit with a developer-facing blog. Not that it couldn’t be worth having somewhere else (like here!), just not on that particular site. I don’t know enough about either of you personally to be judging your skill set :)

Interesting contribution to both that discussion and this one. Now, who exactly were you addressing as not being developers or it being a developer topic? The topic was exactly about removing the automatic updates. And that was what was being discussed. And was being discussed by people who have had ample experience, you just didn’t know that.

I have a suggestion for you. Try to consider when you know you are going to sound “abrupt” whether or not you really need to post it.

Maybe that is something you could work on, being one of the core people involved. Just a suggestion. I hope you take it that way.

As has been pointed out by @mac2net further down, maybe you should consider more and be defensive less.

It’s not about defense, this is genuinely a reflection which led to some very late clarification. My comment does not read well now as a static entity outside of the flow of discussion, and I can certainly see how it would seem to be addressing you and assuming things about your experience. It really was directly in reply to the comment above mine, which says “What about creating a new topic for non-developer questions and concerns, move all non-developer questions to that topic.”. To answer your question about who/what I was addressing, I did not have any particular individuals or topics in mind, only that the “Make WordPress Core” blog itself would likely serve as a poor venue for questions/concerns from whomever would be considered a “non-developer” in that context.

Actually, if we were to look at the thread now and pay attention to the times, your response seems to have been edited after the initial statement. So, really the context can’t be fully understood now. The thread was direct, inline and your time changed to significantly after my post below it. So, let’s get past that. I pointed the conversation out for a different purpose anyway.

The point really at the time and now is just how little those of you in the “core” team listen to those who are trying to contribute. If you want your own special section where only you can contribute then make a section where only you can see the conversations and only you can contribute.

The longer the type of attitude you exhibited there along with your other team member(s) continues, the more separated you will become from what is supposed to be the community. We were talking about the very thing that has happened which resulted in this thread and others. It’s all related. And it could have been potentially avoided had someone been willing to back off and consider for a moment or two the impact “IF” things don’t go the way everyone expects. I tried to point that out back then.

People keep speaking up (you can see it in this thread). They are trying to tell you something. And all you want to do is focus on a statement you made that someone said was rude.

That’s the problem. And that is the point of my posts. I tried to help avoid this embarrassment being suffered by the WordPress “team”. But, as egos go, there are some big ones in that “team” and the more someone tries to point something out, the more stubborn they become. The last few weeks in the “community” has shown the results. People are really fed up with being dismissed as though they aren’t qualified to discuss things with you people over there. That conversation and your statement is only one example. And that is almost two years ago now.

Consider this:
The WordPress team is adopting plugins into core more and more. How hard (aside from someone having to set their ego across the room somewhere) would it be to add the option in general settings to turn automatic updates on? I realize that’s not going to happen without a fight, but really, why does it need to be a fight.

This topic shouldn’t have to be repeated. And as long as you don’t offer that option, it will eventually be repeated. Not everyone can find a plugin to turn off automatic updates though there are a few of them available. But they can find the option in the general settings.

The sales pitch was made. The opposition to having automatic updates was silenced (and there was opposition). Everyone on the “team” got on board and the fantasy ride began. Now, reality has hit, there are situations where your automatic updates can do serious damage to sites in large numbers. All because you have set the software to update automatically by default. And as all you core people like to say, many people don’t know what to do when all hell breaks loose and their site is no longer working. Then core people blame plugins.

Your people check plugins to make sure they comply with WordPress standards, so who is to blame? The plugins affected, many are well known and popular.

There really isn’t a defense against what happened. It shouldn’t have happened. That’s the point now and that was my point back then. And it will be my point when it happens again. And it will happen again if things remain the same.

I hadn’t noticed the timestamp discrepancy – it is worth noting, but not because it indicates that it was edited (editing a comment doesn’t change the timestamp), but because it shows that it’s a reply to the comment above since your comment shown below has an earlier timestamp. But, now that is leaning toward me being defensive :)

If your position is that I can’t address somebody understandably reading an old comment of mine as being dismissive of you personally and calling it rude without also having to opine on what’s happening with this update, then I’ll respectfully decline to engage further. However, I am listening, and would ask that both of you do the same for me and stop characterizing that particular comment as proof that you were told you don’t belong. It pains me that so many people feel that they’re talking to a wall or being dismissed outright, and all the more because I feel exactly the same way. Again, I absolutely understand how it came across that way and will be more mindful of being specific and contextual in replies going forward, but if I’m not also given the chance to explain and be acknowledged on this one small thing, how can I trust that talking about another issue would be listened to?

It’s interesting when you begin to experience what others have been feeling for a while, isn’t it?

Time will tell for all.

Again, stop defending yourself. I included a lot in my response that has to do with the issue at hand. But you only want to focus on your statement(s). That’s what I mean by you being defensive. You don’t need to defend yourself. You need to address the issue of automatic updates.

It can be really disabling to a developer’s workflow when a non-developer brings up use cases that have already been covered in depth. You are creating more work for developers, who are infinitely more aware than you of the complexities of something like a software security vulnerability. I find this kind of nitpicking by non-developers to be really detrimental in the context of SERIOUS security vulnerabilities, especially when it’s focused on female core contributors.

We’re all working towards one common goal: better, faster WordPress installations. Let’s try to always contribute constructively, and not destructively.

Yeah, only been working with computers since 1977 (USAF) programming, communications side.. Hadn’t learned much by the time I had that conversation.. LOL

I wouldn’t know anything about what a developer is aware of. Neither would the other person who was involved in the conversation. Right?

And I agree totally about “nitpicking”.

Now, I ask the question, “Who exactly are you referring to?”

Because I haven’t been involved with previous conversations doesn’t mean I am unaware of what is involved or what the security implications are. So, I fail to understand how your comment actually applies to that specific conversation.

Generally speaking, if someone who has no experience in programming or web development attempts to enter a conversation where developers are attempting to discuss a project I might agree. But, I believe those conversations are held on a more controlled platform or in a more appropriate setting.

However, the conversation was on a public platform regarding a post made by the developer and general discussion was invited and the topic did not state that only WordPress core contributors can enter the conversation. I think context needs to be applied there.

And just because you don’t know the person’s background does not mean the person isn’t qualified to have the discussion with you if you are a developer. If you have questions regarding the qualifications of a person, ask. Don’t presume the person isn’t qualified to speak with you.

This is a case, I think, where WordPress’s arrogance got the better of them, and has undone plenty of good will that has been created.

Automatic updates are perhaps the ultimate in fixing security issues, but also the ultimate in “bite you in the ass” stuff. This week, they got their asses bitten solidly with a security update that was more than a little over the line.

First off, the security update didn’t apply to the literally millions of wordpress sites that do not allow people to sign up / log in. If the user was not logged in (at least as a subscriber) than they couldn’t do anything anyway. Many corporate websites, personal blogs, and the like don’t allow signups, don’t even allow comments. For them this pressing security update brought them nothing but potential problems.

Moreover, having 20 bug fixes in the update is also a bad idea, as the risk that one or more than accidentally hurts something is high. If you are doing a security update, then fix security – and stop there.

This event makes me remember exactly why I don’t use automatic updates. Looking forward to wordpress 4.2.4, which I suspect will be out shortly to fix all of this mess.

> First off, the security update didn’t apply to the literally millions of wordpress sites that do not allow people to sign up / log in. If the user was not logged in (at least as a subscriber) than they couldn’t do anything anyway.

And you know this how? There were many security updates in that release, not just 1. Even with 1 user, no comments, and no registration, there was still stuff for those websites.

Moreover, point releases, which are autopushed, are for bugfixes and security fixes. The bugs included in the point release weren’t pulled out of thin air, they were designated for this release and were in 4.2’s trunk or via a patch for anyone to test (in some cases for several months).

As for 4.2.4, the only thing being fixed in it so far will be CDATA and do_shortcode issues

Chris, part of the problem here is that (a) secuirty patches and bug releases should never be made in the same update, we should never be forced to choose between unwanted “improvements and running changes” and fixing a security hole, and (b) that the security hole being work on is one that is very commonly used by developers because wordpress is not very strict in that area. It’s a real problem of having a sort of slack approach to API, function calls, and code calling that allows developers a little too much freedom to roll their own and cause big issues.

“There were many security updates in that release, not just 1.”

My understanding (from all the hype and what was released) was that this was addressing the singular issue related to situations with logged in users only, IE none of it was relevant if you do not allow users to sign up. XSS or other issues that require a minimum of a certain level of login would not apply to sites that do not allow anyone except that administrator to log in.

That was my take away from the official release. If the situation is different, perhaps it should have been stated in a more clear fashion. I have refrained from updating sites as a result of all of the problems that seem to be cropping up,and that the noted issue doesn’t appear to apply to any sites I own, operate, or maintain for others.

And all of those named have the option “built in” for the user to choose to turn those automatic updates off. In fact, they usually have at least three options:
Allow download and update automatically,
Allow download and you choose when to update,
and notify you of the update and you decide when (or if) to download and perform the update.

Browsers do it as well as all of their plugins and addons. Users should always have the option by default to choose to turn on or off automatic updates. It’s just plain arrogance, ignorance and childish stubbornness to believe that automatic updates should be forced upon users.

But as they said to me, you can install a plugin to do that. Well, there shouldn’t be a need for a plugin for something like that. If you have the option to “discourage” search engines, you should have the option to stop WordPress from automatically updating your site without doing a backup first, IMHO (and that just comes from my limited experience).

Every one of the pieces of software I have used over the years has had a vulnerability and bug in it at some point. And many operating systems have major vulnerabilities which become public knowledge before most people update their systems. That also goes with the territory. But not one of those MAJOR players sits back and says their users are too stupid to make such technically difficult decisions. Only WordPress has been that arrogant.

For WordPress, there should be the default “OPT OUT” and allow people to choose to “OPT IN”. Kind of like what WordPress requires of theme and plugin developers with regard to branding their work. Default to “OFF”. That’s my rant.. LOL

Ahh… Actually, that’s the issue. Most core developers and contributors believe that most people are too stupid to be able to handle editing the wp-config.php file. And working from that belief, it makes more sense to allow people to turn automatic updates “on” rather than having to find a plugin or editing the wp-config.php file so that they can turn them “off”.

and how many of those are open sourced? community driven projects with values such as:

“I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.”

It is truly a sad day when we compare wordpress with companies you listed.

*sigh* Things just seem to be getting worse and worse in the WordPress world. I feel like we need some real leadership here, not just the core dev team acting like politicians and repeating talking points so they can ignoring the real issues.

Just to voice the counter point: For the average WordPress user (the 99% who do not read this blog) such updates are necessary to avoid millions or sites being potentially vulnerable. Yes, it may break plugins, but the alternative is way worse.

In the end the priority of WordPress should be to the majority of users, and the majority of users are not developers like us.

Transparency is key here, and rapid resolution of plugin conflicts is important, but there is also a question of why plugins break. For the most part WP updates are backwards compatible which begs the question if plugins that break during updates are following WP standards. I’m not saying they are or are not, just asking the question that should be on everyone’s minds.

It’s 99% now is it? I think you might want to reconsider that percentage. Plugins wouldn’t be at 39,098 in the Repository alone with 985,842,389 total downloads if that percentage were anywhere near correct. Yes, I agree with transparency. Distortions make things rather difficult in that regard.

What those numbers tell me is, there are a lot more than one percent of users interested in having options, not WordPress making their decisions for them.

You’re misunderstanding what I said. I said “the 99% who do not read this blog” as in the 99% of WordPress users who just want WordPress to work without being hacked. The judgement the people who make these decisions has to make is whether leaving millions of sites vulnerable to save a far lower number from crashing due to plugin conflicts is worth it. If we use the 80/20 rule here it is hard to argue that specific plugin conflicts should warrant updates being delayed.

Personally, my concern with allowing users to block auto-updates is that they’ll read opinion pieces on the web and turn auto-updates off because they think they will break their site. In that case we make the web a far more dangerous place to protect the elite who know everything there is to know about how to keep WordPress secure. It’s a question of who the target audience is, and for better or worse the target audience is bloggers and site owners who use WordPress as a publishing tool.

I think the fear is that developers and people with a lot of knowledge will recommend users to turn auto updates off. If that happens, we’ll end up with the situation we had before – hundreds of thousands of old sites that are not updated and end up getting hacked. I still come across sites running 3.2 at least once a month. Most of these users have no idea they need to update and are shocked to discover their sites are hacked.

It’s very much a question of philosophy – what is the role of WordPress itself. The dividing line splits between WordPress being a tool for the pros and WordPress being a tool for everyone. Enabling auto-updates by default is a move to help everyone. Providing a ‘disable’ button is a tool for the pros.

The dividing line splits between WordPress being a tool for the pros and WordPress being a tool for everyone. Enabling auto-updates by default is a move to help everyone. Providing a ‘disable’ button is a tool for the pros.

So, making this particular “decision not option” only serves to perpetuate the myth that WordPress is intended for, and only suited for, blogging/bloggers.

I realize that I disagree with the general philosophy of core developers on this point, but I firmly believe that WordPress should not be able to do anything to change a user’s site, in its currently installed state, without the user having some way of opting in/out of those changes. Free Software Philosophy includes the user’s right to use software for his own purposes, regardless of the desires or purposes of the developer. The option to configure automatic updates should be in core, rather than being left to Plugins (including the one I maintain for exactly that purpose).

I think the error is those who believe “Most” people don’t have a clue. Something many of those sharing your view is that there is most likely a host involved. And if there is something happening with a site which puts the hosting in danger, that host is going to take action.

Given you are presuming people who have no clue, you aren’t talking about people who would have anything other than shared hosting. So, the your argument is diluted by the fact that most hosts are aware of the lack of expertise many of their shared hosting account holders have.

The argument doesn’t hold up to reality. Sorry. Automatic updates should be set to off by default allowing those who don’t want to bother to changing it. Or are you presuming that the people you are talking about don’t even know how to set up WordPress? And if that is so, then why are you even thinking about them?

How far down the road of ignorant and unqualified to you take your view of the “majority” of WordPress users?

WordPress has always been the tool for blogging (or CMS oriented websites) but because it’s open source, the people veered it in almost any directions.

“Free Software Philosophy includes the user’s right to use software for his own purposes, regardless of the desires or purposes of the developer”

It is indeed a free software, but it was made initially for a specific purpose and is going to continue to adhere to that purpose while delivering compatibility methods for whatever ‘personal’ purposes/desires its users/developers have.

The flaw in your logic from a practical point of view is that you ore anyone else should be making the decisions for the 99%.

The flaw in the logic of WordPress philosophy is that the majority aren’t qualified to make their own decisions, especially when the decisions WordPress are making violate the very thing WordPress has been telling people for years (and still tells them when they have automatic updates turned off): “always back up your site before doing an update”.

The rationale used for forcing automatic updates cannot reside in the same logic for advising backups be performed when doing manual updates but not when doing automatic updates. There is a reason backups should always be performed before an update. And that reason isn’t (and cannot be) negated by WordPress doing updates instead of a user or their help.

This update is a prime example of why that rationale doesn’t work.

Therefore, there should always be the option to turn automatic updates “on” NOT “off”.

There should be the warning that turning automatic updates “on” can break the site when an automatic update is performed, and that there are no automatic backups performed when automatic updates happen. So, if something happens to your site resulting from an automatic update, you will not have a backup to restore from.

And from a legal point of view, there should be a disclaimer involved with these automatic updates because of the potential for loss of data and functionality of the site and potentially the loss of revenue. Maybe that should be looked at a little more carefully.

Making decisions for others does and should have responsibilities which come with making those decisions.

Whether you are in favor of automatic updates or not, the logic doesn’t work. There is ALWAYS the possibility of a broken site. Updates do that sometimes regardless whether it is a website or any other piece of software.

Therefore there should never be the default setting for automatic updates to be “on”. The user should always have that option.

1) See my above response so I don’t clutter the comments with repetition.
2) Auto updates are not uncommon nor legally problematic. Windows, MacOS, iOS, Android, Linux, all OSes run auto updates and strongly recommend the user to leave them on. AFAIK Windows asks the user on first install if they want auto-updates while MacOS does not. Adobe CC auto-updates constantly. So does Chrome, Firefox, Opera, and other software. There is precedent here. It’s just new to our community.

FWIW I’m not saying I should be the boss of (nor have any say in) what happens. All I’m saying is WordPress as a community needs to cater to all users, not just the ones with advanced knowledge of how to do things.

The error being made is the presumption that the majority will take down the internet if WordPress doesn’t automatically update by default.

The problem arises with a dual rationale. On one end we have WordPress telling people they should always back up their site before an update. On the other end, we have WordPress telling those of us smart enough to know the difference (which there are more of than you give credit), that WordPress can do the updates without needing to have a backup. And therefore, you don’t have to know the difference.

It’s a stupid rationale to presume the majority are stupid and/or ignorant to begin with.

To your point CG, allowing devs more room to configure only makes sense. The product is evolving (along with the market) from blog-in-a-can to something less vertical (read: usage of core is getting less and less predictable). One size does not fit all. It’s a shame we have to fight about what is already painfully obvious.

Change management – it got the better of the NYSE a few weeks ago.
I apologise if this is what’s already happening, but I suggest that any and all emergency security updates be accompanied by a blast to an email list to which anyone can subscribe and perhaps a tweet.
This should be a mandatory part of the process. The update does NOT go out until the followup communication is ready.
One more thing – when these things happen, WordPress people should stop getting defensive or rationalising actions or positions. This only further inflames folks who have been unexpectedly stressed. Remember you knew what was happening but they didn’t. There is always time for post-mortem analysis later.

There are 2 issues here that should be keep separate:
1. Policy about whether the auto-update process should be opt-in or out and whether a setting should be exposed to control this. I think the core team should recognise that experience so far with forced opt-in with no setting has failed and the policy needs to be reconsidered.
2. Change management. I used to participate in a weekly change meeting for a global corporate consultancy. While these meetings were important they were often easily concluded in way less than 30 minutes because once we became educated on the process – even though at issue were mission critical services – it was easiest to come to the discussion fully prepared.
a. What’s changing
b. What are the risks
c. What is the impact to others
d. What is the rollback
e. What is being communicated and when

If you have the kind of WordPress site where you prefer not to have automatic updates, then you probably don’t want the web server able to modify ALL the WordPress PHP files, etc. If WordPress PHP files aren’t web server writable you don’t get automatic updates. What you get is a mail saying you need to update. That way you can have automatic update on test servers and then manually update production ones.

It seems that something I assumed to be a Cardinal Rule was violated with this update: minor releases do not change APIs. Maybe that’s less of a Cardinal Rule than I thought, or this XSS vulnerability is such an exceedingly great risk that the rule was violated. I find the latter hard to believe, but I defer to those who know security far better than I do.

From an end user perspective, having a site being taken down due to a fatal error caused by an interventionless update represents far more risk (likelihood of occurrence, severity) than the XSS vulnerability being addressed by the API change.

Perhaps the real solution is to implement in core an update routine that tests the update against the site’s current configuration (core, theme, active plugins). If there are fatal errors, the update is not applied, and the updater sends a critical failure email, listing the theme/active plugins preventing the update.

The shortcodes API, prior to this week had very little documentation in regards to the boundries of what it was designed or intended to do. During the course of fixing one of the 22 addressed issues with 4.2.3, the determination was made that it would be better to break a very obscure functionality that affected a couple plugins out of well over 40,000 plugins on the repository. The risk with the specific vulnerability was more than justifiable to do so.

If the breakage impact was known to be limited to only a “couple of plugins”, what would it have hurt to give the developers of those couple plugins even a day’s notice of the breakage, before rolling out a breaking change to an insufficiently documented API?

Chris, I keep reading you talking about “obscure functionality”, and I do wonder if you really think that using shortcodes as HTML attribute values is actually obscure or you are just trying to state we should consider so after the fact that a sudden API change states so.

To my knowledge, that was not only a clear functionality, but this update has lroven that it was one thing done by thousands of site owners and content creators.

As I have said a couple of times, throwing the word “security” in the table does not entitle someone to say others are doing things wrong. When a *major* API change is introduced less than 30 hours before being released and forced over 5 backward branches, maybe one should not try to add arrogance to the equation.

Just saying.

I will not start the right debate I also think we should be having about backwards compatibility and platform trust. We will get there soon, I think, judging by the latest movements around the community. Or, in the worst case, by the users movement in a sense noone around will like.

@chris what if it only affected 1 plugin… But that plugin was Jetpack that is used by hundreds of thousands (if not millions) of web sites. Doesn’t matter if it was small number of effected plugins, the fact is that it was a “small number of popular plugins” like WooCommerce that broke tens of thousands of web sites.

And yes, BROKE is the correct term. If a web site no longer functions as intended, then it’s broken.

Now, what was truly obscure was the security vulnerability itself. It was very obscure and could ONLY be exploited by someone who ALREADY had access to the site. If you did not have access to a site, this vulnerability could not be used to GAIN access to a site. The chance of a web site getting hacked is next to nil. So yes, I question the need to break WordPress in this instance.

That aside, for me, the real issue is the lack of communication. Once the update was released, the cat was out of the bag. A VERY PUBLIC posting about the consequences should have been made once the update was rolled out, not 8 hours later.

I do not consider “shortcodes stopped parsing” as broken. Annoyance? Yes. Preferably avoidable? Yes. But not my website stopped working.

I do think that the API change could have been communicated to the few Plugin developers impacted, but it appears that I wrongly assumed, based on how this whole thing has been reported/described, that there was actual website breakage. #WPDrama strikes again?

The option to choose auto-updates or not (with a simple rollback feature if something goes wrong) should be standard. It’s decisions like this, and issues that I’ve seen in the last few weeks and months, that seriously make me consider leaving WordPress.

We see a case of somebody else answering the question whether you’d rather have an insecure site or a crashed site, for you. In reality we have been living with this dangerous security issue at least since May 7th, day when 4.2.2 was released, so for over two and a half months. And the community argues that they would rather have an ‘insecure’ site for one more day until they can make a more informed decision about the update. Key is that whether this is ‘sane’ or not should not be ours to decide for others. It depends on so many factors that we can not foresee – it can be more costly for a business website to be down for hours or days then the risk that it will be actually targeted by a hacker discovering an exploit.

When your Windows, or iOS, or Chrome updates and causes a crash on your setup, it would only break the experience for one user – you. If a WordPress website crashed after update, it breaks the experience and economy for thousands of users that are visiting it. Even after 25 years, Linux still does not automatically update, and we still need to go in and manually apply every Linux patch. Probably because otherwise millions of websites around the world would crash every day.

The decision how to update their website should always be site owners’ or maintainers’ to make. A simple preference setting in WordPress general options about the way automatic updates are applied should be a no-brainer (we should actually be debating nowadays the default setting for that option).

Saying things like those without really listening to counter-arguments does indeed make the community and project leadership more disconnected. Whom does that favor?

Making decisions for users without listening to them is not wrong, it is just a practice found in closed platforms. An open source project like WordPress should be thankful for having a vocal community, genuinly interested in the success of the platform. Cherish it the best you can. Specially when this vocal community, mostly referred to as ‘developers’, even if they represented just 0.001% of the userbase, are the major source of WordPress growth and adoption. Why would you ever risk ignoring or evenn worse frustrating them?

Core should not have an option to disable security updates, for the reasons Nacin gives in the linked comment. Security is priority number one. Backwards compatibility is priority number two.

In WordPress you have almost every thinkable freedom. The more you know and are able to install or to program, the greater is the freedom. Such a option in core will make users who have never heard of XSS or know the possible worldwide disastrous implications of vulnerabilities in WordPress to be faced with a dilemma, to enable or disable automatic updates. One who makes the wrong decision may put their site at risk, thousands who make the wrong decision may make WordPress look bad and insecure, millions who make the wrong decision may set the www at risk.

Automatic background updates for security releases is the single most important feature that has come to WordPress in recent years.

You will never get the silly option in core. If you don’t want automatic updates install the damn plugin, or add the damn constant, to disable it and move forward at your own risk.

We, just as many, also “genuinly interested in the success of the platform”, support this decision. We also have a voice. Stop this silly complaining about not being heard. Your arguments may be weak.

I’m not saying any hook should be removed. I tell people to install a plugin that relies on such hooks, if they want to disable this. I disable updates myself, for some time, on some sites. So I obviously don’t want to take away the ability to disable auto updates, or even suggest such. I’m only talking about a user facing option in core, which was the topic I was commenting on.

so you think that site owner who is not a developer should not be trusted to manage their own site because they are too stupid to understand the importance of security update when they get email notification that security update available so wp should take this responsibility for them?

or maybe you think site owner are too lazy to able manage their own sites ?

or you think an update option is not important enough to be added as core option? and site icon in wp 4.3 is more important than that?

Wow! When I think of arrogant pricks from now on I’ll think of you Knut.

I”m not a developer – simply a business owner that looks after his own WP installations.

It’s MY site – NOT yours. Don’t pretend you have the right to control what happens on MY site. You don’t and you never will (I literally just installed a plugin to turn off automatic updates).

If you want control then turn WP into a proprietary, non-open source system and you can have all the control you want. I can assure you at that moment I’ll be migrating my site to something else – even Joomla if i was desperate.

WP is NOT the only game in town. If WP disappeared tomorrow I wouldn’t shed a single tear and my life and my business would carry on. Clearly the core team has no concept of that.

Screw up another auto update (especially one that affects all WP users) and you’ll find out how quickly your market share can disintegrate. In fact I truly hope it happens.

I agree, referring to body parts that nobody really has control over is just wrong. “Arrogant” is justified.

When someone makes statements like “Security is priority number one. Backwards compatibility is priority number two.”, that defies any real logic.

So, we maintain backward compatibility with less secure versions of server software but we MUST allow WordPress to automatically update for “Security” reasons. Where does that logic come from?

Again, the logic fails.

If you are all worried about security, then require the more secure versions of the software which WordPress depends upon to run and then talk to me about “REQUIRING” automatic updates for WordPress for “security reasons”.

“If you are all worried about security, then require the more secure versions of the software which WordPress depends upon to run and then talk to me about “REQUIRING” automatic updates for WordPress for “security reasons”.”

Using the ‘correct’ quotes in shortcodes is not as trivial as it sounds. The description in the ‘make’ blog over-simplifies it and leads to wrong conclusions.

When some piece of code generates a shortcode, how can that code know where YOU are going to insert it?

The reason why you see Toolset plugins starring in this episode is because our support team was very active and started handling this issue within minutes of it happening. We immediately explained to our clients that this sudden breakage is due to this recent change in the WordPress shortcodes API. This is why you see so many Toolset clients here.

Hold on and you will see plenty of other people who report related problems. It will take a little time for people to make the connection between broken content and API changes, but this will happen.

Almost every WordPress theme and plugin today uses shortcodes. This is the glue that lets end-users integrate between the theme and different plugins.

A theme defines shortcodes and a plugin defines shortcodes. It’s the user that connects them together by putting one shortcode as the argument of another. Up until now, it was an excellent way for non-programmers to achieve complex functionality.

So, the ‘fault’ that’s described in this update is actually in the content of sites. This API update requires end-users to update the content in their sites and use the existing shortcodes in new ways (more limited).

Changes to an API will always break something. This time, it was a change to the shortcodes API. Next time, an update may change the REST API. So, you can expect mobile apps and remote services to break.

This is a prime example of why WordPress for years (and even now when automatic updates have been turned off by way of a plugin) strongly advised people to back their sites up prior to an update.

Enter the arrogance of core developers. “If we automatically update your site, you no longer need a backup”. And why exactly is that?

Why is there an advisory in the dashboard that tells us to “always” back up the site before an update if we do it manually, but there is NO back up process if WordPress automatically updates your site?

Major flaw in logic this automatic update defaulted to “ON” is. Either there should always be a backup done or there shouldn’t. This situation is one great example of why there should be and why WordPress should NOT default to having automatic updates “ON”.

In fact, taking it a step further, there should be an advisory for the setting (that isn’t there) which should say something like “Backups should always be performed prior to updating a website. However, if you wish to automatically update your site without a backup, we can do that for you if you check this box”.

> Hold on and you will see plenty of other people who report related problems.

No, you probably won’t. The effected shortcode changes will only break a very select number of plugins who are doing shortcodes inside of HTML attributes. There are very very few plugins which do that.

Chris, plugins do not add shortcode as HTML attributes. Users do. And up until now it was a valid use if the shortcode API. I have seen reports on Shortcode Ultimate, ACF, WooCommerce and several Bootstrap plugins. Simply changing an API does not entitle someone to say the new unsupported things were wrong before.

Specially when this vocal community, mostly referred to as ‘developers’, even if they represented just 0.001% of the userbase, are the major source of WordPress growth and adoption. Why would you ever risk ignoring or evenn worse frustrating them?

I’m a firm believer in automatic updates and I appreciate the emergency work to fix a security issue. I also think that we need to work on the processes. If there is not a ‘communications team’ working with the core developers, then we need one. At some point the fix that was needed became clear and an email could have gone out prior to the release. That may not have avoided all of the problems, but would have allowed people to get out in front of it.

This seems like a non issue on core side. From the comments and examples given it is clear that the plugins and themes that are burned by this update are the ones that their developer do not understand what is the proper usage for shortcodes and use them as a magic tool to reduce the amount of code they write or just write it improperly.

In theory there is some truth to their claims. Change in api should not happen without a notice even if it is a security release. It is an XSS problem but one that requires first a user to have a contributor or author role or an admin on a multisite. All single author type sites should not care about the security issue and it is a pitty if their site was broked because of an updated that added no security.

But in the real world site owners do not update their sites when there is an update for a plugin or theme, partially because their experiance shows them that they can not trust plugin developer to not break anything, but mostly because they have better things to do with their time and updating a plugin while there is no apparent problem will be given the lowest priority. Therefor many sites which got broken now will still get broken whenever the update of the core will happen.

Mora of the story: For an important site (generates money and/or reputation) you should never install software update before testing it and therefor auto updates should be off. Yes, this means that you will most likely need to have a developer ready to do that for you and it will cost you money, but that is the reality of the internet sites needs constant maintenance and there is no way around it.

I would love to see a) a comprehensive list of plugins that were affected by this update, and b) examples with code and codec references of what actually caused the conflicts. I am curious whether this is a question of something unusual being done in this particular release or if it’s a question of non-standard code or code examples being used in themes and plugins.

The only plugins affected by this are a subset of plugins whose shortcodes are using in the attributes of HTML elements, and plugins who use CDATA output (the latter of which is getting a fix). There’s some samples on make. Some of the more obscure examples can be found on the Types and Views support forum.

Thanks Chris for the info. Vladimir I agree, I’m more just wanting to learn and understand how this all happened and if it was preventable by either WordPress core or plugin developers. Updates will always happen and these rush updates for security will happen so how can we make this a smoother process.

My personal take on this is that the auto update should happen for website owners who don’t have a dedicated web developer who does their maintenance, otherwise that should be the responsibility of the web developer.

Have auto updates enabled on none supported sites by a developer.
Turn off auto updates if a developer is maintaining it. Therefore this option should be optional.

There should be an email to all plugin developers giving them a heads up of the changes maybe 24 – 48 hrs ahead of the update regardless.

I am afraid such analysis will only prove that all code is prone to bugs and security issues. That is also why we had the security patch in WordPress itself. This discussion is whether WordPress will do what every other software (Windows, MacOS, iOS, Android, Linux, all OSes ) did, which is expose UI for its automatic update feature without the need for a third party plugin or hack, or stubornly keep the precedent going and simply treat all negative consequences of this decison as ‘collateral damage’. Those 99% this is supposed to protect are really in most danger here as they would never have the chance to backup their site (as core instructs them to do) before a potentially website breaking update hits them. Which makes me think that one cool way out of this could be that VaultPress performs a free backup on all automatically updated websites :)

It is not so hard to turn off autoupdate, backup site before update, so do your job instead of bitching to people who do their job.
It is not necessary to fight on every second post on Tavern, last weeks it looks like fight club here.
Customizer, menu, update, anything what does not stay on one place like dead body and rot is a problem for some group.

Millions of websites powered by WP run everyday on internet and here it sometimes looks like armageddon began :)

If it’s a major security fix, that trumps making sure it doesn’t hurt plugins–I have automatic updates turned off on my sites, but, seriously, I’ll take a broken site over a broken into site any day. No contest. I realize it’s inconvenient for plugin developers, but that’s the nature of the game.

Well said, I’m a plugin developer, and if I’m doing something that gets broken by a security update, that’s on me, and I’ll take the fallout. That may be easy to say when I’m not the one affected by 4.2.3, but I’d like to hope I would keep my head about me if ever I find myself in that position. I also find myself in the position of maintaining several wordpress sites, and it was quite nice to see the automatic update notices rolling in.

It is disheartening to see such discord in this great community. Our site is a CMS that welcomes registered users to contribute. We were hacked as a result of the vulnerability that this release fixed. I am certain that the dev staff at WP is doing the best they can in an environment where other smart folks like you are spending all their time just trying to break in to sites. Personally, and from reading most of these comments, it seems if plugin developers followed WP standards many, if not most, would not have broken. If I’m wrong, sorry. If I’m correct, maybe the plugin developers should try to work within the parameters/standards that WP requires.

Something to consider might be the likelihood that this “discord” can and most likely will bring better understanding and opportunities for everyone to learn. The great community needs to be able to speak. And speaking isn’t always going to be with one voice.

Debate has to be allowed somewhere.

I agree that plugin developers need to follow WordPress standards. However, as has been mentioned, those standards haven’t been very well documented and are still being documented.

Recently, there was another of WordPress vulnerabilities discovered and fixed and again WordPress hadn’t adequately documented the use of certain functions. It is the result of discussions (not always agreement) which cause things to come to light which will ultimately enhance and further the “evolution” of a project.

If we don’t allow things to be looked at from angles other than what we believe or know, we don’t grow. OR we grow very slowly. That’s just the way things work.

It would be nice, anyway just about 13.4% of all sites are on php 5.5 or 5.6. (btw. not even half of sites are on the latest version of WP)
I hope when php7 and http/2 will come, we will see faster and huge movement … just hope, don’t believe :)

I realize it is the custom over there at WordPress.org to ask for volunteers for everything. And there is nothing wrong with that. However, I think the invitation should be extended to the people doing the coding.

As you have had the opportunity to learn here, I have been involved with computers for approximately 20 years prior to the internet as we know it to be. When I began programming we didn’t have volunteers. And when we coded we were required to document. In fact, disciplinary action could be taken against anyone too lazy to provide documentation.

Now, I ask you, why would someone else be expected to go in and clean up after a core developer? Those people should be providing documentation on everything they do. Maybe if they did that, they might not be releasing new versions of WordPress as fast as they have been doing recently.

But, is that a bad thing? I don’t think so.

In fact, if they were doing adequate documentation as the project has been evolving, they might find that they would know what to expect when they do updates.

The obligation for documentation rests upon the coder. There is nobody who knows more intimately how that code is supposed to work than they do. If they want to have tutorials based on the documentation they provide, sure ask a volunteer to do that. I can get on board with that. But to ask for people to volunteer to do something that should be provided as coding is being done, that’s just not the way things should be. If there is a team coding a function or some other part of a project, then that team should have someone designated to document it.

There are thousands of developers who provide extended functionality for WordPress. Each of those developers has the responsibility to provide adequate documentation in order for someone to know how that plugin extends WordPress and what they can expect from that plugin as a result.

These last two automatic updates and the problems associated with them are the direct result of core developers relying upon someone else to do their documentation. I think it’s time for core developers and core contributors to step up and provide what they should have been providing all along. Now, that would be a “smart decision” I would agree with.

Why should I or anyone else be asked to step in and reverse engineer something so we can document what it does? If you have other documentation you are relying upon to do your documentation, why not ask that coder or that team to provide the rest of the documentation?

I do know from past experience, those associated with core aren’t really excited to be questioned, but you know what? Those people are the ones who have been most active in creating the current environment within the “community”. Maybe things over there need to change.

The core team is not of one mind and attitude. Everybody taking a step back and not making assumptions about motives would go a long way here.

I think there’s a strong assumption that documentation isn’t a part of everyday core development – it is. It hasn’t always been, but as long as I’ve been the docs committer for WordPress core it has. Missing documentation wasn’t always considered a bug, now it’s considered vital for a commit candidate to go through. That’s a huge step forward any way you look at it.

Could the shortcodes API have been more adequately documented? Sure. Could the changes that went in with 4.2.3 have been better explained? Absolutely. The balance there of course is to explain what’s currently supported vs not creating a roadmap for any would-be hackers to follow, especially since this was a security release. I think we could have done a better job there all around.

Discounting the recent changes, I think it’s also important to note that what we’re talking about here largely falls into the category of legacy documentation – that is to say, APIs introduced long ago that were never adequately explained … like the shortcodes or media APIs. And it’s not a little bit of code we’re talking about, it’s literally tens of thousands of lines that have to be read, understood, and explained, sometimes without any historical context.

Call it whatever you want, “cleaning up after core developers” even, though in my experience, it’s usually more productive to expend energy on lending a hand than it is on pointing out our shortcomings. I didn’t write 99 percent of the code that I document, but that doesn’t stop me from championing the cause.

We’re all part of one community, and everyone benefits from better documentation. So when I say, “I invite you to participate” that’s not a call for cleanup in aisle five, it’s a acknowledgement that what we have isn’t perfect, and we need the community’s help to make it better.

Thank you for pointing out the obvious. However, this is delving into another subject. The flaw in all of the logic is that forced automatic updates should be happening when apparently nobody understands fully the impact of changes to the thousands of lines of code which apparently are NOT adequately documented.

And that is where I return to this topic and call for either an option to turn “on” automatic updates or abandon the requirement altogether until more adequate documentation is available for not only those who extend WordPress, but those who are contributing to a core nobody really has a full understanding of.

Again, thanks for the invitation. But again, I believe the core developers and the core contributors need to STOP, take a STEP BACK and AUDIT WordPress code and fully document so that there is better understanding of what impact these updates have on plugins as well as unsuspecting websites.

I have been seeing a lot about “security”. What exactly is security when nobody fully understands the code contained in the project?

@centralgeek I’m not sure you are picking up the obvious what Drew tried to convey, even with your 20+ years of experience. All the people involved in contributing to WordPress core are doing so with the intent of making it better. It is community driven. Users don’t like feeling like they are not listened to but, but I’m sure none of the people contributing directly like being treated as nasty hobbits that just don’t get it.

There’s a difference between bringing up discussion around issues and being critical of the people doing the work. It is convenient to mentally separate those driving the project and those that are mere users. What this does is enforce the idea that users are at the whims of an ‘elite’ group as some have called it. It also makes some users act like customers who’ve gotten a bad deal. But we’re not customers.

Users are community members and every community member is a potential contributor. All contributors come forward because they want to see WordPress become better, that’s the dynamic that we have. That’s the driving force. It doesn’t mean everything will be perfect. Lots of points raised have a lot of merit in my opinion.

How WordPress gets better is not through sideline criticism of its contributors efforts, it’s because people feel motivated to make the project better and contribute. If there’s something about the project that sorely needs improving, the dynamic that needs to happen is for contributors to step in. I’m not describing some moral plea, I’m describing the actual mechanic of the project that has been working all these years. This is not about whipping the current contributors into shape, as if its a staff under employment.

So it’s community driven and that also means its not perfect. I for one, think that WP could use a community relations team. And maybe it’s time to think about bring site backups as a core feature. But that’s just me.

I just think it’s far beyond silly to castigate those who are currently contributing because a choice was made aimed at prioritising security over convenience. A choice that will attract criticism regardless of what you prioritise. (Mind you I’m in favour of allowing users to disable or buffer updates through a UI). But part of buying into WordPress is about buying into the process that makes WordPress. That model has got us this far. The figures say it works, overwhelmingly.

Actually, I think you have failed to grasp @Central Geek’s fundamental point. Which is simply that bad practices have been adopted.

There’s no personal criticism there. Unfortunately, some of those responsible for these practices have taken it personally. But @Central Geek’s response to that has been one of exasperation rather than “silly … castig[ation]”.

@Central Geek,

I have appreciated your well-thought-out comments here, which have explained the issues very well. I do hope that others will stop seeing personal criticisms where there are none, and will start thinking instead about how to improve practices for the future.

Maybe it’s time for WordPress to fork itself
Having worked with Apple for almost 30 years, it is obvious that Apple thrived the most when it completed with itself and aggressively obsolesced old technologies.
By forking and eliminating backwards compatibility, problems like changing an API for security purposes would come up less. And developers would be reinvigorated by the opportunity to better exploit emerging technologies.
Wouldn’t it require far less effort to support an off-ramp in addition to the modern fork, than supporting a single bloated code base?

I’ll support a fork if WordPress starts to fashion its strategies based after big commercial corporate companies. Fortunately I don’t think that’s going to happen at any point.

Splintering the project would not go down well for innumerous reasons. If people want to build the one true CMS that runs smoothly under all conditions, it makes more sense to start from scratch. (5 years later that project will have the same problems though.). I prefer to put my money on an army of wonderful developers incrementally making this project better, the track record is amazing.

just to clarify, that’s what I am saying. I am not suggesting a renegade group – an official fork.
By leaving behind the bloated out-dated part of the code base, developers would be in a better position to innovate.

Maybe someone else has commented on what Peter Cralen said. If not, here’s my two, “It is not so hard to turn off autoupdate, backup site before update…” It really is that easy to do, so I agree that the real issue is not the auto-updates but sometimes (please notice I did not say always) lack of knowledge/skill or initiative of site owners/managers. From what I’ve been seeing, this is the result of the thinking anyone can put up and maintain a website when some of us here know that’s not the case unless the site has minimal function. When there is not much to a site, then yeah, its chances of breaking are low, and yeah, just about anyone can run it.

Frankly, these issues with auto-update do nothing but create an opportunity to get some business from those who don’t have the time or inclination to do it for themselves or who have a situation that is not working with their current webmasters, developers, whatever. Yep, there’s an up side to everything.

I agree with many comments here. I don’t like automatic updates!! I manage 100’s of sites and waking up to broken sites last week was not pleasant – I was one of the folks on holidays. I’m not including the statement in the wp-conf file that tells the core to NOT update automatically. Allow me to get a message to update and then I’ll update when ready.

I have used WordPress for about 8 years now, as a part time blogger and “apprentice” Internet Marketer.
I’m not developer, but as an ex Army Communicator I can only say that the operator must be allowed to control when updates to their apparatus/software occur.
The use of their WordPress websites, and the important option allowing them to back up before updating, is essential to maintaining that control.
Automatic Updates should NOT be forced upon WordPress users unless they take the decision to accept them.
John Reed (Major, Royal Signals, Retired)

So another lack of good communication take us to a new round of of bad mood in the WordPress Community.

I really think that an urgent message sent to every registered plugin developer and a blog post, even if generic like “any shorcode in the form of …. will stop working” would have avoided a lot of problem to WP user and, moreover, would have avoided another bad mood in the community

I really see us who develop plugins, themes and who bulid websites for a living (small or big companies), like partners of the core WP developers, like @Chip Bennet wrote on a comment here.
If we raise an issue is because we love WP and we respect who contribute to make it.

I’m with WP since the 2004… and I can clearly remember when we, our opinions, our suggestions, were considered as such: maybe wrong but welcome suggestions.

Now more and more often I see just answers that have the bad taste of: “we know what we are doing”, “just us know the big pictures, shut up”, “WP is our toy, if you don’t agree… go away”.

While I’m sure that it’s not the real sentiment in the core team I sincerely have to say that, moreover for a newcomer, this is the impression they give of them.

Please, give us the roadmap of where you are taking WordPress. Maybe this help us understanding the “why” behing some decision… because there is a roadmap, isn’t it??

Tell us if “WP as a small core with just the essential feature extended with plugins” is still the main paradigm.

Tell us if the business needs of Automatticc is “features for wp.com first then the rest”, there would be nothing wrong in it since we all benefit for such huge investments.

Show us the “big picture”, we need to know it, we need to be part of the journey, not considered merely as (not paying) customers.

If I’m not wrong, one of the objective of this year is to reinforce the WP community and it’s organization. Well, I thnk we ALL still have a lot of work to be done.

Why the core dev team is so controlling over the Automatic Update? All we are asking is to have an option to disable it without having to touch the code, or using a plugin. You can have the automatic update set to ON by default, so those who don’t bother to change can just leave it alone, but those who prefer to do manual updates can set it to OFF easily.

I use several plug-ins with risky options that can be accessed from sections typically labelled “Advanced”, and the publishers write conspicuous warnings about selecting these options, as well as links to more information, so that knowledgeable/intrepid users can benefit from those options.

A new Settings->Advanced page would be the place to make the choice to turn Automatic Updates on /off accessible from the back end. It would also provide an opportunity to publish links to material that educates users about the necessity of keeping software up-to-date, the benefits of doing backups before updating, and the trade-offs between automatic vs. manual updating of WP websites.

And if there isn’t a hook in WP that allows publishers of backup plug-ins to have their code executed prior to automatic backups, then there ought to be!!!

Why is open source about having many UI options? A lot of software, especially old software, has way too many options, confusing.

The more options the harder to maintain all possible combinations as responsibility for a core team.

This very debated security release has become so partly because of a loosely defined API, presenting the user for too many, possibly dangerous, “options”.

Not having a Core option presented to the user inviting to turn off automatic security updates is the Core Team saying “We take the responsibility of not releasing any update that breaks more things that absolutely necessary to maintain the safety of the Word Wide WordPress”.

The roadmap of WordPress core is towards fewer options, as stated in the official philosophy, “decisions, not options”. In 4.4 there will probably be a cleanup, removing a lot of old options rarely used.

The “Settings – Advanced” section of WordPress Admin is Plugins – Add New (easy to find and install) and wp-config constants (requires some skills). This puts most of the responsibility, but not all, to maintain these by the plugin author or the developer for a certain site.

A general debate on the core philosophy of WordPress, especially “decisions, not options” for Core, should (again be held somewhere with that as the distinct topic.

Disclaimer: I’m a nobody with some (arrogant) opinions on this excellent piece of software, sometimes coherent with the official philosophy and roadmap, sometimes not. I’m in no way speaking for WordPress Core Team or any other party.

@knut I second your opinion on decisions vs options. Sounds like Apple’s success story for me.
A lot of people are against the automatic updates and I don’t get it. There are two types of people involved in this: developers who should know how to stop/ manage this (right @Central Geek?) and end users who should have devs available to help them out.
Maybe it didn’t work out well this time but for sure that’s the way and of course there’s a lot to improve regarding the communications and procedures.

I am well versed in how to manage and stop automatic updates. The problem for me is when someone shows up who wasn’t aware of just how dangerous allowing automatic updates was and their site is down with no backup to work with.

That’s a major pain in the butt for someone like me. Though I can usually get things sorted for them, that wouldn’t have been necessary if they had been advised to activate automatic updates or have someone familiar with doing backups assist them in maintaining their site if they don’t know how themselves.

It is a given that there are inexperienced people running WordPress. Never denied that. However, as I said above, until you require the server software WordPress runs on to be secure and not have such a high priority on maintaining backward compatibility with outdated (end of life) versions of that software (and vulnerable versions of that software), you really have a twisted set of priorities and your logic is suffering.

Don’t give me the “security” rationale when you have a high priority for maintaining the platform to be backward compatible with vulnerable software. The logic fails.

Now, the problem lies in the premise that WordPress is developed for novices and that they aren’t smart enough to manage their sites. Actually, most are smart enough, if you spend a little effort to provide adequate documentation which was lacking in what created this security issue and the most recent security issue prior to this.

You can boast all you want about how all of the other updates have gone so well, but I know a lot of people who have suffered from those updates as well, them being automatic and done without backing up the site before doing the update.

And that is the issue many of us have. Don’t force updates on the people you consider to be too stupid to know better. Allow people to opt in. I know the arrogance and stubbornness that refuses to add this one option to the WP core, while pushing the adoption of certain plugins into the core which will come with some options.

Grow up and allow this option, that’s all that was asked in the beginning and that is all that was asked for since these most recent issues were brought to light.

Or is it that much business for the WordPress affiliated worker site(s) that the “developers” getting the repair business are lobbying for there to never be the option? That’s a thought..

I fully respect your opinion on the matter. This time your arguments are clearer. Except for the last paragraph I can follow your line of reasoning.

For others, who support the official line of not adding this option in core, it’s not about being arrogant, but a firm belief that it would be harmful.

If I was to accept your line of reasoning and accept a core option for this, I would at the same time advocate a complete removal of automatic updates in core, and leave it to a plugin. Either Core Team thinks automatic updates will benefit “the World Wide WordPress” or it doesn’t. If it’s unsure, then it should not be implemented in core at all.

That’s why such option will never happen in core, but be left to plugins or a simple wp-config constant. If any change would happen in this case, it would be to remove automatic updates entirely, as a thing not recommended for the average user, and declared as plugin territory.

Which plugins that is planned to go into core will create more UI options?

The reasoning behind allowing old versions of PHP to run WordPress has been debated for a long time, and in many places. It will be raised when reasonably few sites will be affected. There is a plan for this to happen. That debate should not be confused with this one. In no way this has to do with core security team not taking security seriously.

I can disagree with still letting PHP 5.2 be the minimal requirement, but it has nothing to do with this as long as there is no known vulnerability in PHP 5.2 that web hosts sees as a problem for their servers. I disagree that WordPress will not gain from raising he minimal, but that is the official stance, for now.

Oh, yeah, I’m quite familiar with the “Official” stance. Too bad it’s such a reckless one. Serving a group of people WordPress considers too stupid to be able to handle options (especially one that can have such an impact) is in and of itself rather stupid. Have many people stopped to think, those people who are so stupid they can’t be burdened with such technical decisions really aren’t likely to be running WordPress sites?

The rationale in the last paragraph.. I guess not many people think about the fact that there is at least one affiliated site recommended by WordPress for getting help from developers.. It’s an interesting thing to consider given the staunch position on not allowing ONE option. One could wonder what the real motivation is.

So, you are suggesting that there may be a point where the automatic updates would be considered plugin territory rather than admitting that having one little option to turn off or on automatic updates is better? How childish is that? Just add the option and be done with it. LOL

And I will continue to put the two together as long as someone puts the two priorities together. After all, I believe it was you who placed the number one priority and the number two priority into these comments.

And that is the logic I battle. People put things into the mix together and then complaint that they shouldn’t be talked about by anyone else together. Silly me. Now that is arrogance.

Not presumably knowing the impact of a decision one is forced to take, does not imply that person is stupid. This logic fails to me.

Users/People should have options! They should be able to do things that harms themselves.

But this is not about a site only. This mostly about the web as a whole, primarily, and for the reputation of WordPress, second. Hacked sites is the worst that van happen to users, AND others sites affected, in a cascade to hurts the www overall.

“Childish” not to have such option in core, “grown up” to obey your demands of such? I’m sorry, but I don’t get it. As said, I think it’s harmful, nothing else.

It’s the WordPress philosophy. They consider people too stupid to either care of have the ability to adequately deal with such technical decisions. Sure, they say it a different way but that is the message. Only they know what decisions should be made and they are making the “smart” decisions so the rest of the stupid people don’t have to bother.

Wake up and read what is written.

Here we go again. We are backward compatible with more vulnerable web software which has reached it’s end of life and beyond and you want to talk about people who want to have the option to back up their site without having to add more plugins (turn off or on automatic updates). Putting the entire web at risk. That’s asinine reasoning.

We can agree to disagree.

We live in a world where the most secure websites are being hacked on a regular basis.

You are attributing the danger to the entire web on a little website run by someone too stupid to be able to make smart decisions about the security of their site and other sites on the web.

And this rationale comes from being asked for an option to have automatic updates off so that sites can be backed up before updates are performed. You can’t understand the logic?

My question now is, how did the web survive prior to the introduction of forced automatic updates by the “smart” decision makers over there at WordPress?

I’m sure the communications and procedures could be improved, as always.The post announcing the (probably necessary and presumably urgent) API changes should probably have been released earlier to avoid some trouble with some plugins. Or maybe not possible? That should have been debated here. That was what I was looking for when reading this post’s comments to begin with.

And that is the main issue. And the core WordPress developer reliability with regard to communication and adding things which should be separate is what drives my concern.

I can bend some on my position but WordPress needs to stop the approach they have been using. There needs to be an allowance for people to be able to back up their sites when significant API changes occur.

Keep in mind, this update and the last one were both related to poor and inadequate documentation provided by WordPress. Plugin developers can’t be accused of not knowing how to work with the platform if the platform developers are too lazy to adequately document.

Don’t advertise your update was for “security” reasons while introducing significant other changes. That’s not the way these updates are supposed to be handled.

That’s not the way to do business. If you aren’t going to communicate then you have to give that option. Period.

And having seen one of the conversations after the update was found to have such an impact, there were a lot of people involved with the project who weren’t aware there was going to be such a big problem.

Now, why was that? Could it be it wasn’t adequately tested? And if that is true why not?

Do you doubt the changes to the Shortcode API was based on security, closing a vulnerability? I don’t know. I clearly have got that impression. Snd devs saying it was he most important thing in he update.

The documentation on WordPress is far from perfect. It needs attention and contributors.

I’ve not seen plugin developers “accused” of anything.

If this update was very important, and given the trouble for some, in could possibly have been handled better, prior to the update being rolled out. I guess this is about learning. I’m sure this is not because some are ignorant.

I would agree. None of it is because some are ignorant. The rationale is flawed and the logic doesn’t work.

As long as WordPress developers need help with their documentation and refuse to allow people options given nobody, even the developers, knows what all is going on, then there are going to be heated debates. And since so many people didn’t realize there was going to be such an impact on so many sites, I would venture into the area of believing that the cause for such “discord” (mentioned elsewhere) is due more to stubbornness than anything else. And that stubbornness is born of arrogance.

As long as there can be such significant issues, people should be allowed to back their sites up before updating. The lack of concern for loss of data is reckless and too dismissive of those who are running websites with this platform as being too stupid to be able to handle such technical things.

Uhm… as user… how I can be aware of the updates conflict with my plugins? So, whatever, I’ll click OK to a security update. For sure, I don’t want for my site to be less secure. The core dev team is doing all right: from an user POV, there’s no need to accept or refuse a security update. Only to accept it. If something goes wrong with the core, the core dev team had to fix it. That’s all.

Good luck getting the core dev team to fix your site. If your site is made unresponsive, how would you expect the core dev to fix it? And without a backup what would they fix it from? The core dev team doesn’t give notice of the update coming and they don’t do a backup. So far so good for you, that’s great.

The question is: should the changes be pushed to your site without giving you an opportunity to back up (hence to be able to rollback in case of problem).

This is where opinions differ; the core team thinks it’s better to automatically apply the updates while a lot of voices are against.

The motivation of automatic updates is clearly to address sites with poor maintenance.

A suggestion could be to instate a grace period during which the notification of updates would be displayed (as it was before) and dedicated admin could backup and update their sites. After this grace period, the updates should be automatically triggered

I just want to applaud what has got to be the most passionate WP Tavern comment thread I’ve seen in a long time. I’m settled in on the couch with my bowl of popcorn – this beats Netflix streaming for sure.

I never had auto-update turned on, as I prefer to backup and update myself. Somehow, auto update has been enabled on some of my sites. So yesterday, 4.2.3 installed itself. And guess what. No backup…
Currently fighting through a WordPress support thread to get control of my admin back…

Regardless of your stance on the issues, the fact is that this update is seen pretty widely as being negative. The “Developers” that so many here and in core appear to despise are using their influence to recommend that the novices disable auto updates. I am seeing more and more posts on blogs and in social media with links to plugins or code or instructions to disable auto-update. And widespread public opinion postings that WordPress (the people/organization) can not be trusted. The end result is a rash of negativity for WordPress (the community) and probably a net loss of thousands (or tens of thousands or hundreds of thousands) of WordPress web sites that auto-update.

As I see it the issue at hand is about trust. The number of devs and noobs that distrust the WordPress establishment is growing. It’s not meteoric and it’s not going to cause most people to stop using WordPress, but for all we know, this is the “beginning” of the end unless something is done to address it. And from where I stand, the WordPress establishment does not wish to address it or even acknowledge it. They just want compliance without question, and that only makes it worse. And they’re blind even to that.

I just hope that someone at Automattic or in the upper eschalons of WordPress Core will wake up and see what’s really happening. And stop feeding the beast that is making the whole community more and more divisive.

You’re right about the perception, Dave, and I was one who said just turn off auto-updates. But if site owners, no matter their technical abilities or the abilities of their webmasters, devs, whatever, see WordPress as a hassle, then it doesn’t matter what caused it, the damage is still done.

There does need to be better communication in future, and I’m also a little concerned about the commenter who said they had auto-updates turned off but somehow it happened anyway. I’ve never turned them off, but I may after all of this, and I don’t want any surprises.

I have turned off auto-updates on the hundreds of live sites I manage. I don’t feel that I can trust WordPress to auto-update itself and not cause harm. I don’t feel that I can trust those who make the decisions about what gets released as a security update. I don’t feel they are rooted in reality.

I will continue to leave it enabled on my dev/staging sites. And just as I do with new releases of WordPress, I’ll test them there first before rolling them out to live sites. And I will encourage others to do the same.

I already express myself about the trending attitude of the core team that’s …well. not very friendly… but please let’s not reiterate wrong information.
Turning off auto updates is just as easy as adding this line to your wp-config.php, something that everyone who installed WP can do in few seconds:
define(‘AUTOMATIC_UPDATER_DISABLED’, true);