What’s wrong with WordPress?
This blog is running WordPress, one of the most popular web-logging applications. Recently, another flaw in WordPress surfaced and caused some stir and panic. The issue was (in the end) missing type-checking on user-provided input, a well-known and well-understood flaw. This must not happen to a project of WordPress’ popularity and professionalism.
I looked at WordPress while writing my Diploma Thesis and found that WordPress lacks important means for consistent type-checking:
- There is no centralized definition (regexps and constraints) for all the data ‘types’ WordPress uses
- There is no general agreement on exactly when and how input and output filtering and sanitation take place. This leads to ad-hoc solutions like the one causing the current vulnerability.
What WordPress really needs is a better architecture that solves the two problems stated above and as such makes vulnerabilities like this recent one very unlikely, not ever more ad-hoc hacks. Unless the WordPress project is willing to spend considerably effort on the architecture, using WordPress for professional means will become an intolerable liability. Software Engineering is about long-term stability and dependability, established in the process, not about “if you update your WordPress every few days, you’re safe” (as Matt Mullenweg suggested).
Am 7. September 2009 um 15:13 Uhr
“WordPress lacks important means for consistent type-checking“ – that’s the problem with all dynamic languages that do not provide strict type checking, be it PHP, Python, Ruby or any of these fancy dynamic languages. All good, dependable architectures written in these languages begin to re-implement a strict type checking manually. In my eyes, this really negates all the advantages of an overly dynamic type system.
WordPress has the additional problem of being a project with a huge legacy code base. A complete rewrite might be the only long-term solution to all of its problems.
Am 7. September 2009 um 16:43 Uhr
I’m not talking about a programming language level type system. Web applications (or applications in general) need a “rich type” system that defines what (e.g.) constitutes a date (most applications can do that) or a name (most can’t and fall back to a simple string). If you really have rich types you can delegate most checks and sanitations to the framework and you won’t have to care for that manually.
Rich types is something that’s generally not present in languages (be it non-strict, dynamically types ones or not) but is added in frameworks (Django’s models go in that general direction.
The legacy code base seems to be another problem, that, combined with the unwillingness to make much-needed architectural changes (changes that break the “plugin API” (in fact, there is no plugin API) are a no-no), becomes a major hindrance for long-term robustness of WordPress.