WordPress Forgot Why WordPress Won

WordPress won because it put power in the hands of the community.

Part of the series starting with WordPress for Blogs Is Dead.

That is the part people keep forgetting. WordPress did not win because core tried to satisfy every possible user, every possible workflow, every possible business model, and every possible edge case. It won because core handled the things almost everyone needed, then gave developers, designers, agencies, plugin authors, theme authors, hosting companies, and weird obsessive problem solvers enough power to build the rest.

That was the deal.

WordPress said, in practice if not always in those exact words, “This is what almost everyone needs. We are going to do a solid job with that. Then we are going to make the system flexible enough for talented people to extend it into whatever the next person needs.”

That was genius.

Not because WordPress itself was perfect. It was not. The database schema was never beautiful. The template hierarchy was not some divine object of software architecture. The plugin ecosystem was always chaotic. The admin was always a little weird. Anyone who has built serious WordPress sites has spent part of their life staring at hooks, filters, serialized options, plugin conflicts, and mystery behavior that made them question every career decision that led them there.

But the model worked because WordPress did not need to be perfect.

Core did the common things. The community handled the specific things. The more WordPress trusted that model, the stronger it became.

A blogger could publish. A business owner could edit a page. A developer could create custom post types, custom fields, plugins, themes, integrations, and admin workflows. A plugin author could solve one problem well and reach millions of sites. An agency could build a repeatable practice around it. A hosting company could support it. A designer could make it feel like something completely different from the default install.

WordPress became dominant because it was a platform for the community to build on, not because core tried to become every product.

That distinction matters because the current direction feels like WordPress has forgotten it.

Now WordPress wants to be the editor, the page builder, the design system, the collaboration tool, the enterprise CMS, the AI integration layer, the application platform, the site builder, and the answer to every product trend happening around it.

That is not how WordPress won.

That is how WordPress gets heavy.

Core was supposed to stay focused

The frustrating thing is that WordPress already has the right philosophy written down.

The official WordPress philosophy page says core should be “clean, lean, and mean.” It says the core should provide features that 80% or more of end users will actually appreciate and use. It says the plugin and theme system exists so people can find the remaining 20% that fits their needs.

That is not just a nice slogan. That was the operating model.

Core did the common things. Plugins did the specific things. Themes handled presentation. Developers filled the gaps. The community created the long tail. WordPress stayed broadly useful because it did not need to solve every problem in core.

That balance was never perfect. WordPress has always had messy edges. Anyone who has built real sites with it knows the pain. Custom fields were awkward. Metadata got abused. Options tables became junk drawers. Plugins fought each other. Themes did too much. The editor changed underneath people. Performance was always something you had to care about.

But the model worked because WordPress itself was still understandable.

You could explain WordPress to someone.

It was a publishing system with posts, pages, themes, plugins, users, and media. Developers could extend it. Normal people could use it. That clarity mattered.

The more WordPress tries to become everything, the harder it becomes to explain what it actually is.

The community was not an accessory

The community was not a nice extra attached to WordPress. The community was the product advantage.

WordPress core could stay relatively focused because the community handled the long tail. That was the whole point. Different people needed different things, and WordPress did not have to flatten all of those needs into core because plugin developers, theme developers, agencies, freelancers, and hosting companies were already solving them.

That is what made WordPress feel endless without making core responsible for everything.

• Need SEO controls? Plugins handled it.
• Need custom fields? ACF handled it.
• Need forms? Plugins handled it.
• Need ecommerce? WooCommerce handled it.
• Need multilingual content? WPML, Polylang, and others handled it.
• Need membership functionality, redirects, custom post types, migrations, caching, image optimization, security hardening, analytics, weird client dashboards, or some cursed integration with a vendor API from 2009? Someone in the ecosystem probably solved it, or a developer could build it.

That was not a weakness.

That was the architecture of the community.

WordPress core did not need to chase every feature because the ecosystem was already the feature engine. Core needed to be stable, flexible, understandable, and extensible enough for the rest of us to do the specific work.

When WordPress starts pulling more and more product categories toward core, it sends the wrong signal. It says the project trusts central planning more than the ecosystem that made it dominant.

That is how you turn a community-powered platform into a bloated product committee.

That is why the current direction feels so aggravating.

When core starts chasing big platform features, it can look like progress from the inside. From the outside, it can feel like WordPress is undervaluing the exact ecosystem that made those features unnecessary in core in the first place.

Real-time collaboration can be a plugin. AI provider integrations can be plugins. SEO metadata can be core. Performance basics can be core. Editorial primitives can be core. Clean APIs can be core. Better structured content can be core.

Instead, WordPress seems increasingly interested in product categories that make sense for enterprise demos while ordinary site owners and developers keep patching the same basic gaps.

That is backwards.

The 80% user is not WP VIP

The real-time collaboration work makes the disconnect obvious.

The official Make WordPress post about early real-time collaboration feedback says the feature is being developed for WordPress 7.0. It also says WP VIP customers had beta access starting in October 2025, and that feedback came from larger organizations with multi-person editorial teams across news, media, higher education, research institutions, and enterprise publishing.

That feedback may be useful. Large editorial teams have real problems. I am not pretending otherwise.

But when an open source core post is talking about WP VIP customers, the average WordPress user is allowed to ask who the software is really being optimized for.

The average WordPress user is not running a newsroom. The average WordPress user is not coordinating a dozen editors on one post. The average WordPress user is not sitting in a corporate editorial workflow with approvals, simultaneous review, compliance constraints, and multiple authors editing the same page at once.

The average WordPress user is trying to make a site work.

• They are trying to publish a page.
• They are trying to update a menu.
• They are trying to fix a broken layout.
• They are trying to install a form.
• They are trying to understand why their site is slow.
• They are trying to add metadata.
• They are trying to stop a plugin update from breaking something.
• They are trying to get through the day without learning three new layers of WordPress abstraction.

Real-time collaboration may be useful to some organizations. Fine.

It is not the 80%.

That matters because the 80/20 principle is not supposed to mean “80% of enterprise editorial teams.” It is supposed to mean end users. The broad base. The people WordPress claims to serve by default.

If core keeps prioritizing the needs of the most complex customers, WordPress stops being the thing that made those customers choose it in the first place.

The basics are still embarrassing

The easiest way to explain the problem is still the meta description.

That is insane.

People can argue about whether meta descriptions are ranking factors. They can argue about whether Google rewrites them. They can argue about how much control a site owner really has over snippets. I do not care. A page description is basic publishing metadata. It belongs to the content.

WordPress has had decades to make that feel native.

Instead, one of the most ordinary fields a site owner expects to control is still outsourced to plugins.

That is the kind of thing that makes developers lose their minds because it reveals the mismatch. WordPress will build complicated systems around modern trends while leaving obvious publishing primitives as someone else’s problem.

That is not clean, lean, and mean.

That is confused.

Gutenberg changed the center of gravity

A lot of this traces back to Gutenberg.

Gutenberg was not just a new editor. It changed the center of gravity of WordPress. WordPress started thinking of itself less as a publishing system with an editor and more as a product platform centered around blocks.

Some of that was necessary. The old editor was not enough. Shortcodes were ugly. Page builders filled a real gap. WordPress needed a better native editing experience.

But Gutenberg also pulled WordPress into a permanent identity crisis.

Is WordPress a CMS? Is it a page builder? Is it a site builder? Is it a design system? Is it a React application embedded inside a PHP CMS? Is it an enterprise publishing platform? Is it a low-code app framework? Is it trying to compete with Squarespace, Wix, Webflow, Shopify, Notion, Google Docs, Contentful, and every AI writing tool at the same time?

The answer increasingly feels like yes.

That is the problem.

Trying to serve all those directions at once makes WordPress harder to reason about. Developers have to understand PHP, React, block metadata, theme.json, editor styles, server rendering, REST behavior, custom post types, block serialization, global styles, patterns, template parts, and whatever new abstraction comes next.

Some of that is powerful. Some of it is genuinely useful.

But power is not the same thing as clarity.

WordPress used to give developers a messy but understandable platform. Now it often gives developers a platform that feels like it is constantly renegotiating what it wants to be.

Matt and WP Engine broke the illusion

The Matt Mullenweg and WP Engine fight is not the whole reason WordPress feels off, but it made the problem impossible to ignore.

And I do not think this needs to be framed as some polite “both sides have concerns” situation.

Matt was the bad guy.

Maybe WP Engine has benefited from WordPress without contributing enough. Maybe there are fair questions about trademarks, commercial usage, open source obligations, and how much large companies owe back to the ecosystems they profit from. Those are real conversations.

But none of that justifies using control over WordPress.org as a weapon against WP Engine customers.

WordPress.org banned WP Engine from accessing WordPress.org resources. WP Engine said that meant its customers could not update and install plugins and themes through WP Admin. That is not an abstract governance fight. That is not a conference hallway argument. That is a decision that affected real websites maintained by real developers for real clients.

That crosses a line.

Then WordPress.org forked Advanced Custom Fields into Secure Custom Fields. Yes, ACF is GPL. Yes, open source code can be forked. I understand how licensing works.

That is not the point.

The issue was not merely that the code was forked. The issue was the distribution channel, the plugin identity, the update path, the installed user base, the trust, the reviews, the slug, and the ecosystem position attached to that plugin. For years, developers installed ACF from the WordPress plugin directory with a specific understanding of what it was and who maintained it. Then the plugin was effectively taken over and turned into Secure Custom Fields under the authority of WordPress.org.

You can call that a fork if you want.

I am going to call it what it felt like to developers who rely on that plugin: a hostile takeover.

ACF is not some random plugin. For a huge portion of serious WordPress development, ACF is infrastructure. It is the plugin that made WordPress usable as a real CMS for thousands and thousands of custom builds. Taking control of that distribution path during a fight with WP Engine was not just aggressive. It was reckless.

That is the part that damaged trust.

Developers and agencies have spent years telling clients WordPress is stable, open, community-driven, and safe. Then the person most associated with WordPress used centralized control in a way that made the ecosystem feel fragile overnight.

That is a huge deal.

Open source communities run on trust. WordPress especially runs on trust because the lines between WordPress.org, WordPress.com, Automattic, the foundation, Matt, contributors, hosting companies, plugin authors, and commercial interests have always been blurry. People accepted that weirdness because the system mostly worked and because WordPress felt bigger than any one person or company.

The WP Engine fight shattered that feeling.

After that, every big product decision looks different. Real-time collaboration looks more enterprise-driven. AI connectors look more like platform positioning. WP VIP showing up in core development conversations feels less incidental. Market-share decline feels less like a blip. Core priorities feel less community-led.

Maybe some people think that is unfair.

I do not.

When trust breaks, people start interpreting decisions through the thing that broke it. That is what Matt did to WordPress. He made developers wonder whether the open source project they built careers on was actually as open and community-centered as they thought.

Market share is not the whole story

WordPress is still massive. It still powers a huge portion of the web. Anyone pretending WordPress is going away tomorrow is being ridiculous.

But dominance can make projects arrogant.

Search Engine Journal covered W3Techs data showing WordPress market share declining for five consecutive quarters beginning in 2025, with a sharper six-month drop from December 2025 to May 27, 2026.

That does not prove WordPress is doomed. It does not prove one cause. It does not prove developers are fleeing to Astro or Next.js or Webflow or Shopify or anything else.

It does show that WordPress is not entitled to growth forever.

That should matter.

When a platform has been the default for so long, even a modest decline should trigger serious self-reflection. Not panic. Not denial. Not more feature chasing. Reflection.

The question should not be “What else can WordPress become?”

The question should be “What did people trust WordPress to be, and are we still honoring that?”

I do not think WordPress has a good answer right now.

The product is drifting away from the people who made it work

The people who made WordPress successful were not all enterprise editorial teams.

They were freelancers. Agencies. Plugin developers. Theme developers. Bloggers. Small business owners. Nonprofits. Campaign teams. Hobbyists. Local newspapers. University departments. Scrappy marketing teams. Developers who could make WordPress do something useful quickly because the platform was flexible enough and familiar enough to sell.

Those people did not need WordPress to become everything.

They needed WordPress to keep being a solid foundation.

That foundation now feels heavier than it should. The admin feels slower than it should. The editor feels more complex than it should. The data model feels older than it should. The APIs feel rougher than they should. The basics feel less complete than they should.

And every time core chases a giant new platform feature, the frustration gets worse.

Because the people who have used WordPress for years know exactly what still hurts.

They know what clients still ask for. They know what plugin conflicts look like. They know what performance tuning takes. They know what happens when block markup breaks. They know what it means to support a site for years. They know how much hidden labor sits underneath the phrase “just use WordPress.”

That labor built the ecosystem.

WordPress should be making that labor easier.

Too often, it feels like WordPress is making that labor harder while telling everyone the future is exciting.

WordPress should be smaller and better

WordPress does not need to die.

It needs to remember what it is good at.

• Be the best open source CMS for publishing and managing content.
• Make the admin fast.
• Make structured content better.
• Make metadata native.
• Make media handling better.
• Make permissions better.
• Make revisions better.
• Make the REST API better.
• Make block content easier to work with outside the editor.
• Make deployment less stupid.
• Make performance a first-class concern.
• Make the basics feel finished.
• Let plugins handle specialized features.
• Let enterprise customers pay for enterprise workflows.
• Let AI tools talk to WordPress through clean APIs.
• Let site builders compete on site building.
• Let static tools own simple blogs where a CMS is not needed.

That is not surrender.

That is focus.

WordPress does not need to win every category. It needs to stop losing the plot in the category it already won.

The uncomfortable future

The scary part for WordPress is not that one tool is better.

It is that the web no longer needs WordPress by default.

If I need ecommerce, Shopify might be the obvious answer. If I need a highly custom app, Next.js or Laravel might make more sense. If I need a fast developer blog, Astro or Eleventy might be better. If I need a polished marketing site, Webflow might be easier for some teams. If I need a headless CMS, there are dedicated tools for that. If I need AI-assisted content and development, the best workflow might happen in Cursor, Claude, ChatGPT, GitHub, and a static repo.

WordPress still fits some of those situations.

It no longer owns them.

That is the difference.

For years, WordPress benefited from being the safe default. Even when it was not perfect, it was good enough, known enough, flexible enough, and supported enough to justify.

Now every new project starts with a harder question.

Why WordPress?

That question used to be easy to answer.

It is getting harder because WordPress keeps trying to be more things while becoming less obviously great at the thing that made it matter.

WordPress won by being useful, flexible, and focused enough for the community to build around it.

If it wants to keep winning, it needs to stop acting like the answer is always more WordPress. See WordPress for Blogs Is Dead for where this series started.