Just like new WordPress features are supposed to be developed as feature plugins before being integrated into the core, perhaps it is time to have a look at which stalks of the WordPress code tree may be cut off entirely or be given their own better lives as feature plugins instead.
Before anyone suggest that I submit a couple of patches on the WordPress Track (as if I haven’t thought of that), I think it is more likely to be successful if I blow this into the ether by blogging about it, so more credible people than me (perhaps a group of overconfident men) may think they got the idea first and submit the patches for me.
I am going to start with the simplest part, with concrete issues and solutions and then I will ease into more complex an convoluted issues that don’t have as clear ways forward.
Some of the issues here are purely technical while others are more related to politics and collaboration.
1. Just delete XML-RPC already
Services that used to take advantage of XML-RPC back in the can already use different entry points into your WordPress installation. Jetpack can use index.php in cases where XML-RPC can’t be contacted and most external services for plugins should be using the JSON API already.
Not to mention the notorious vulnerabilities such as CVE-2013-0235 that still linger in older WordPress installations and can affect other installations on the same internal network using techniques such as denial-of-service attacks — and the more recent CVE-2020-28035 that can enable privilege escalations within your site.
Having worked in the hosting sector and seen what happens when access to XML-RPC is blocked (i.e. almost zero complaints), I think that hosting providers should be instructed to block access it by default and there should be more awareness of the dangers of this endpoint.
Truth be told, the number of use cases for XML-RPC that can’t be replaced with modern and secure methods is not even a rounding error in the larger context of things and it is long overdue to remove this feature from the security and performance perspective.
Perhaps this could be used as the beginning of making index.php the only entry point for WordPress in general, without any other PHP files in the WordPress root directory, just like modern frameworks.
2. Remove the plugin editor
This feature enables admin users to change the actual underlying files used by WordPress to run plugins. And it’s enabled by default.
It even warns users about its dangers, but if everyone is an admin user and it is always enabled, then I would assume that Murphy’s Law (Anything that can go wrong will go wrong) should apply here.
For the past couple of years, I have seen more issues related to the use of the plugin editor that before, which is strange as this is an old feature. Perhaps there are recent tutorials or online courses using it?
Not only does this enable bad (or horrible, bluntly speaking) practices out of the box, but it is also a giant security hole for any beginner-level site builder who’s login information may go astray or session information gets hijacked, and I have suspected that it is the most common attack vector for code injections, even more than zerodays in plugins.
The most common errors here however, have to do with users adding any kind of PHP syntax errors to whatever it is that they are editing. Regardless of security implications, this takes the whole site down more often than not and the amateur site builders using the feature often don’t have any other way of accessing the filesystem.
In essence, the plugin editor:
- Enables bad practices for beginner-level builders,
- acts as a common vector for code injection attacks,
- is a common way for beginner-level site builders to take down their own sites by accident, and
- makes changes that don’t stick as the updating mechanism does its thing.
Why would anyone with the slightest sense of responsibility even think about including something like this in the core without at least hiding it behind a wp-config.php constant by default?
I don’t even think this belongs in a feature plugin, so the plugin editor should be cut off completely in my humblest opinion.
3. Get rid of the comments
The comments section is one of the parts of the wp-admin interface that lacks tender love and care from contributors — and for a reason — as it is where we go to see spam, spam and more spam instead of anything that facilitates discussion.
In fact, except for blog sites hosted on WordPress.com and on sites related to the WordPress community in some way, I have almost never seen the built-in comments feature being used at all. At best, I’ve seen 3rd party commenting systems such as Disqus or Facebook being used instead.
Now that everything is a block, perhaps we should consider this legacy feature – that surely had its purpose back in 2004 – to be an artefact of the days of social media’s main venue being the comments section of blog sites and something that perhaps should belong in a feature plugin instead, but not in the WordPress core.
As the comments feature mainly gets used as a spam delivery mechanism, and with the default choice of Akismet for spam filtering, the feature should be removed entirely or hidden behind a wp-config constant.
4. What are pingbacks for anyway?
Yeah, I get it. Someone writes a blog post, citing and linking to my post and I get a notification of that as if a comment arrived.
But what technical challenges does it solve and what does it do that the referral trackers in even the simplest counters and web analytics platforms does not do?
The answer in is absolutely noting, at least not where it matters.
It sounded like a neat experiment back when the semantic web was being promoted (and it is still a good idea for the time), but just like the built-in comments feature, it feels like it mainly gets used for spam delivery.
Furthermore, WordPress uses the notorious XML-RPC endpoint for this and as I said there, one of the most commonly abused security vulnerabilitis in older versions of WordPress uses the pingback feature.
I don’t even think that pingbacks should transition into a feature plugin or get hidden behind a wp-config flag. Instead, I think this feature should be removed completely.
5. Remove or hide the Posts feature
While we are thinking of removing comments and pingbacks, let’s remove the Posts feature from the core. Yes. Really.
WordPress started out as a powerful and lightweight blogging platform that could be self-hosted, but even as I far as 2004, I already had a client asking if it could be removed or hidden and replaced with Pages entirely, as we were mainly using WordPress as a traditional CMS but not as a blogging system.
Today, only a small minority of WordPress installations uses the Posts feature at all. Surely, news websites still use it along with the few eccentrics who still blog use it, but should it be considered to be a core feature in this day and age?
At least it should be possible to hide Posts behind a wp-config constant for those who only need to write pages, as if WordPress is not just a blogging platform, but a proper content management system.
6. Remove the built-in plugins
The WordPress core comes with two plugins pre-installed (and they also keep getting re-installed depending on your update methods). Neither of them provide value for WordPress or the community at all.
Akismet is as far as I know no longer available as a stand-alone subscription from Automattic, so unless you have grandfathered in an old subscription from 15 years ago, you will have to install and sign up for Jetpack anyway to get the comment spam moderation functionality promised by Akismet.
So why ship the WordPress core with a pre-installed plugin that does not even provide a service that is available to new users anymore?
I think it is strange that if WordPress is a community effort that Automattic gets away with doing this sort of bait-and-switch marketing.
Then there’s Hello Dolly, which acts as an example plugin that displays random lines from a Louis Armstrong song of the same name below the admin view.
I understand that some of us think that putting the BDFL’s name and his interest in jazz music into the limelight somehow, even if we already have releases named after famous jazz musicians and Matt himself gets to put his name and face out there in relation to WordPress as much as he likes to elsewhere.
I would honestly show the existence of hello.php some understanding if it was there to provide an example of best practices for beginners or could act as a starting structure for a real plugin, but it is not even useful for that.
7. Take wp-cron out of the performance equation
Customers at specialised WordPress hosting providers should not have to depend on wp-cron being spammed as ajax requests from the frontend to imitate background processing in PHP.
This not only hijacks performance from low-spec hosting solutions, but most web requests time out after something like 30 seconds as well. This means that in case of long-running tasks or badly written plugins, they may not even get finished within that timeframe and get repeated into infinity.
Competent hosting providers should be able to disable those wp-cron calls by default and then run something like wp cron event run --due-now using an actual cron job or a systemd service, but that is extremely rare.
8. Make WordPress immutable by default
WordPress assumes to have write access to itself, which surely enables automatic updates and such but also allows many security vulnerabilities to expand into being code injections, meaning that a single security vulnerability in a single plugin can enable a bad actor to break into your site.
If we change the recommendation to making the filesystem read-only, apply some creative file ownership tricks and then make it the role of hosting providers to provide these updates — wherever that is a possibility — using tools such as WP CLI, then we may be somewhat closer to an immutable setup.
But what about static files such as images that are uploaded from the Media Library?
Many web frameworks account for keeping static assets in a cloud-based storage bucket while WordPress still relies on using the local filesystem (which is fine for development but not as fine for high performance production instances and CDNs).
There are 3rd party plugins out there for this but adding this capability into the WordPress core could move the stack one step toward immutability in addition to changes in how we approach updates.
9. Facilitate the use of PHP composer packages without hacks
Using PHP Composer packages when developing WordPress plugins is currently an absolute nightmare and unfortunately I expect it to remain so in the future.
This in addition to the emphasis on backwards compatibility which prevents “new” PHP features from PHP 7 to make it into the WordPress space — has resulted in an unnecessary and unfortunate divide between the WordPress community and the PHP developer community.
Composer is used in the WordPress core itself to facilitate testing and development, but last time I checked, everything that WordPress includes and requires at runtime is done so locally.
Say a certain plugin loads a specific version of a specific Composer package and another one requires a different version of the same plugin without namespace prefixing techniques. This will result in an unexpected conflict between them.
There are tools out there that edit each autoloaded file to change its PHP namespaces use or prefix class names in an attempt to prevent conflicts such as Imposter, but it is awfully messy and may cause things such as PHP traits to break. This is how the plugins that currently use Composer packages include them.
However, there needs to be a way for WordPress to enable plugins to autoload their runtime dependencies using Composer in a tidier way than this.
I suggest doing something like having WordPress itself or a WP sanctioned tool parse the composer.json file for each plugin, resolve conflicts between them and then autoload the required packages from the WordPress root, enabling plugins to share Composer packages.
However, this is a complicated thing to get right, and with the BDFL of WordPress not being a fan of Composer at all, the rewards of volunteering on this may be questionable at best.
10. Specify minimum requirements for hosting providers
The WordPress system requirements and documentation look okay to the untrained eye in terms of performance and security.
I think the documentation and instructions provided by the WordPress project itself are great for setting up a local development environment or something internal for your home or workplace on a repurposed server or a Raspberry Pi or for getting around the limitations of generic LAMP stack hosting that comes for free with ISP subscription and computer equipment rent-lease contracts.
However, the WordPress project itself should be much more explicit about what is needed for a high performance and high quality web hosting solution and those of us who are involved in and interested in that should not have to learn those ropes from a 3rd party blog like this one.
Here’s a couple of things that can be added to a list of recommendations:
- A set of standard and open performance benchmarks to test the performance of WordPress hosting plans
- Clear information about the amount of memory and CPU power for a response time of less than 500 ms, without a page cache and with or without demanding plugins and themes
- Object caching as a minimal requirement for hosts (Memcached or Redis)
wp-cronas a background process on the server side, not from an ajax request- Static asset URLs pointed to a CDN (all static content, not just images and videos)
- Application monitoring that follows a minimal set of features (i.e. not just run-off-the-mill log analysis, but something closer to New Relic and AppSignal).
While we’re at it, we should not refer to this as a list of recommendations, but as a set of requirements for something like an official WordPress quality certification.
Furthermore, if the International Cycling Federation (UCI) can charge bike manufacturers a small amount for a certification sticker that goes under the clear coat of every certifiably compliant competition bike frame, then surely it would be possible for the WordPress Foundation to issue a set of certifications for hosting providers or specific hosting plans based on such a criteria, to be renewed on a bi-annual basis.
How about that?