By Brent Toderash
Published January 6, 2025
≅3,883 Words
on Future of WordPress

Note: When this post was first drafted, I was slightly more (though not overly) optimistic that Matt Mullenweg might participate in this sort of roadmap. I have not edited the post to reflect his recently-stated unwillingness to collaborate, as it’s still a path that’s open, though perhaps not for long.

First, Context

On December 10^th, arising from an in-depth discussion on Post Status Slack, Hendrik Luehrsen posted “WordPress isn’t WordPress anymore”¹ A couple of days later, Joost de Valk posted some thoughts on “WordPress, and what should be on its roadmap“, which referenced and agreed with Henrik’s post.² About a week later, Morten Rand-Hendriksen posted some of his thoughts.³ The same day, Brian Coords offered Another Post About What WordPress Core Should be Doing as a followup to Joost’s post, linking to other sources with similar concerns about the  impact of Gutenberg and the future of WordPress, summarizing that they show “concern that WordPress has lost its direction in the last few years.”⁴ This is a small sample of all that’s been said by many people, but is representative of where we’re at now, from some well-known people in the community.

Canonical Plugins Reimagined

Canonical Support

In his roadmap post, Joost says that WordPress is “slow & technically stagnant,” implying poor technical decisions while calling out its accumulated technical debt,⁵ with no plan to repay it through a modernization of WordPress Core. Within the community, there is widespread agreement Core needs to address its technical debt.⁶ Moreover, the approach to Core and what belongs in it has shifted over time.

Hendrik suggests that WordPress has moved from a lean and flexible Core “with boundless extensibility” to adding features that feel “increasingly opinionated,” which in the past would have been plugins. In effect, this is a shift from an opt-in to an opt-out philosophy. Joost quotes approvingly from Hendrik’s post:

Historically, WordPress didn’t try to be everything for everyone. Its lean core and robust ecosystem allowed it to meet a wide range of needs without dictating how it should be used. Developers could tailor it to clients. Hobbyists could start small and scale up. Agencies could rely on its flexibility to create bespoke solutions. WordPress provided the tools, but the user always defined the experience.

Hendrik advocates a return to using more canonical plugins, which Matt is on board with.⁷ Brian Coords spoke up earlier this year for canonical plugins,⁸ listing several he’d like to see. In his response to Hendrik’s call for a return to canonical plugins, he cites an interview he had just done with Felix Arntz, in which Felix suggests it’s hard to get wide adoption for them because they aren’t in core. Brian notes this same argument has also been made for keeping Gutenberg in core.⁹

From my perspective, adoption is an entirely different problem that can be addressed with a different solution, such as shipping the product with canonical plugins included, the way it already includes Akismet and Hello Dolly. To be fair, these are two plugins that can be deleted on most installs, but Akismet wouldn’t have had its level of success without having always been included with every WordPress install. By shipping canonical plugins with core, new performance features now handled this way would also see better adoption.

I echo the call for more canonical plugins, and would up the ante by redefining what they are to make more and better use of them. As for Gutenberg, I believe it should be a canonical plugin rather than part of Core, with Core being modified as necessary to support it while not actually including it. This means users who prefer Elementor or Beaver Builder or Divi or any other page builder would have the option of running it without having Gutenberg running in the background.

Taking Canonical Plugins a Step Further

Redefined, canonical plugins should not be short-lived, but maintained indefinitely to support a modular core that can be variously configured to meet any use case in the most efficient way possible. This includes removing things that are now in Core but are not in use on a high enough percentage of sites to warrant having them on all sites. This approach facilitates moving toward a more modular architecture for Core to return it to its lean-approach origins.

Pushing the adoption of canonical plugins is a different issue from the philosophy of using them as a build approach. Historically in WordPress they’ve been used to develop and evaluate features for possible inclusion in Core, but by streamlining core and forcing some existing features into canonical plugins, the philosophy changes, with canonical plugins always remaining plugins, never included in core.¹¹ Where modifications to core are needed to support canonical plugins, they would most likely be done through changes to hooks and filters. A new model for these plugins changes how they are managed and how they are viewed: a typical WordPress site would always have one or more canonical plugin enabled, with only highly-customized sites running on Core alone.

The idea of “drop-ins,” which I refer to here conceptually as a “modular core” is not new, and although it is not frequently used outside of caching, is already part of WordPress’ architecture.¹² What I’m advocating is therefore not revolutionary, but an appeal to make increased and better use of two things that already exist in Core architecture and in our conceptual framework for WordPress.

I have many thoughts about the path forward, centering around what I would call a “Lean-Core Approach.” With both effectively being called for broadly by the community, I view canonical plugins together with a lean-core approach as having the ability to support and unite (as much as we can) a fractured community. At the same time, it’s the best way of achieving the objectives that so many of us share – including Matt. A lean-core approach would leverage a redefined version of canonical plugins and potentially expand the use of drop-ins to achieve a more modular architecture for Core. I’ll outline the merits of this approach and then address some of the additional considerations necessitated by this approach.

Five Canonical Considerations

Dependency Management

With canonical plugins establishing functions and features which may be required by other standard plugins or themes, a long-requested feature request must be designed and delivered: dependency management. More than one model exists for this, but it would be one area where Core needs to be extended before it can be pruned. A dependency API could allow plugins and themes to stipulate what modules or plugins it relies upon; these could be installed if missing, activated, and loaded in priority order. Past recommendations have been made for how this would work, but none have ever had the traction or support from the right decision makers to implement it. Doing so also allows safely including a framework as a plugin dependency.

Defining Canonical Plugins

Defining what canonical plugins should exist requires a roadmap and a philosophy. This begins with a planned roadmap for removal of identified Core features to newly-established canonical plugins. Some features are more easily extricated than others, and a maintenance team needs to be commissioned for each canonical plugin as well as for Core, so this will not be a quick process.

New canonical plugins might be made from old ones, revived and refreshed, along with entirely new ones. Without the assumption that the feature plugin would be merged into Core, each could serve a smaller subset of users. There will be certain use cases that the ecosystem is already meeting well, either with free or non-free plugins. Provided the necessary range of requirements is being met with quality solutions, there would be no need for an official core-maintained plugin.²⁰ On the other hand, if none of the solutions were free and adoption was hindered as a result, there may exist reasons for a canonical plugin to be created to fill the gap or to add options for an underserved niche. This approach helps further stabilize the wider ecosystem, since it reduces the likelihood that an added Core feature would disrupt a new venture by rendering it irrelevant, even unintentionally. These observations indicate the need for a policy or philosophy about which canonical plugins are needed, and under what circumstances.

Existing features in core could similarly be removed to canonical plugins based on usage: if only 50% (or some suitable threshold) of sites are using the feature, move it out of core to a canonical plugin. For things that are deeply embedded, begin by shipping with it disabled by default and allow re-enabling it. This approach could be taken for the theme/plugin editor, the commenting feature, emojis, xml-rpc, A “remove by disabling” approach has been used before, such as with the blogroll feature, which remains in core but must be enabled with a simple bit of code. Allowing it to be enabled on a settings page is better for users, and removes the need for a very simple plugin to be listed in the plugin directory, looking old and unmaintained but having no actual need for maintenance as it simply applies a filter. Most modern browsers can serve their own emojis, a “feature” which is just cruft in core as far as I’m concerned.

Potential Middle Ground Between Standard & MU-Plugins

Currently MU-Plugins²¹ are implemented in a manner that requires them to be contained in a single PHP file which is executed without being enabled. While there are a number of advantages to this, it means that more complex features aren’t as well-suited to using this model. As such, modular core or canonical plugins may require a slightly different architecture within core, as they should not be easy for users to disable, and some should perhaps not be viewable to users apart from any options pages they add.

Hooks, Filters, & Documentation

One can still find many deprecations in the documentation for hooks, filters, and functions. These would need to be reviewed, possibly extended, but providing an opportunity to drop deprecated arguments. With canonical plugins, modern Core refinements, and drop-in modules, a significant documentation rewrite will be required. Each canonical plugin will also require documentation of its own, as they could also be somewhat extensible; this would begin with a reorganization of existing documentation for it to follow the functions out of core and into the canonical plugin.

Breaking Changes Versus Backward Compatibility

Significant changes to the architecture of WordPress Core and steps to modernize it will inevitably introduce some breaking changes. It’s too early to speculate what those might be, but deprecations can be planned and managed. There are numerous functions in Core now that continue support for deprecated features or methods. Many of these could be removed as Core is modernized and further modularized for a lean approach.

Given the state of the WordPress plugin repository and the need to cull older plugins, it’s not unreasonable to suggest that around the 22-year mark, it’s reasonable to introduce some breaking change in the interest of modernization. For the most part, packages that are dropped for not making updates to support certain changes will be ones that are also targeted for removal from the repository for other reasons. Over the long term, commitment to backward-compatibility is good, and should be maintained into the future, even as a line is drawn that will force the issue for many, including a number of users running outdated sites.

Released in January 2015, the 4.1 branch was updated in October 2024 to 4.1.41, meaning that almost a decade’s worth of major releases — 26 of them — are being maintained. This is twice the expected lifespan of a website, which is a good thing, but there are times when you need to take a larger step forward. If this means that upgrading requires an export/import process, conversion script needing a developer, or a multi-step upgrade to move from 4.x to the current branch, that’s probably okay — those site owners have been coasting for almost a decade. Paying a developer for an hour or two to convert the site shouldn’t be a big ask, if it comes to that. Handled on a well-planned roadmap, even that can perhaps be avoided. But sometimes it’s okay to draw a line.

Looking Forward

At the agency I co-own and operate, we make what we’ve called an industry-leading guarantee: if a WordPress core update breaks your site within the next two years (6 major releases), we’ll fix it at no cost, provided we’ve been maintaining and updating it over that timeframe. I think it’s a good guarantee, and doing things “the WordPress way” has so far meant not being called on it. I’m currently hesitant to keep extending the offer in the current climate, but I like to think that despite the huge course-correction I am recommending (and earnestly hope to see) for WordPress, the end result will be worth it, even if I need to devise an upgrade path for a couple hundred websites we’ve already built in order to minimize warranty costs. I offer this simply to illustrate that I’m not saying any of this lightly.

In May of 2004, as WordPress 1.2 was being released, Moveable Type 3.0 was released with licensing changes resulting in significant price increases. Six Apart, the platform’s owner, had offended its users, and they weren’t having it. They didn’t just flee the Moveable Type platform, they fled to open source alternatives. As a happy accident, WordPress was a major beneficiary of the exodus, setting it on the growth course it’s been on for over 20 years. Its users — its community — have been offended, and if they don’t see signs of change during 2025, they’ll be gone, to the happy benefit of some other platform’s market share.

Near the end of 2025, we’re expecting to see the release of version 7.0, the third major releases from now. No matter what happens next, the landscape is going to look different by then, but there is a way forward that unites the community rather than fracturing it further. It’s a path that opens up new possibilities for WordPress Core that makes it even more powerful while holding it more loosely. Sadly, if it happens this way, I don’t think we’ll be calling it “WordPress” anymore. More on that to follow.

Where do You Share?

• Share on Bluesky
• Share on Facebook
• Share on LinkedIn
• Share on Reddit
• Share on X
• Share on WhatsApp
• Share on Pocket
• Share on Threads

Notes

1. Hendrik Luehrsen, “WordPress isn’t WordPress anymore“, December 10, 2024. Link is to his English version; the original German post is linked from there. I showed up a bit late, but read and participated in some of the referenced PS-Slack discussion, and can attest to the fact it was very insightful and thoughtful. Eventually someone pointed out with some surprise how amicable it was. The tone was indeed constructive and respectful, which stands out given there was a fair amount of critique with the discussion of numerous issues in the thread. I infer from this that there’s a significant shared hunger for constructive criticism leading to a healthy course-correction for WordPress core.⤷
2. Joost de Valk, WordPress, and what should be on its roadmap, December 12^th, 2024. Joost was also active in the PS-Slack discussion. Joost builds on an analysis of market share stats, an area in which he’s well-versed. He compares WordPress with some popular SaaS platforms and the block editor (Gutenberg) with Elementor. It would be interesting to see a few other page builders compared as well, but the point is made: Elementor’s adoption has been considerably stronger than Gutenberg’s, and had Elementor not been available when it was, WordPress market share would likely have declined before Gutenberg became available, something which Joost contends specifically. It will be instructive to note that Elementor – a third-party plugin – effectively preserved WordPress market share for several years; perhaps not single-handedly, but as a leader among a specific group of third-party plugins.⤷
3. Morten Rand-Hendriksen, After WordPress, December 20, 2024. This is one of several responses triggered by Matt Mulleweg’s announcement on December 20^th. He begins with an explanation of why he’s commenting at all, as after a decade of being heavily involved, as he says, “I walked away from the WordPress Open Source Project in 2019 due to irreconcilable disagreements around governance, ethics, and community equity between Mullenweg and myself.” Morten was an active member of the WordPress community until 2019. He has spoken about FLOSS governance quite a bit since then, and suggests that Matt (and WordPress) may have crossed the Rubicon on October 12, 2024 with the forking of the Advanced Custom Fields (ACF) plugin.⤷
4. Brian Coords, Another Post About What WordPress Core Should be Doing, December 20, 2024. He also contends that some of the features in Gutenberg are not yet production-ready, but are resolved by other popular third-party tools found in plugins or block themes.⤷
5. If the term or concept is unfamiliar, I wrote a basic client-focused introductory piece on the subject a few years ago when we needed to upgrade a number of older sites built by third parties on ColdFusion. See Brent Toderash, Technical Debt & Why it Matters, October 2021.⤷
6. So far nobody has offered an account of what this entails, but the fact that its code base stretches back to b2 founder Michel Valdrighi in 2001 suggests there’s a need to revisit it more foundationally. Core presently seems to be largely in “maintenance mode” to address newer versions of PHP or MySQL. While the code has obviously evolved considerably, many parts of its architecture are unchanged. Gutenberg excepted, Core hasn’t seen major upgrades within the past 8-10 years. Minor upgrades have been made, but while I’m apt to celebrate things like revision history support for post meta, it’s hardly revolutionary.⤷
7. Comment on Hendrik’s post; he also advocated for them back in September 2022.⤷
8. Brian Coords, In Support of Canonical Plugins, February 2024⤷
9. I have to observe that this is anti-competitive behaviour, such as when Microsoft embedded its browser into its operating system in order to gain adoption and stamp out Netscape. The DOJ took notice: this is something you can do when you don’t have a market share that approaches monopoly conditions. I might wonder aloud if page builders whose market share has eroded precipitously to Gutenberg have a claim here if they weren’t concerned about reprisals.⤷
10. Ernst F. Schumacher, Small Is Beautiful: Economics as if People Mattered, 1975⤷
11. One plugin I like and have used and extended a number of times is WP Job Manager, (wpjobmanager.com) which is officially maintained by Automattic. Until recently, this meant I was not overly concerned about future support, but it’s a good example of a common need that doesn’t belong in core. It might fit one of the past definitions of “canonical” in that it’s maintained by the WordPress team, but I see no reason why certain others couldn’t be maintained by the community or by an external corporate interest.⤷
12. See Kevin Dees, What are WordPress Drop-in Plugins?, April 2020 and (for example) _get_dropins() – Function in the WordPress Developer Documentation.⤷
13. Antoine de Saint-Exupery, The Little Prince, 1943⤷
14. Technically this is already supported. Quite a few years ago, I recall work toward supporting PostgreSQL, and for a time it was unofficially supported, at least to some extent. I’m not sure offhand whatever happened to that effort, but a lean Core could facilitate a comeback.⤷
15. I have previously endorsed the concept of multiple forks of WordPress, enabling the creation of different “distributions” in the same way that Linux works now. I stand by this, however I believe that a lean modular core is not only the best path forward for WordPress, it’s the one which enables the establishment of many variants or distributions built around the same Core, minimizing the need for hard forks to exist at all.⤷
16. The concept of network value is important to the economics of FLOSS. More users means a more valuable network able to support a larger and healthier marketplace with a variety of business models⤷
17. I will say that I personally need a bit of convincing that this is actually a good idea, and why. Part of this stems from an undefined concept of “web OS”, but I do believe it can be a good framework (and better than it is currently) or platform for various CMSs and web apps, and to the extent these ideas overlap, there are common changes needed for Core to support it.⤷
18. Anecdote time: back in 1998 I set up an underpowered PC with “98Lite”, a project that installed Windows 98 (or ME) but removed the deeply-integrated Internet Explorer and replaced it with the Windows 95 Shell. I offer this simply to point out that it’s always been a bad idea to integrate too many things too tightly with the core of an operating system, because some users want something else. On my Linux desktop, I’ve always been able to run the window manager or desktop environment of my choice, which is a much better model.⤷
19. I also question the relentless drive for increased market share for WordPress. Nobody in the community needs WordPress to grow beyond 62% of the CMS market into monopoly territory. I reject out-of-hand the idea that a monopoly can’t exist with open source software. The GPL is not market-focused, and its mere presence neither suggests nor precludes the establishment of a monopoly.⤷
20. I realize I’m conflating the idea of plugins and canonical plugins a bit here, so hopefully it doesn’t cause confusion. I’d note here that as Joost implied, Elementor and the like were perhaps doing Gutenberg’s job well enough, as Gutenberg was not launched into an optionless void.⤷
21. For background, mu-plugins are an alternate type of plugin that cannot be disabled. “MU” is defined as “Must-Use”. This was introduced when WordPress Multisite, or “Multi-User” (WP MU) was merged into WordPress Core at version 3.0.⤷