WordPress 4.2.3 has reminded me why being conservative with enhancements is a good thing. If a bug is committed, you lose the benefit of time to fix it.
WordPress 4.2.3 has broken some sites using shortcodes in HTML tag attributes. As part of a security fix, certain ways of doing this are no longer possible. Arguably shortcodes were not intended to be used in this manner, but some developers found they could and used them as such. I believe the plugin and theme developers using shortcodes in this fashion need to shoulder some of the blame for their clients’ sites breaking.
Unrelated to the WordPress 4.3.2 release, there was a long discussion in the WordPress Slack on merging the WordPress REST API (WP-API) into WordPress 4.4. Those involved were pushing for the merge, Matt Mullenweg was pushing back. My reading of the discussion is Mullenweg wants the API in core, he is being conservative on doing so; he has said as much since:
@carlhancock @post_status but I’ve never said that’s a reason not to do it. I super want a JSON REST API, a great one.
— Matt Mullenweg (@photomatt) July 25, 2015
At the time, I thought Mullenweg was being too conservative. Following the release of WordPress 4.3.2 I am not so sure.
Once an enhancement is committed to core, developers lose the benefit of time should a security bug be discovered. Not necessarily WordPress core developers but plugin and theme developers (provided the bug is responsibly disclosed). According the to July 25, 2015 edition of Post Status notes:
The fix that went into 4.2.3 appears to have been under consideration for a long time. The vulnerability was reported independently by a third party in September of 2014, but I understand it’s been known about much longer than that.
Post Status (paywall)
Plugin and theme authors lose the benefit of time because breaking changes in a point release can not be announced in advance. With such a tip-off, the flaw is bound to be discovered – and potentially exploited – before a fix can be tested and released.
Andrew Nacin has said the core team can’t alert major hosting providers of security issues without them leaking.
Which brings me back to Mullenweg’s conservatism around committing WP-API to core. The API is a big, complicated plugin. There are endpoints for each post, index, comment, category, tag, custom post type, page and user; and a new authentication method is implemented: open auth.
If WP-API allows for something to be done in ways that are not intended, there are developers who will do so. If the code is in core, the WordPress developers will be stuck with it. Mullengweg’s conservatism is because he wants to prevent that. Developers abusing shortcodes and the resulting issues in WordPress 4.3.2 has me coming around to his way of thinking.
Leave a Reply