.png)
3 days ago
2
Yes, we're a bit late to this party - the WordPress world caught fire back in 2024. But sometimes you need distance to see just how badly the bridge was burnt.
Remember when WordPress was the reliable workhorse of the web? Those were simpler times. Then came October 2024, when Matt Mullenweg decided to play repo roulette with one of WordPress's most popular plugins, and developers everywhere collectively spat out their coffee and formed an opinion, as we do.
The day WordPress jumped the shark
The WordPress vs WP Engine conflict started as a trademark dispute but quickly devolved into what can only be described as a masterclass in how not to run an open-source project. The timeline was brutal:
- Mullenweg calls WP Engine a "cancer" at WordCamp
- WordPress.org blocks WP Engine's access
- The nuclear option: WordPress forcibly takes control of Advanced Custom Fields (ACF)
- Developers everywhere: "Wait, they can just... do that?"
The ACF seizure was the moment everything changed. Without warning, WordPress "forked" the plugin into "Secure Custom Fields," essentially stealing it from its creators. For developers who'd built their careers on WordPress, it was like watching your favourite pub get turned into a vegan juice bar. Technically still a business, but fundamentally not what you signed up for.
Why Sanity and Payload are eating WordPress's lunch
While WordPress was busy with its civil war, modern headless CMSs were quietly winning over developers who'd had enough drama. Here's why platforms like Sanity and Payload CMS are thriving:
Sanity offers what WordPress couldn't: predictability. Its real-time collaboration, structured content approach, and "bring your own frontend" philosophy attracted developers who were tired of wrestling with WordPress's increasingly complex ecosystem. No plugin conflicts, no surprise takeovers. Just a content API that does what it says on the tin.
Payload CMS went even further, giving developers the TypeScript-native, self-hosted option they'd been craving. It's like WordPress if WordPress had been built in 2024 instead of 2003. Modern, developer-friendly, and without the baggage of supporting two decades of legacy code.
Both platforms understood something WordPress forgot: developers want tools, not drama.
The trust recession
The WordPress conflict revealed an uncomfortable truth: when push comes to shove, open-source projects with centralised control aren't that different from proprietary platforms. If WordPress.org could unilaterally seize ACF, what else could they take? Your favourite security plugin? That e-commerce solution your clients depend on?
This wasn't just about losing faith in WordPress. We were realising the entire model was broken. Developers started asking hard questions:
- Why am I building on a platform where one person's tantrum can break everything?
- What happens when the next conflict erupts?
- Is "open source" meaningful when control is this centralised?
The headless revolution accelerates
The exodus from traditional WordPress didn't mean abandoning it entirely. Smart developers pivoted to treating WordPress as just another content API. Sure, it was useful for clients who knew the interface, but it wasn't the foundation of their stack anymore.
The modern approach became:
- Use WordPress (or better yet, Sanity/Payload) as a headless CMS
- Build frontends with Next.js, AstroJS, Nuxt, or SvelteKit
- Deploy on Vercel, Netlify or Cloudflare
- Sleep better knowing no one can arbitrarily break your sites
This wasn't just about technical architecture. It was risk management, pure and simple. Decoupling meant freedom from platform politics.
The bottom line
Looking back from mid-2025, the WordPress civil war feels like a necessary wake-up call. It forced developers to reconsider their dependencies, explore modern alternatives, and build more resilient architectures.
The irony? WordPress is still massive, still powers a huge chunk of the web. But its role has fundamentally shifted. It's no longer the default choice for new projects. It's the legacy system you migrate away from, one headless API at a time.
For developers who lived through the drama, the lesson was clear: never again put all your eggs in one basket, especially when that basket's owner might decide to juggle with it. The future belongs to platforms that respect developer autonomy, embrace modern development practices, and understand that trust, once broken, is bloody hard to rebuild.
