For years, WordPress has been the go-to platform for building websites of all kinds. It empowered both users and developers with a lean core and a vibrant plugin ecosystem for endless customization. Lately, however, I’ve started to feel that the balance between simplicity and flexibility is tipping in the wrong direction.
Some troubling numbers back this concern. Contributor churn has reached a record high. WordPress growth has stagnated for several years. The adoption of Blocks and Full Site Editing (FSE) has also been slow, with FSE adoption being almost nonexistent.
I’ve been using WordPress since 2006, working professionally with it since 2010, and building client sites with the block editor since 2017. Over the years, I’ve celebrated its growth and supported its vision. Recently, though, I’ve begun questioning whether its current path truly meets the needs of its diverse users and the broader community that sustains it.
Trends, Not Drama
Although this article coincides with the recent WP Engine drama, the message is unrelated. These reflections could have been written well before that situation unfolded, as the issues stem from long-standing trends and observations about the WordPress project’s direction.
What prompted these thoughts was a rich discussion with brilliant minds on the “Post Status” Slack. Our initial focus was the developer experience of working with Gutenberg. However, the conversation soon expanded into a deeper exploration of WordPress’s identity and future, ultimately inspiring this post.
Thanks to Simon, I’m able to share these reflections here as a guest on KrautPress. If you’d prefer to read this in German, the original version is also available on WP Munich.
The Essence of WordPress:
A Lean Core with Boundless Extensibility
For much of its history, WordPress had a clear sense of purpose. It began as a blogging platform but quickly grew into a system with a lean core. This core excelled at publishing and managing content while leaving the rest to an expansive ecosystem of plugins and themes. This modular approach allowed users to create exactly what they needed. Whether it was a personal blog, a business website, or a complex e-commerce platform, WordPress could adapt.
This lean core, paired with boundless extensibility, wasn’t just practical—it was a philosophy. It gave developers, agencies, and hobbyists the freedom to tailor WordPress to their needs. They weren’t burdened by unnecessary features—well, almost.
For developers, this model encouraged innovation. A thriving plugin ecosystem made it possible to turn great ideas into distributable plugins. Many multi-million-dollar businesses began this way—examples include Yoast, WooCommerce, and Elementor. Users benefited too. They gained access to a nearly endless array of solutions for countless problems and use cases. This symbiosis between core and ecosystem is what turned WordPress into the powerhouse it is today.
Flexibility at Its Core
From a user’s perspective, WordPress’s flexibility was its greatest strength. Out of the box, it provided a stable, lightweight foundation. But with the addition of plugins and themes, it could become anything—an online store, a portfolio site, a news platform, or even a full-blown application. The simplicity of its core ensured accessibility, while the ecosystem ensured scalability.
This balance was the heart of WordPress’s identity. A lean core meant that users were not forced to deal with features they didn’t need. Instead, they could build their ideal website by choosing only the tools and functionalities that suited their requirements.
In this way, WordPress became a platform that served everyone—beginners, seasoned developers, small businesses, large enterprises, and everyone in between. It was an ecosystem where diversity of use cases was a feature, not a challenge.
The New Direction:
Core Features vs. Plugin Territory
In recent years, WordPress has started adding features to its core that feel increasingly opinionated. In the past, these would have been better suited as plugins. Examples include Lightbox functionality, Duotone Filters, and Footnotes, along with proposed blocks like the Marquee Block and Slider Block. While these features have merits for specific use cases, their inclusion in the core raises serious questions about WordPress’s evolving identity and direction.
These features mark a significant shift away from the lean, modular philosophy that once defined WordPress. They address niche functionalities or design trends but are bundled into the core as if they are universally needed. For many users who depend on WordPress as a stable, flexible platform, these additions feel unnecessary and even intrusive.
Additionally, many of these features are introduced half-baked. It’s not just their inclusion that causes concern but also their critical flaws. Issues like poor documentation, inconsistent behavior, and compatibility problems create headaches for users and agencies. Developers often have to patch or work around these problems quickly to meet client expectations, adding more frustration.
Consider Duotone Filters as an example. While visually appealing, they serve a narrow audience focused on design-heavy projects. Similarly, the Marquee Block or Slider Block might interest users seeking flashy visuals but are not essential tools for most websites. These are precisely the kinds of functionalities that plugins have historically provided.
Valuable Features, Wrong Place
The inclusion of such features doesn’t just clutter the core; it also disrupts the ecosystem. For years, third-party developers built plugins to address these specific needs, creating thriving businesses and innovative solutions. By incorporating these functionalities directly into core, WordPress inadvertently undercuts the plugin ecosystem that has always been its lifeblood. Plugin developers are left with fewer opportunities to innovate, and users lose access to a diverse marketplace of competing solutions.
Moreover, these features add an ongoing maintenance burden to WordPress itself. Every block or feature added to core becomes a permanent responsibility for the project. It requires updates, bug fixes, and compatibility testing with every release. For a project already juggling the complexities of backward compatibility and evolving web standards, this is not a trivial commitment. Adding to this challenge is the ongoing contributor churn, which leaves fewer hands available to manage this growing workload. As contributors leave or reduce their involvement, the long-term sustainability of maintaining an ever-expanding core becomes an even more pressing concern.
The method of introducing these features also reflects a shift from WordPress’s historical opt-in development philosophy (e.g. theme_supports) to an increasingly opt-out model. Traditionally, core provided a lean foundation, and users could extend functionality as needed through plugins. By contrast, the opt-out approach bundles specific functionalities into core by default, assuming universal relevance, and places the burden on users to disable or work around features that may not suit their needs.
It’s not that features like Lightbox, Footnotes, or Duotone Filters lack value—they absolutely do for the right audience. But their place is in the plugin ecosystem, not in core.
The Case for Canonical Plugins
If there’s one idea that could help WordPress strike a balance between core functionality and extensibility, it’s the concept of canonical plugins. These are plugins developed and maintained by the WordPress community, offering high-quality solutions for specific or niche use cases. By adhering to the same standards as the core, canonical plugins provide an official but optional way to extend WordPress without overburdening its foundation.
Including highly specific features like Lightbox, Duotone Filters, Footnotes, or Slider Blocks directly in the core creates challenges that could be avoided by using canonical plugins. Features like these often address particular audiences or design trends, which may not align with the needs of all users. Keeping them as plugins allows WordPress to maintain its lean and flexible core while still making these tools available to those who find them valuable.
A Sustainable Path forward
Canonical plugins allow WordPress to address specific needs without imposing those solutions on everyone. A lean core could work in tandem with carefully developed plugins to meet the expectations of various user groups, all while preserving the platform’s flexibility. This approach also creates opportunities for developers and the broader ecosystem to innovate without being sidelined by features baked into core.
This concept also opens up a future where a lightweight WordPress core can remain the foundation for tailored experiences. Instead of bundling everything into one system, a lean core combined with canonical plugins could cater to diverse needs without burdening the platform with unnecessary complexity. Users could opt for the core as it is or add curated extensions that suit their specific goals, ensuring that WordPress remains accessible, scalable, and relevant.
Canonical plugins also reduce the strain on WordPress’s development resources. Adding opinionated features to core brings a long-term maintenance burden, requiring constant updates and compatibility fixes. Plugins, by contrast, provide a modular solution that allows for easier iteration and even retirement if a feature’s relevance fades. This keeps core manageable while giving the community the tools it needs to meet evolving demands.
The Bigger Picture:
Who Is WordPress For?
At its core, WordPress has always been about empowering users. From the early days of personal blogs to the sprawling enterprise solutions we see today, WordPress served a diverse audience by being adaptable, accessible, and open. But recent shifts in its development raise a fundamental question: Who is WordPress really for?
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.
Today, that sense of adaptability feels at risk. The inclusion of increasingly specific and opinionated features into core suggests a move toward a more prescriptive vision of what WordPress should be. These decisions impose assumptions about what a WordPress site should look like and how it should function. This risks alienating developers and users who value WordPress for its neutrality and extensibility.
I understand that a “feature complete” WordPress core—one that can serve as an all-in-one solution for users—would be highly beneficial for a business like WordPress.com. Offering a platform that works seamlessly out of the box, without the need for additional plugins, aligns perfectly with the needs of a managed hosting service. However, for the open-source WordPress project, this approach is highly detrimental. It not only disrupts the delicate balance between core and ecosystem but also imposes limitations on the adaptability that has always been WordPress’s greatest strength.
The Hunt for Clarity
The question becomes not just “Who is WordPress for?” but also “Who gets to decide that?” When new features are added to core, they inevitably reflect the priorities of those making the decisions. Are these priorities aligned with the broader community, or are they shaped by the specific needs of a subset of stakeholders? Decisions that prioritize certain use cases can inadvertently limit the platform’s ability to meet others’ needs.
This tension affects more than just developers. It ripples out to users who rely on WordPress for its reliability and stability. Every new feature introduces complexity, maintenance challenges, and the potential for unintended consequences. Users who don’t need or want these features are left to navigate a core experience that feels increasingly cluttered, while the broader plugin ecosystem—historically WordPress’s strength—is weakened by features absorbed into core.
WordPress’s power has always been its ability to serve a wide array of users without forcing any particular vision onto them. But as the platform evolves, it risks losing sight of this inclusivity. The ongoing challenge is to ensure that WordPress remains adaptable, modular, and community-driven—a platform that serves everyone, not just the loudest voices or the most visible use cases.
Call to Action:
Rediscovering WordPress’s True Identity
WordPress is at a crossroads. As the platform evolves, it’s crucial to reflect on the principles that initially made it successful: a lightweight, adaptable core and a thriving ecosystem of plugins and themes. These elements empowered users to create their vision on their terms. However, recent development trends risk steering WordPress away from this foundational philosophy. Now is the time for the community to assess its direction and ensure the project’s future stays true to its roots.
WordPress’s strength has always been its ability to serve a vast and diverse audience without dictating how it should be used. This balance was achieved by offering a core that was simple, stable, and extensible. It provided a solid foundation that allowed an entire ecosystem to thrive. By refocusing on this balance, WordPress can reclaim its identity as a platform that serves everyone.
This isn’t just about resisting unnecessary complexity in the core. It’s about embracing strategies and tools that enable the project to grow while respecting both its history and its future. Canonical plugins are one such strategy. They offer a way to innovate and address niche needs without overloading the core with features that not all users require. By adopting this approach, WordPress can continue to evolve while preserving the adaptability and modularity that have always set it apart.
Shaping the Future
The community must also engage in open and transparent conversations about the direction of the project. Decisions about what belongs in core and what should remain in the ecosystem must be made with care, ensuring they reflect the needs of the broader user base rather than a specific subset of stakeholders. WordPress has always been a collaborative project, and its future depends on contributions and perspectives from across its community.
For developers, agencies, and users who rely on WordPress every day, now is the time to voice concerns and advocate for a thoughtful, restrained approach to core development. WordPress doesn’t need to be everything for everyone—it needs to remain flexible enough to allow everyone to shape it to their needs.
Rediscovering WordPress’s true identity doesn’t mean rejecting change or innovation. It means pursuing them in a way that honors the platform’s foundational values: simplicity, extensibility, and community-driven growth. By doing so, WordPress can remain a tool that empowers users and developers alike, continuing to thrive as the world’s most popular and versatile content management system.
The future of WordPress is not set in stone. It’s something we create together. Let’s make sure it’s a future that stays true to the principles that have always made WordPress extraordinary.
Links
Make.WordPress.org: Contribution Health Dashboards
WP Tavern: How a Munich-based Game Studio is Using WordPress and Gutenberg to Power Its Website
Thanks for this writeup Hendrik 🙂
I certainly agree with quite a few of the points you are making about which features get priority vs which ones don’t etc.
But I think the only possible solution to this problem is missing from here. The only way for anything to change in this regard is with meaningful investment & code contributions by other players than Automattic.
It’s easy to raise concerns and to voice opinions of how it should be. And as you well know I myself do a fair share of that.
But at the end of the day, the decisions and prioritization happens by the people who show up in code with contributions and feedback on tickets as they are in flight.
To me this also doesn’t have anything to do with the current drama. I’ve long before been a big advocate for Agencies in particular being more active in core. To date I’ve not really seem much movement here. And looking at the top 100 contributors to the gutenberg repository (https://github.com/WordPress/gutenberg/graphs/contributors) there currently is one other person from the agency world besides myself on the list. In order to change the balance this number needs to change. And it can only change if we start to more meaningfully contribute back time of people that can actually ship things.
Thank you, Hendrik. I appreciated hearing your thoughts and agree with the approach of a lightweight core that serves the majority with canonical plugins that serve more targeted needs. It just makes sense.
Let’s wave a magic wand for a moment and assume the project direction supports that approach… how would you propose that we walk back some of the things that have already been added to Core and separate them out into feature plugins? In the spirit of backward compatibility and non-breaking changes to Core, I’m thinking through what that process might involve and…it’s not simple.
Maybe my question is too tactical since your post is philosophical in nature, but I’d love to hear your thoughts.
The process of rolling back features from WordPress Core isn’t entirely uncharted territory. Look at examples like the Classic Editor or the Link Manager. Interestingly, these weren’t fully removed—they merely introduced feature flags through plugins. This highlights the need for a structured method to properly extract features while ensuring backward compatibility.
I can imagine working with two concepts WordPress already employs: Bundled Plugins (like Akismet) and Required Plugins. The process could unfold in three phases:
1) Plugin Rollout
Initially, the feature is extracted into a dedicated plugin, which comes bundled with new WordPress releases. During this phase, the plugin is a required plugin, meaning it’s activated by default on all installations to ensure continuity.
2) Feature Flag
Once the plugin achieves broad adoption, the “required” status is removed. WordPress still bundles the plugin, but users gain the ability to deactivate it. Core would use a feature flag to detect if the plugin is active, ensuring that sites without the plugin don’t load the feature. Importantly, the underlying code still resides in Core for now, preventing site-breaking changes.
3) Code Extraction
After sufficient testing and adoption, the feature’s code can be safely migrated out of Core and fully into the plugin. This phase would likely involve a grace period where the code exists in both places, similar to how Gutenberg is still handled today.
By the end of the third phase, all pre-existing installations retain access to the feature through the plugin. Meanwhile, new users have the choice to opt-in or out. This method ensures minimal disruption, respects backward compatibility, and offers a clear path forward for decoupling features from Core.