In my blog post about today’s coordinated plugin update, I discussed the logistics of many of the top WordPress plugins working together to put out an update to fix the misuse of
Throughout the day, I’ve tracked other plugins as they update, and my list has around 35 plugins on it — and I only included those with a significant number of installs or are otherwise noteworthy.
I know for a fact that other popular plugins (hundreds of thousands of active installs) are updating tomorrow. All told, I think it’s safe to say that most installs of WordPress were affected by this security issue — a security issue caused by a poorly written Codex article and the long and widely misunderstood return value for a WordPress function.
All told, the vulnerability was minor in most cases. But the lesson is major. The lesson is that most of these instances could’ve been prevented with a more thorough Codex article.
In response to today’s updates, the Codex article was forwarded to the new Developer Reference page. I’m not sure that’s the “perfect” answer either, though it’s a strategy that’s been planned for much of the Codex for some time.
More importantly, that Codex article went years with improper examples, though I’m sure dozens of developers could have fixed them. And I know that I haven’t myself fixed every bad example in a Codex article I’ve ever seen; or emailed every tutorial blog author that their stated method was not correct or safe.
I tend to look up what I need, take it, adapt it to my use case, perhaps fix parts I see that may need fixing and then move on. We should take a step back more often.
If one person had taken a step back and fixed that Codex article in the last four or five years, the issue wouldn’t have been what it was today.
And that’s my challenge to you: next time you see something you can correct, do it. Take the extra minute. Who knows, maybe you’ll prevent a future mass security update.