It’s already been better discussed elsewhere, but the latest security release of WordPress (v4.0.1) exposed a fatal flaw in how some developers improperly created their own shortcodes, eschewing the Shortcode API that has existed since v2.5, making it a nearly seven year old issue.

The discussions on whether this update should have happened, what it means for automatic updates and the ill will that can be created when “WordPress is broken” have been had already, causing those of us who’ve had to explain to people in the past the difference between WordPress core and community made plugins and themes work overtime in the past week. Last night I got into a discussion over Twitter concerning the issue and how it relates to WordPress being viewed as an enterprise level solution for website development.

The discussion that I had was concerning a web property owned by a multi-billion dollar corporation. My gut reaction to say that they should know better has to be tempered with the fact that no, they should not have to. It’s the job of every site owner to vet their system, but to make a platform that is truly global, that vetting should be delegated. Web hosts and security analysts should vet code for collisions and bugs. Theme and plugin shops should ensure that their products adhere to best practices. Putting accountability for the full stack on each site owner is not only inefficient, but impractical. Inherent trust should exist that code in the official repository maintains a baseline level of code, trust that is eroded when the problems that occurred with a subset of sites on this update occur.

I’m not one for intrinsically weakened systems. I don’t think, for instance, that the ability to toggle off a security improvement like this should be readily available. That said, it is to the developer who understands the system, as it is to write them in a system-approved manner in the first place. What I do think needs to happen is a better system of education, both for clients and for developers new to WordPress (or new to specific tools in it). There needs to be more public discussion on why progress will invariably cause a bit of trouble upon adoption and how to react or future-proof. There needs to be discussion on how that trouble can lead to lack of faith, and a mistrust in the next level of WordPress growth: higher adoption among enterprise clients.

To avoid these discussions invites stagnation of growth, inhibition of progress and a lack of advancement for WordPress and its adherents everywhere.

Republish