This post is not the normal faire for this blog. Normal programming will return shortly (I had to create a new category called ‘Rants’ so that says a lot, I think).
I’m frustrated.
I am so conflicted with the shortcodes API change. I understand it’s a security fix, and that is the trump card. I’m fully cognizant of the fact that this change hasn’t affected a huge, huge number of sites and that’s a really great thing. I’m also cognizant of the fact the way in which the API was being used wasn’t the envisaged way (using shortcodes in attributes) and that, to a lot of experienced people, doing so is just a bit, y’know, silly.
However, this is a breaking change to an API. An API that has existed for a long time and as such is being used in many, many different ways.
As someone who has been affected by this, and the thousands of people I support, I’m not currently someone who can have a fully-clear picture on this. I’m trying to see the bigger picture. I don’t have the luxury of telling people “well, you were doing it wrong, you shouldn’t have been doing it like that in the first place”.
I’m frustrated at the way this has been communicated. I’m not talking about the fact that this had to be communicated after-the-fact. It’s a security patch, that’s obvious. I’m more talking about the way in which many high profile people in our community have bashed plugin devs for not doing it properly in the first place, then when plugin devs got frustrated at the way this has been communicated, they were met with some more derision. Even blaming users for doing what the API allowed them to do – and has done for years. That’s not the WordPress community I know and love. That’s not the WordPress I know and love.
I think what I’m most frustrated about is the potential precedent this is setting. “We had to break backwards compatibility because of security but it’s actually your fault your stuff is broken because you shouldn’t have been using it that way” is the way I’m feeling right now.
Where does this put us with the WP API? What about the customizer? These are new toys, just like the shortcodes API was way-back-when. People are already doing pretty crazy things with the customizer and that’s not going to change. Neither should it.
I guess it’s a software-maker’s conundrum, in general. You can’t possibly imagine every use-case for the thing you’re writing when you write it. But for so many years and in so many circumstances, the attitude has been different. It’s been “OK, we have to work out a way to support this use-case because people are doing it that way because we allowed them to. It’s our fault. Not theirs. Let’s work out a solution.” That doesn’t seem to be the case at the moment.
The security team have done – and always, in my opinion, do – a great job. It’s almost always a thankless job. Sometimes it’s an impossible job and I get that it’s better to have some broken-pages-for-the-time-being rather than insecure sites. What I don’t get is where or when this attitude change happened.
Thanks for articulating this.
The WordPress team (and I personally) erred seven years ago by not being conservative in the shortcode use cases that we allowed to work, and/or by not saying “these ways are supported, but THESE ways are not”. So we were put in the position where a use case that worked (even though we’d never used it in core or officially endorsed it) could not be fully supported while keeping WordPress sites secure. There were earlier versions of the security fix that would have broken even more plugins, and a lot of work was done to minimize the impact. We should have communicated the changes and shared information the supported/unsupported use cases before there was pushback by plugin devs and plugin users. We probably should have linked to that information/guide from the release post. And although I do think plugin devs were stretching shortcodes beyond their original purpose, it’s on us that we didn’t push back against that until after we were forced to break some of those use cases.
Mark, thanks first of all for taking the time to comment. Secondly, I’m in no way assigning blame to anyone or anything, these things happen. To err is human, after all. The greater good is a more secure WordPress and that is what – rightfully and naturally – won out. I really hope that we as a community can learn from what’s happened, how it’s happened, why it’s happened and ultimately improve across the board.