48% of all CMS websites are WordPress, and other stats

[Harold Mansfield]

I never said they don't. I said the developer overhead (and therefore the accumulating technical debt) is much more than it should be, largely due to a PHP4 architecture (that will likely not be improved to a modern architecture until the powers that be see that backwards compatibility should not be a first class citizen).

Dude, I have to be honest..I've been doing this a long time and sometimes I have no idea what you're saying.
All I can says is that WordPress runs in the latest version of PHP.

The release number of WordPress does not coincide with a version of PHP. WordPress 4.2.2 runs on PHP 5.4 (or greater).

As far as "accumulating technical debt", and "developer overhead"...I don't know what all that means. Can you dumb it down for me?

[Brian Altenhofel]

The release number of WordPress does not coincide with a version of PHP. WordPress 4.2.2 runs on PHP 5.4 (or greater).

I didn't say it does. For compatibility reasons, WP is still largely built around PHP4 procedural programming and paradigms. Treating backward compatibility as a first class citizen rather than a byproduct of forward compatibility, issues like this one are created (WP hasn't officially supported PHP4 since 3.2, but yet still maintains code whose only purpose is PHP4-compatibility).

Another example of this is in the recent add_query_args() XSS vulnerability. That function relies on func_get_args() to process a finite amount of arguments (documentation specifies that only 3 are valid, but technically speaking you can pass more that will just be ignored) from a signature-less function. The right fix for that vulnerability would be to have add_query_args() always return sanitized output by default with an optional parameter being explicitly set to bypass sanitization, but instead it's just "update the docs and tell everyone to wrap calls to that function in esc_url()." Rather than allowing site owners to trust that proper use of core APIs will result in secure code, now site owners will need to audit every plugin or theme they use that calls add_query_args() or remove_query_args(). A quick search on Github found a lot of projects still not escaping their output properly 4 months later.

The current architecture also does not allow for easily using alternative data storage which is essential when you get into projects with even moderate levels of traffic. For example, in e-commerce, once an order is completed (definition of "complete" varies from business to business) it is immutable. Between the time it is placed and the time that it is final, there are very few (and often no) changes. At that point, an order is a document. There are many systems much better suited to storing documents than MySQL, but the only way to use those technologies in WP is to bypass WP completely. Rather than encouraging developers to query MySQL directly, a little abstraction would go a long way here toward modernization.

As far as "accumulating technical debt", and "developer overhead"...I don't know what all that means. Can you dumb it down for me?

Technical debt is the result of system design choices over time. Like any other form of debt, it accumulates over time unless you pay it down (most often via refactoring). Every line of code is something that must be maintained in the future. Treating backwards compatibility as a first class citizen builds up a lot of code that must be maintained but may no longer be relevant and may even encourage bad practices.

Developer overhead is time spent doing things that should not be necessary to achieve their goal.