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.
Developers want better communication from the those who are managing security releases. Amir Helzer, author of Types and Views, two plugins majorly affected by the release, sums up the thoughts of many other commenters on the Make/WordPress.org/Core post:
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.
As everyone is aware, I am against automatic updates. I turned them ALL off on my websites and clients. So I have ZERO broken websites to worry. #JustSayin’