To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites.
But of course, then they wouldn't be able to sell their own "workers" product, so suddenly I think I might understand why they built it the way they built it, at the very least to dogfood their own stuff.
I'm not sure it actually solves the "fundamental security problem" in actuality though, but I guess that remains to be seen.
"I need a website for my bakery". "What's supposed to be on it?" "Our address, opening times, a few pictures". I build them a static website.
"Now I need a contact form". Ok, that doesn't really fit into a static website, but I can hack something together. "Now I need to show inventory, and allow customers to pre-order". A static website won't cut it anymore.
When you develop for clients, especially those that you don't know very well, it's a bad idea to back yourself into a corner that's not very extensible. So from that perspective, I really get why they give plugins such a central spot.
I got my start in webdev slinging WordPress sites like a lot of self taught devs and I definitely see the pain points now that I’ve moved on to more “engineering” focused development paradigms but the value proposition of WP has always been clear and present.
Given how WP leadership is all over the place at the moment, I can see how Cloudflare sees this as an opportunity to come in and peel away some market share when they can convince these current WP devs to adopt a little AI help and write applications for their platform instead.
Let’s see if it pays off!
The flip side of the dynamic content is that every Wordpress I've ever worked on is a horrifying mountain of plugins managed by the world's worst package manager. Plugin A needs to be updated because it has a vulnerability, which requires plugin B to be updated, but the theme hasn't gotten updates in 6 years and plugin B is using new stuff the theme doesn't support, so either the site has to be re-built with a new theme or plugin A just needs to be left at a vulnerable version.
Static sites get around some of that because vulnerable plugins only exist at build-time. I'm not worried about using an old version of Hugo or Jekyll, but I'm very worried about using old Wordpress plugins.
I have no hope nor expectations of non-technical people performing technical tasks no matter how advanced AI becomes. The only solution is a platform/CMS that already has the all bells and whistles included.
until 3 days ago the website was a bunch of static pages, updated by the "webmaster", no shopping cart, no search, no contact form, just the email on the website
he and his employers have been living out of selling records and band merchandising for more than a decade, before he even created a real company
wanna buy a record? press a button that sends you to the paypal cart
wanna pre order? there is a preorder product on paypal, were you can put your shipping address and when it's ready, it'll be shipped to you
he's been selling in Europe and overseas in the US since the day he started
Now it got to the point where he needed to put different currencies for different regions, taxes, tariffs (UK, USA) so he built a new website that (automatically I guess) show the prices in the local currencies and stuff like that
p.s. still no contact form :)
The problem with WordPress (and it looks like this solution largely just replicated the problem) is that it's way too cumbersome and bloated.
It really is unlike any modern UI for really any SaaS or software in general.
It's filled with meaningless admin notices, the sidebar is 5 miles long and about 98% of what the user sees is meaningless to them.
Creating a very lightweight, minimal UI for the client to edit exactly what they need or like you said, just static files really is the best solution in most cases. The "page builders" always just turn into a nightmare the clients end up handing over for a dev to "fix" anyways.
Not sure why so many people feel the need to continue on the decades of bloat and cruft WordPress has accumulated, even if it's "modernized."
The first and arguably largest is exactly what you describe. Little sites for small businesses who just want an online presence and maybe to facilitate some light duty business development with a small webshop or forum. These sites are done by fly by night marketers who are also hawking SEO optimization and ads on Facebook and they’ll host your site for the low low price of $100/mo while dodging your phone calls when the godaddy $5/mo plan they are actually hosting your site on shits the bed.
The second, and more influential group of WordPress users, are very large organizations who publish a lot of content and need something that is flexible, reasonably scalable and cheap to hire developers for. Universities love WP because they can setup multisite and give every student in every class a website with some basic plugins and then it’s handsoff. Go look at the logo list for WordPress VIP to see what media organizations are powered by WP. Legit newsrooms run on mostly stock WP backends but with their own designers and some custom publishing workflows.
These two market segments are so far apart though that it creates a lot of division and friction from lots of different angles. Do you cater to the small businesses and just accept that they’ll outgrow the platform someday? Or do you build stuff that makes the big publishers happy because the pay for most of the engineering talent working on the open source project more generally? And all that while maintaining backwards compatibility and somewhat trying to keep up with modern-ish practices (they did adopt React after all).
WordPress is weird and in no way a monoculture is what I guess I’m trying to say.
I use Wordpress for my blog because I stopped caring about maintaining one, and I'm mildly confident wp will be around for 10 more years.
There are basically no notices and the admin sidebar is ~10 obvious entries (home, posts, pages, comments, appearance, settings etc).
I've built Wordpress sites for 12 years. Very few Wordpress developers are trying to swap to a slightly upgraded version of the same thing with no ecosystem and much of the same solutions. This will see some adoption, no doubt, but not a serious dent.
The main reason for that: in 12 months, 24 months, 36 months, this solution will be outdated and unimportant, same as Wordpress. Wordpress will still be kicking because it already has a 40% market share on the entire internet. This, however, will not be.
The CMS is dead tech in six to twelve months. I might have a million people who will disagree with me (and yes, people will still use CMS's after twelve months), but people actually moving into the future will have dropped CMS's for architectures that are AI first with strong, intuitive, easy-to-leverage guardrails.
In my opinion, the vast majority of people are still looking at AI through the lens of "how does it alter my current work/tech stack/strategy" and failing to ask the proper question: "what the hell is even important in a world where AI is as competent as 90% of humans and 100x faster?"
What do you need a CMS for? You think you'll be managing the content? Why? Why do I want a human managing content when the AI does it 100x as fast? Why do I want Astro? It compiles down nicely? Okay, maybe its a god-tier solution, but more likely... AI can just code extremely fast vanilla html/css/js. Why do I need a component library when AI can steal all the best components from all the best libraries? Why do I need "Portable Text"?
This is still not big picture enough. Think further out than 12 months.
To me this wording is strange, since traditional web frameworks do render pages server-side. The specific functions of their templating engines are often even called "render" (https://jinja.palletsprojects.com/en/stable/api/#jinja2.Temp...) or "render_template" or similar (https://docs.djangoproject.com/en/6.0/topics/templates/#djan...). I guess "server-side rendered" is being coopted by the JS ecosystem for some time now, as if they had come up with the very idea of rendering pages on the server side.
It would do the world some good, if people could just look at a technical term, understand its meaning by its components, and then not go: "Ah yes, I will use the same term, but no, no, no, I mean something different by that!"
For this example:
(1) "server-side": happening on the server
(2) "rendering pages": various meanings in different contexts, but on the web meaning filling in information and creating parts of the HTML tree, to get a full HTML document.
You either write them by hand, or use a tool that generates it locally, upload everything and you're done. Perfect security. Great performances.
It's in this sense that static generators go back to the source, the simply produce dumb HTML files that you upload/publish to a web server that doesn't need to run any code. Just serve files.
I've given the security, or lack of, WP a lot of thought recently. In WP malicious plugin has access to the database, enfironment variables, rendering text on screen (think XSS). Luckily, a thoughtfully designed plugin system can mitigate all of those issues.
I've been working on a headless CMS in my spare time that is eirily similar to EmDash in a few ways. It's in very early development, but I will share regardless. It's called HotsauceCMS - https://github.com/hotsauce-team/hotsauce
- I went with optional NodeJS or Deno Worker plugins, this means that first-party plugins can benefit from the speed of in-process, and other plugins can be run in Workers. For fine grained permission control, you can use Deno Workers.
- I went with absolute minimal dependencies, I am so fed up with Dependabot alerts and npm supply chain hacks. My CMS has only 4 dependencies, 0 transistive dependencies.
- It's Drizzle schema first, and headless. So you have full controll of the database structure, use cms hints in your schema for features like file upload.
- It's database-agnostic, so it works with any Drizzle-supported database (Postgres, MySQL, SQLite)
- Being headless, you can use any frontend, my preference is JSX w/o react, but anything goes.
Feedback is absolutely welcomed on HotsauceCMS, did I miss a trick, am I on the right track?
Anyway, congratulations on EmDash. I'll be following closely, excited to see how the next few months unfold.
Can you explain why TS is spot on?
- I've been done GraphQL server with a build step to share types between languages.
- I've used untyped JS client side code.
Both are prone to bugs, and not much fun.
TS for front and back end: sharing types means you'll have editor type hints, catch type errors at lint (or build), and you might even share validation logic between client and browser.
The appeal for the company i was working with was ease of installation on legacy servers (FTP). You would just upload the files, and it worked. No CLI tools, no dependency management, no build tools.
But yeah, security was a big issue. Constant hacks.
Yeah the security aspect is important, but how many of those Wordpress engineers are going to jump ship to this because of security when they've been fine with the risk so far? My money is not a lot. If someone is a WordPress dev in 2026, they're probably not the type of dev that likes to upskill and learn new tech. Similarly, if you're looking to target the average joe looking to build a fresh website, would that consumer really choose this over Wix or Squarespace? It doesn't look easier to use so I wouldn't count on it. So where is the network effect going to come from to make this the new WordPress?
I could see Vinext being successful if they keep at it— I think there are a sizeable amount of people who would like to move away from Vercel (and who will probably migrate to Tanstack when the ecosystem is more stable). But I'm not sure people on WordPress really want to leave. If they really want to make this successful I think they need a better angle which in my opinion would be making it easier, quicker, cheaper and more flexible than Squarespace/Wix/Shopify etc
The real talent drain isn't about technology at all. It's the governance mess. The WP Engine lawsuit, Matt's behavior on community Slack, the constant drama. That's what's pushing people out.
But even with all of that, nobody's leaving for EmDash. They're leaving for freelance Webflow work or getting out of CMS entirely. Cloudflare would need to solve the "why should I rebuild my entire business on your platform" question before the talent pool argument matters.
I’m very happy with WP, but I’ll be cheering on EmDash if it gets momentum.
Fascinating. Cloudflare is envisioning a future where agents are given debit cards by their owners, so they can autonomously send microtransactions to website owners to scrape content or possibly purchase goods on the owner's behalf. I don't know how I feel about that but there's no doubt it's a fascinating concept.
Brb, setting up a honeypot that always responds with HTTP 402 Payment Required demanding 10cents per visit... That's the next "selling 1 million pixels on my website for $1 each", I guess
and you could call it "EmDash"
I suppose this is the world we live in.
Oh dont worry, I'll do the feelings for the both of us, I have over a decade of experience feeling smugly and validatingly superior to people who save payment info on ipads and then hand it to their kids.
There's no reason to use an interpreted, bloated, weird language anymore. The only reason interpreted languages were a thing was so you could edit a file and re-run it immediately without a compile step. Compiling is now cheap, and you don't have to build expertise in a new language anymore. Ask AI to write your app in Go, it'll happily comply. Run it and it's faster with less memory use and disk space. The code is simpler and smaller making reviewing easier. Distribution is as easy as "copy the file".
I'll grant you, interpreted languages skip the "portability" compiling/distributing step, and let you avoid the stupid MacOS code signing. But Go is stupid easy to cross-compile, and (afaik?) the user can un-quarantine a self-signed app pretty easily.
how is javascript not a real language?
> There's no reason to use an interpreted
there are loads and loads of reasons to use "interpreted" languages. that you can't think of even a single one while still pretending to be knowledgeable in the field is really intriguing.
> bloated, weird language
oh, i see, this is all just a religious rant. carry on!
One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating.
Another problem is that the type system is often not expressive enough for frontend code. So you either have to generate types or end up with something like map[string]any, which is awkward and gives you less guarantees and support than what dynamic languages typically offer (in other words, dynamic languages are better at being dynamic languages than Go).
Now these problems don't emerge in every web UI based project, but when they do, it's really painful and limiting compared to what one is used to.
b) typescript fixed a lot about javascript and is somewhat decent
c) multiple fast and performant runtime engines
d) deployment story is php levels of easy
that's it.
Yeah just invalidate the SSR cluster for your tiny footer update and let it prewarm until coffee break. Easy.
Perhaps I'm speaking out of depth because I haven't done a lot of Golang, but I've always thought of it as a systems language first, which means by necessity you have you to handle lower level problems yourself. I'm sure there's plenty of libraries that paper over this - but the philosophy of the languages themselves is different. Javascript was designed to solve CRUD like interfaces/problems quite well.
Maybe this is just an outdated argument though that isn't really relevant with modern golang/rust though.
Go has a really solid standard library which removes a lot of what you'd typically implement separately. You don't solve lower level problems because the language already solved it. Nodejs has the opposite issue, where there's virtually nothing standard, so people made libraries to implement 5 lines of code. Rust also has a minimal standard library, and is more complex than Go. If you want a dead-simple, batteries-included compiled programming language, Go is pretty much it. Since you write less code with Go, there's less context use, so actually, the LLM has an easier time with Go apps.
It started as a 'systems language' but it has many projects that extend its usefulness. There are two separate frameworks that let you write one Go app and compile it as an Android app, iOS app, Mac app, Windows app, Linux app, both GUI and console. It has multiple web frameworks, and one is even an Electron replacement. The thing it doesn't have is a REPL.
LLMs have a couple major problem, they hallucinate and make mistakes. So the ideal way to use them is to constrain them as much as possible with formal methods. Rust's type system is a formal proof of some forms of correctness, this will let "vibe-coding" work to a much higher degree than with other languages.
In the very long run, I suspect that all vibe-coding will actually occur in a language with dependent types and we'll push as much as possible into being proven correct at compile-time. Since the cost of generating code is plummeting, and thus the sheer volume of code will be exponentially rising, this is the only way to prevent an unsurmountable mountain of errors.
Formal methods and LLMs are a match made in heaven.
But it's correct that it is odd. As long the lang is mainstream enough, it hardly matters. My assumption is that JS/TS coders have the highest resistance to switch platforms, the ecosystem is huge, it's cross BE/FE, performance isn't complete trash, everyone they know knows the platform as well. Why switch? It's a screwdriver, if your passion is to screw things, you will.
But the reason I'm still on WordPress isn't loyalty. It's that my clients can maintain their own sites without me. A small business owner updates their own pages, adds blog posts, changes a phone number. No developer needed. That's not a feature of WordPress. That IS the product.
EmDash solves a developer problem (sandboxed plugins, TypeScript, Workers) by building a developer product. Nothing wrong with that. But calling it a WordPress successor misses why WordPress won in the first place. It wasn't the code quality. It was the guy who runs a bakery being able to edit his own website on a Sunday morning.
E: Oh, I think it's an April fools joke, I'm embarrassed.
E2: Apparently not a joke.
On the initial commit:
> Some content is hidden
> Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
This for "a spiritual successor to WordPress".
It should. I miss the days when tech was interesting and fun.
Even Steve Jobs, for all his later-day revisionist hard-assed reputation, enjoyed the occasional Easter egg, inside joke, or April Fool's joke.
That site warns that WordPress plugins can be abandoned, but that's clearly not a WordPress specific issue. Sure some site could use SSG, but that's a different design.
I certainly don't want to claim WordPress security is good, but I'm not sure that site is measuring anything meaningful.
"Better coded" is very much a subjective assessment.
yes you want a global db handle sure ya lets delete all tables woohoo
You've sort of nailed it, but this isn't a bad thing. An alternative for these customers does not exist.
There's another vertical which is organizations that have armies of writers churning out content. Any kind of publisher or advertiser, basically. There is no better CMS for this. Large organizations like NYT, etc chose to write their own.
Ivory tower "just don't use a low-cost solution" people aren't going to hand over money to people to use a higher-cost one, are they?
And ignoring why it's used besides the sloppiness means they have a huge blind spot to what people actually want:
"wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious"
Nothing in this quote doesn't describe very real needs.
WP treats plugins as content, literally in the same top level `wp-content` directory as uploaded images. This makes CI/CD among other things, a nightmare. But EmDash plugins are just TS modules, which has got to make things easier even if plugin configuration does end up in the db somewhere.
You hit the nail on the head.
Cloudflare's new business model is to find popular OSS projects, create a vibe coded alternative that only runs on Cloudflare's infrastructure.
The $5/mo gets you 10 million dynamic requests (static assets are not included in this limit, so often a single pageview will be 1 dynamic request) and that would be across the whole workers product for your account, no extra pricing for extra websites, domains, or anything else like you'd see in most "wordpress hosting"
I run all my personal sites and client sites (one of them for a fortune 500 company) in the $5/mo plan, and the only time I went over that was when a client got hammered with malicious requests (and it was like $100)
Disclaimer: I have no relationship to cloudflare, I'm just a happy customer
Ha ha, that's really funny timing given the recent launch of Cleanroom As A Service, promising that you can licensewash other peoples' code quickly and easily: https://malus.sh/
I'm not saying they did that, but it's ironic timing.
> A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations.
Someone should introduce the authors to the lovely em dash character. It's perfect for such sentences!
Just not accurate. WordPress doesn't prevent this.. It's up to hosting providers to work on their infra so it can run in a serverless fashion.
For example: https://www.agiler.io
That's serverless wordpress that scales to zero.. no changes to WordPress, plugins or anything else.. just platform infra.
Also, there are successful alternatives to Wordpress too, so the most likely outcome is that it becomes yet another alternative.
People aren't on WordPress because of WordPress.
They're on WordPress because of WooCommerce, a million themes, BuddyPress, integrations for every stupid internal business API on the planet (many of which are terrible and were written by an idiot with a crayon).
The APIs will have no testing because they are bad. In many cases the WordPress implementation of the API written in the codeblock, ran on page-load to the pain of the person responsible for SEO, is the API contract.
And yes those plugins are also terrible, but they solve business problems, even if they are tech problems.
You can't just launch a better wp-core and expect it to replace any of that.
EmDash needs to actually run the existing insecure WP plugins to takeover.
A "good" standard, free CMS with theming and plugin support without the issues of Wordpress is _welcome_. (And the issues are many: Licensing, trust, drama, security, and cost).
I'm guessing that a lot of cynicism here is coming from this crowd not being the target market of Wordpress in the first place? What were you recommending to non-technical friends and family who wanted a good, open source, affordable CMS to back their website? Wordpress has all the right _ideas_, but the wrong implementation.
The hard part is displacing Wordpress market share; building a community of bloggers, marketeers, agencies, web designers, and so on; creating a huge ecosystem of paid and free plugins, allowing plugin devs to commit to your marketplace and lock customers in.
Wordpress is awful. The only thing it's got going is its moat, but that's not an engineering problem, but a people problem instead.
The problem is that people misunderstand why WP was and is better than all alternatives that tried to take it's place, I have no idea either but I know that others have tried same thing as CF and failed.
Like?
Other than that, it seems it might be a half decent headless CMS, if the bit of WordPress you want is its interface, and not the number of plugins and devs and not being tied to Cloudflare's infrastructure.
...the fact that CF just dumps tokens to generate some slop to compete with the single biggest web platform and casually adding a vendor lock in. It's just buzz, an inexpensive attempt to grab a valuable market share.
If you set security as a selling point for EmDash, then I am baffled. The WP lock file has 30k lines, the brand new EmDash has 16k lines, but it LESS verbose yaml. JS is the cornerstone of anti-security that WP couldn't dare to compete with. The plugin isolation is also bogus, WP plugins are insecure because they have all access to everything, but they need at least some, mostly DB, how is that even solved? Isolation does shit there.
I am not a fan of WP, but CF doesn't even try to get this right.
With WP you can find a plethora of cheap PHP hostings that offer WP preinstalled. If you need to tweak a theme - just download a .php file via FTP, tweak it and upload back.
No server management or restart is required.
One big potential benefit that EmDash has - every WP deployment is basically a honeypot.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
Editing content in Strapi, once customized with CKEditor and such, is Wordpressy enough for the human Editors familiar with WP.
So far I'm loving the stack.
As do most productivity software, like MS Office, Photoshop, Apple's iWork, etc.
Imagine making a document in Word, and it looks completely different when published.
I guess this is our answer to the question of why Cloudflare acquired it in the first place.
You just put the comments into something like firebase/supabase etc or use one of many off the shelf solutions. Free tier is fine.
https://github.com/Automattic/vip-go-mu-plugins
It must be open sourced because it's based on WordPress. I still love that.
I struggle to understand why anyone would want to generate code in TypeScript - unless what you're building truly can't be done in Go, Rust, or Kotlin; anything but JS.
I’m not sure how much of an improvement it really is to rewrite something from PHP to TypeScript while claiming security benefits.
¹https://developers.cloudflare.com/directory/?product-group=D...
Just missing compartmentalisation features between prod and dev environments.
Anything built on PHP will be widely used, like Laravel
Talented teams will build the atoms for most apps - blogs, CMSes, ticket systems, forums - and it'll be easy for end users to configure.
Rust is easy to code gen and deploy now. No barrier to understanding lifetimes. It's the language everyone should be using Claude Code to emit.
Everyone is now a Rust engineer with 10 years of experience. (I'm not joking, just in case that needs clarification.)
If you haven't tried writing a simple web service in Axum or Actix plus SQLx, you need to give it a try. You'll be amazed at how simple it is, and you'll be even more amazed at how performant and easy it is to work with.
You do not need to know Rust or have any prior Rust experience. You'll pick it up along the way. It's easy and you'll learn it fast.
Rust is a low-defect rate language to serialize to. The syntax begs you to handle errors, nulls, exceptional conditions within the language itself. This is naturally a good fit for most business problems. It doesn't hurt that the language is fast as hell and super portable either.
If the job is now encoding business logic - this is the optimal serialization that I'm aware of. I write Go, Java, Python, TypeScript, PHP, Swift - I can't think of any better language for greenfield projects that don't have existing language/library requirements.
This is no successor, it's not even in the same universe. - vendor lock-in, losing gpl, losing access to plugins source code, loosing ownership.
> no WordPress code was used to create EmDash
Hm. Do you think those agents were trained on WP code?
base platform used - typescript - means for the average Joe out there - deploying is difficult - compared to php.
if they really wanted to be revolutionary - they would've made a single PHP script either on FrankenPHP backed by sqlite - single file deploy - with yeah a permission model Ala denojs for the security aspects.
end of day this is vibeslop.
Is this April fools? With real products launching on this date you can't really be too sure.
It's not illegal to make product comparisons. That's just competition.
It takes me to the expected Cloudflare dashboard page, with title “Clone a repository” and with the GitHub repository URL field filled with https://github.com/emdash-cms/templates/tree/main/blog-cloud... but when I click Continue, the Continue button changes to “…” and animates indicating it’s thinking, but then nothing happens. No error messages shown, nothing. The Continue button switches back to having the Continue text and being clickable.
I tried deleting a couple of old applications I had in the Workers & Pages page of the Cloudflare dashboard thinking that maybe I had exhausted the number of such applications I can have on a free Cloudflare account. The number of applications I have is now down to 7, after deleting a couple of old ones. Still, attempting to deploy EmDash to my Cloudflare account fails in the same way as before without any error messages shown.
I was using Safari on iOS 18.7.1. I will try on a desktop browser, in case the problem is only happening in Safari on iOS.
Another one of their products which was “just an experiment”
Cloudflare annoys me as a company.
Oh, neat. Which model wasn't trained on WordPress?
You want anything beyond ghost? Find a way to port the vast market of 100,000+ cheap and free themes and components that are available to enable tech-illiterate, low-budget users to basically build an entire business platform on a $5/mo shared hosting plan.
A vibe coded CMS that's 3 months in the making is not capable of taking that place in the market, no matter how much VC funding you put behind it.
In contrast, typical web frameworks (even static sites) require a code change, build, deploy, etc to update many aspects of a site.
It looks like a good open source project, but just call it a new CMS. I think calling it a "spiritual successor to WordPress" is just to gain some marketing points.
The cost of building software has drastically decreased.
We have a cursor subscription and work and i now see many non-technical people building their own internal tooling. People that had essentially never written a line of code before this new revolution.
The cost of building software has really drastically decreased.
> Most abstractions in software exist because humans need help...It's not clear yet which abstractions are truly foundational and which ones were just crutches for human cognition... We took an API contract, a build tool, and an AI model, and the AI wrote everything in between.
That said, WordPress is a weird paradigm to be replicating in 2026. WP won on extensibility, but the actual legacy of that ecosystem is bloat, security disasters and dogshit performance.
What I think makes more sense is this kind of edge backend paired with a proper modern authoring experience with visual control like Framer/Webflow with Notion-style database primitives underneath.
And given how fast AI is getting at generating bespoke business logic, building another monolithic plugin ecosystem feels like solving the wrong problem.
Plugins were a workaround for the fact that most people couldn't write code. That's increasingly not true.
Actually, rebuilding WordPress without the ecosystem is kind of the point. For example, would Divi or the major page builders rebuild their entire products to support this? I doubt it
A while ago I ran claude code in a custom loop (calling it autoclaude; this was last summer) to create a CMS with Gutenberg’s editor but a lean Python backend (github.com/hessammehr/nuCMS). This was in the Sonnet 3.7 days and even that model got quite far.
"Plugin security is the root of this problem. Marketplace businesses provide trust when parties otherwise cannot easily trust each other. In the case of the WordPress marketplace, the plugin security risk is so large and probable that many of your customers can only reasonably trust your plugin via the marketplace. But in order to be part of the marketplace your code must be licensed in a way that forces you to give it away for free everywhere other than that marketplace. You are locked in."
There was much drama with wordpress some time ago and the plugin marketplace.
capabilities: ["read:content", "email:send"], read:content
write:content
read:media
write:media
network:fetch
read:users
email:send
email:provide
email:intercept
> ### Trusted Mode
> Trusted plugins are npm packages or local files added in `astro.config.mjs`. They run in-process with your Astro site.
> - *Capabilities are documentation only.* Declaring `["read:content"]` documents intent but isn't enforced — the plugin has full process access.
> - Only install from sources you trust. A malicious trusted plugin has the same access as your application code.
And all that padding gets you quite the narrow content area. Not to mention it looks like a very basic TinyMCE. Seems like more of a POC than an actual "spiritual successor".
Additionally, as others have already mentioned, the best security would be no dynamic code at all, just static pages generated by Jekyll. This should have been a Jekyll frontend, IMO.
>And because WordPress plugins run in the same execution context as WordPress itself and are so deeply intertwined with WordPress code, some argue they must carry forward WordPress’ GPL license.
That is a feature, not a bug. I already have to debug broken or poorly-documented WordPress plugins as-is, my job would be 100x harder if those plugins were proprietary and forbade inspection of the code.
Furthermore, while the GPL forbids locking down plugins to charge a licensing premium, it does not forbid charging money in general. While in theory you can legally pirate paid WordPress plugins (it's called "nulling"), in practice few do this because it's an obvious and blatant security risk[1]. Paid plugin authors are selling support and software assurance that has real value.
Also, I must take umbrage with the legal hedging. "Some argue"? Like, the GPL is strategically ambiguous with regards to the definition of a "Program"[2], but it'd be very hard to write a useful WordPress plugin that does not become part of the same Program.
[0] This is predominantly a fault of JavaScript, which has no threading story and is designed to fit in a foreign event loop. In Rust, async code can spawn and await real threads to hold blocking code, and sequential code can host its own event loop to run async in.
[1] Especially if you were to, say, name your nulled version "Secure Custom Fields". Nobody would EVER do that, right?
[2] No, proprietary Linux modules don't count. Linux has a userspace syscall exception that defangs the GPL, so it's perfectly possible to write kernel-mode code that only touches syscall equivalents.
They fix many of the hosting concerns , but it’s way too complex, and lacks wordpresses biggest selling points.
People will be vibecoding Wordpress templates and sites for another 15 years
This would avoid plugin scanning and direct plugin code execution.
For the CMS I'm developing, Vvveb CMS, no plugin code is exposed, everything passes through the only exposed php file `public/index.php`
Can a successor for Wordpres shave some amount or type of import, conversion, or backwards compatibility?
Can there. ba way to tie in wordpress plugins or their functionality through a secure interface/translation layer?
Adoption for new projects is one thing, migration is another.
There's some cms that pretty much build in some core amount of main plugins right into the core cms.
So, long story short I ended up removing write permission to all the folders, thus disabling upload, and later they went to another server. They host it fine there, I still maintain redirection from the main domain to their host. However I failed, but really this is sad the WP is so vulnerable just by the plugins installation.
Since then I am looking for WP replacement that would not mix up the code and the images from the upload directory (presumably in rust or golang), but this would need to be opensource anyways.
A system for using Federated and Independent Repositories in WordPress
Re-implementing WordPress (their words, not mine) as MIT licensed, while legally questionable, breaks that virtuous cycle and removes the community's moat. They've taken WordPress's roles and menus and borrowed its Gutenberg code (which is GPL), and launched it as an MIT licensed product, which breaks that virtuous cycle. It means e.g. a hosting company can take the product closed source if they want to, and never have to contribute any of what they build on top of the community's work, back to the community.
https://github.com/emdash-cms/emdash/tree/main/packages/core... says "The core EmDash CMS package - an Astro-native, agent-portable reimplementation of WordPress."
Emdash uses WP's RBAC roles. Also uses their menus. Also depends on @wordpress/block-serialization-default-parser which I think might (??) be able to be used by an MIT project even though WordPress is GPL.
They used Claude Code it seems because the first commit has a CLAUDE.md file which became an AGENTS.md.
The repo says "depends on Dynamic Workers ... Dynamic Workers are currently only available on paid accounts" but the article says "but you can run it on your own hardware".
This IS an April Fools joke, whether or not they intended it to be one.
Is the second coming of Wordpress what we really need?
With Cloudflare behind it, hopefully plugin vendors will start paying attention.
I'd usually expect this to be used about something like Google Reader, not something you are actively competing with.
Will EmDash work with shared hosting?
What does it mean, to be "compatible with functionality"?
At a first glance this statement promises a lot, but does it really mean anything technically?
Most WordPress users use at least one plugin: it is the appeal of the product.
The Cloudflare Workers approach (V8 isolates) is fundamentally better because it enforces boundaries at the runtime level rather than relying on developer goodwill. Curious to see how they handle the migration path for existing WP sites though — that's where projects like this usually die.
Why do you feel it's not right?
Its a CMS, designed from scratch, for a serverless world. It has a stricter, well defined API that plugins are forced to use instead of directly calling/overriding core functionality like in WP. But that benefit comes with a CMS that's built on top of, and seems to prefer, a ton of CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things).
The web need less consolidation on CF, not more.
Maybe not scratch scratch: "And under the hood, EmDash is powered by Astro…"
> It's built on top of, and seems to perfer you use CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things.
D1 is SQLite, R2 is S3, and there are other ways to securely run plugins. If it was designed to only be possible to deploy on Cloudflare, they didn't do a very good job.
(To be clear, I'm no fan of WordPress either, and its security hassles are a real issue. But some sloppified MegaCorp vibecoded fever dream will never be a suitable replacement, of that I guarantee.)
If Cloudflare really have radically changed their software development philosophy lately, this would actually be an interesting project, being based on Astro and coming with some APIs for programmatic management.
Them being so happy about the „cost of software development“ and not going very deep into ecosystem, community or project management doesn’t convince me that this is going to be a worthwhile project, even if, unlike their previous vibe coding demos, this one actually works.
As the post implies, I did use a lot of agent time on this, but this isn't a vibe-coded weekend project. I've been working full time on this since mid-January.
That's the significant part of Wordpress after all, not the mediocre code.
You even open the article by linking the toy project where you used agents to "recreate Next in a week" and released with critical vulnerabilities.
Compatible how?
The question isn't whether this took longer than a weekend or whether you personally have open source experience, it's whether Emdash is actually being built as an open ecosystem or as a Cloudflare-bound platform. Bringing up your background reads like using prior credibility to justify the project's quality, instead of demonstrating it.
If it only runs properly on Cloudflare's infrastructure, then invoking "understanding open source and community" feels misleading. Those values usually imply portability and independent ecosystem growth, not tight platform coupling.
Also, "not vibeslop" here isn't about effort, it's about whether there's a clear, defensible reason this exists beyond being an AI-accelerated WordPress-like system tied to one vendor.
- good caching - GUI in spanish - a cli like wp-cli
good cache control is essential for news sites with 100k + posts
> But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
They have honed their AI OSS troll marketing chop and every step goes far and far. I'll take it more seriously once they start open sourcing vibe coded projects they actually use in their production.
capabilities: ["read:content", "email:send"],
The problem is there's no beating the slop allegation. There's no "proof of work" that can be demonstrated in this comment section that satisfies, which you can see if you just keep following the entire chain. I'd rather read slop comments than this.
The main engineer of this project is in the comments and all he's being engaged with on is the definition of vibes.
If the product launch involves dressing the engineering team up in duck suits and releasing to a soundtrack of quacking, it's really not surprising people are asking the guy they hid behind the Daffy mask on why he's dressed as a duck rather than what he learned about headless CMS architecture from being on the Astro core team...
I am implying that Cloudflare is publishing unusable one-off software without care because they have done it before and the blog post indicates that they are doing it again („look how CHEAP it is to pump out code now“).
I don’t need a proof of work, I need a proof of quality, and the blog post is the opposite of that.
The blog post was chock full of factual errors, claimed to be based off project X but wasn't at all and even had the cheek to include that it was arguably the most secure way to deploy such a server, with their implementation apparently already being used by their team to serve real traffic. Meanwhile the repo was full of TODOs for all the security aspects of the protocol.
Of course after the backlash a lot of this was covered up so look at the archives if you are curious.
They have really done a disservice to themselves because their blog posts used to be excellent, but now I have to question whether it's another blogpost full of fakery like that one (and there was another since iirc). Given this blog post talks about reimplementing a popular project, it starts to give off the signs of being another one of these. Unfortunate if that's not the case
The problem is with letting your AI roam freely to produce hundreds of thousands of lines of code without caring what it produces, which Cloudflare‘s history and the launch post indicate to be the case here.
Is AI merely being used as a tool to aid the engineer? Because that's what I do. I use it as essentially a super-autocomplete. It typically only writes a couple lines at a time for me. On rare occasions, I can write a function signature and let it fill out the body. That's coding with AI.
Anything more than that though? You're stepping into coding by AI, which utterly fails at anything beyond an MVP. Once you go over 2,000 lines of code or so, it falls apart. It can't reason about anything with even a small amount of complexity, and every "bug fix" either fails to fix the bug or it introduces two more.
What I don't love is how insecure it is. You're entirely dependent on plugins (if you're not a developer), and if WordPress updates and a plugin goes inactive, you're sitting on a vulnerability. It adds real stress for something that's just supposed to be a fun personal site.
I stopped building on it two years ago, even though I still like it more than Webflow and most alternatives I've tried. It's a bit sad.
I have been on and off in the past 6 - 7 years trying to get DHH / 37Signals to release a CMS / simply blog system that compete with Wordpress.
May be Shopify should do it instead, and name it Pressify.
[1] https://w3techs.com/technologies/overview/content_management
Half the websites on wordpress moved to shopify, squarespace, etc. a very long time ago. The remaining half were blogs, personal pages, wikis, etc. that moved to community/social platforms created in the past decade(s). In a few cases out of all this someone finally learned how to write/host a webpage themselves (imagine that)! It's even easier with AI now.
I'm totally serious when I ask "why". Who actually uses a CMS or anything like that anymore? It's madness!
Having got back in to some WP in the last year, the big thing that struck me compared to other framework/environments is... no... build step, or even plugin/module install step. Files are just there in the document root, accessible by default - the logic files are invokable and the asset files are reachable. Most other php frameworks will install a plugin/module outside the document root then have some sort of publish/install step that will copy assets to be publicly accessible as needed. No plugin logic files would be invokable directly from a URL. That one change would make a big difference, imo, but seeing so much of the last 15-20 years of WP involves helper functions to assumed paths, and default assumptions about assets and logic living in the same paths... I'm not sure the ecosystem could adapt or support an alternative approach at this stage. Might be wrong. It's taken me a while to put my finger on why the current situation encourages less-secure-by-default systems, and this is probably the biggest thing I've landed on. There are other issues, but these issues all help contribute to WP popularity in the first place...
(looks for cameras) Wait a minute, am I being Punk'D? Oh my god! Ashton, you really got me! Ha Ha! Ashton!
I run parallel coding agents on my own projects daily. The code they produce is fine. What worries me is the "just ship it" energy where nobody on the team deeply understands what got built. That's not an AI problem, it's been a problem with outsourced codebases forever. AI just makes it faster to accumulate code nobody fully groks.
Cloudflare probably has the engineering depth to maintain this regardless of how it was built. A lot of other teams don't.
Impressive indeed!