WordPress: Windows of the Internet

WordPress powers 41.5% of all websites, and it represents nearly 60% of all content management systems.

This is absolutely massive capitalization at the scale of the global Internet. The momentum of a multi-decades old ecosystem alone is incredible: the plugins, themes, experienced administrators, shared hosts, Internet guides, talks, and generally the incredible social economics of scale means that WordPress is perhaps the most ubiquitous technology on the Internet, right there alongside, HTTP, TCP, and JavaScript.

And the developers of WordPress have worked hard to keep it that way. For example, they have maintained a near-fanatical commitment to backward compatibility. This means a plugin written a decade ago has a remarkably high chance of still functioning on the latest version of WordPress today. While other frameworks frequently force developers through grueling, breaking-change migration cycles every few years, WordPress has historically prioritized ecosystem stability above all else.

Who—or what, does this remind me of? Microsoft Windows!

Windows dominates its market, representing nearly 72% of the desktop market. I’ve personally launched games written over 20 years ago in modern Windows 11 and found they still worked without modification. It’s the default operating system for most users, unless they happened to buy a Mac instead. If we generously assume that these are fair and competitive markets, this seems to suggest that the users highly value compatibility with the plugins and apps they wish to run over any other competitive factor. The people should get what the people want, but every engineering decision comes with a cost.

There is a price paid for this degree of extreme backwards compatibility to reach the widest possible audience. Both systems are stuck in the pre-2000s Internet era of software architecture, with small modernization inlays.

WordPress Concessions

• Multi-Entrypoint Routing Architecture
  Modern PHP frameworks (like Laravel or Symfony) and web frameworks in general route all traffic through a single entrypoint (index.php) using a centralized router. This design lends itself to consistently enforcing a strict security posture by processing all requests the same way. WordPress, however, still allows direct access to individual files across its directory structure. It’s up to each file to enforce the security boundaries. Because an attacker need only find a single flaw in a plugin or perhaps a forgotten PHP file in the web root, this architectural design decision makes WordPress harder to defend than necessary due to a lack of a single choke point through which attackers must pass. This also complicates writing rules for the web server to allow or deny PHP processing for various directories when the code is sprawling.
  
• Eternal XML-RPC Protocol
  WordPress still ships with xmlrpc.php fully enabled by default despite the existing Rest API. Even the official WordPress mobile app requires XML RPC for full functionality. Not only is this an extra entry point that must be defended (e.g. the XML RPC login methods bypass any rate limiting of the admin login web page), but also untrusted XML parsing is inherently risky. XML External Entity, denial of service, and buffer overflows mar the history of the request format. There’s a safer interface available now, but WordPress can’t remove the old API because some services use it. Apparently there’s no urgency to remove the interface when there will be legacy users to support. Websites should strive to disable this API.
  
• Conflation of Code and Data in the Web Root
  A primary selling point of early PHP was its simplicity: a web server could easily be extended to execute a pre-processing step right before serving HTML to the client. While highly accessible, this model lacked scalability and introduced severe security risks. Today, because large applications must handle user uploads, a common exploit involves tricking the server into executing uploaded data as application code—a vulnerability exacerbated because both reside within the same public web root.
  
  A significantly more secure architecture strictly isolates the application’s executable code from user-generated data. WordPress cannot decouple this conflation without fundamentally redesigning how it initializes and executes PHP, which implies a compatibility price that the project is unwilling to pay.
  

Windows Concessions

• Unsupervised App Ecosystem
  Windows has no central app store of note. While there have been multiple attempts to create an official app store, developers have little motivation to seriously participate because they have already invested heavily in the legacy distribution model. Consequently, many apps in the store simply download a standard installer that executes in the traditional manner. In most cases, the official store acts as a glorified download server—if an app vendor even bothers to use it at all.
  
  Unlike Apple, which controls its hardware and can force developers into compliance to access its closed ecosystem, Microsoft lacks that leverage. Software lacks quality control, and apps can easily contain malware or be published anonymously because users are conditioned to download software directly from the open web. It is a terrible security model that essentially amounts to no security model at all; applications can come from anywhere and are rarely vetted in a meaningful way.
  
• No App Isolation
  To make matters worse, these unverified apps act with the full faith and privileges of the user. The archaic yet still active security model assumes that any action taken by an application reflects the explicit intent of the user. As a result, apps can freely access each other’s data, and there are virtually no boundaries restricting what an application can read or modify within the user’s personal files.
  
  Compare this to modern mobile operating systems like iOS or Android, where tight sandboxing and access controls prevent applications from sharing data unless explicitly permitted by both parties. In those systems, the application is treated as an independent actor with its own distinct intent and restricted permission set, rather than an extension of the user.

Closing Thoughts

None of these problems are entirely fixable without conceding compatibility because fixing the issue implies a major redesign that breaks existing extensions or apps. This isn’t something these giants are willing to do. I understand that software ultimately must be useful, and ecosystem matters a ton for building a website or desktop experience that makes users happy. Still, I can’t help but wonder and wish that there was a better way. Ultimately, in engineering, all design choices are a compromise. Perhaps this principle extends to social and economic compromise as well.

I cannot argue that WordPress and Windows aren’t useful in spite of their shortcomings. I’m using them both right now.