One tweet, two releases: how feedback from the WordPress world makes EmDash better

On 1 April 2026, Cloudflare introduced a new CMS and called it the "spiritual successor to WordPress" right away. A new CMS, written in TypeScript, announced on 1 April, with a name that recalls the punctuation mark people associate with AI-written text. No wonder some thought it was a joke. Matt Kane, the lead engineer, had to tell The Register: "Name is a joke but the project is real." Under WordPress co-founder Matt Mullenweg's blog post, one reader put it dryly: "They posted this on April 1st… I'm not falling for it."

Mullenweg himself took EmDash seriously and wrote detailed feedback. He praised the engineering, the migration tools and the speed, but rejected the claim to WordPress's succession. And he wrote one line that stuck: "Stuff breaks at the edges."

Five months later, on 28 September, EmDash 1.0 came out. Cloudflare opened its release post with exactly the question from April: "Was this just an April Fools' joke? It was not." By then the Cloudflare Blog itself had been running on EmDash since August, and more than 175 people had contributed to the project.

With 1.0, people from the WordPress world came by to see what had actually been delivered. One of them was Paul from WPTuts, who helps people get more out of their WordPress websites. Two days after the release, on 30 September at 9:33 PM, after his first day with EmDash, he posted this tweet:

He was right, and so was Mullenweg: something had broken at exactly that kind of edge. And because Paul wrote it down publicly and concretely instead of quietly deleting EmDash again, the fix was merged the next morning and released that evening. Six days later came the second fix his tweet set in motion. I want to tell this story because it shows what feedback can do in an open source project.

Up front: I'm an EmDash maintainer and wrote both fixes in this article myself. So read this as a view from the inside. Every date is linked so you can check it.

What happened to Paul

Paul had installed EmDash with the "Deploy to Cloudflare" button. It's the fastest way to your own site: one click, Cloudflare sets everything up, you open the address and set up your site.

That exact path was broken. Since EmDash 0.40.1 on 25 September, setup outside local development requires a configured site address: siteUrl, EMDASH_SITE_URL or SITE_URL. The rule came with a security fix, and it's the right rule. But the Deploy button never asks for that address. Anyone who installed that way got as far as the setup wizard and got stuck there with the error SITE_URL_REQUIRED. The only way forward was editing the configuration by hand, which is exactly what Paul described.

While digging in, I found a second problem Paul hadn't even reached yet. A passkey only works at the address where it was created. If you later move your site from its workers.dev address to your own domain, you can no longer sign in there.

From tweet to release

The next morning at 8:56 AM, I replied to Paul: cause found, the problem is on us and not on you, and I'm working on fixes for both issues. I also asked what else had tripped him up.

From there, things moved fast:

From the tweet to the merged fix took a little over 13 hours, and to the release just over 21.

Setup in 1.1.0. On Cloudflare, the setup wizard now takes https:// and the hostname it runs on as the site's address. The fix is small: 59 lines added, 4 removed. Click the Deploy button, open the address, create your account. That's all it takes now. One limit remains, and the changelog says so openly: if you run EmDash on your own Node.js server, you still have to set the address before setup.

Domain changes in 1.2.0. This fix is much bigger, over 2,000 lines across 45 files, because sign-in is involved. Under Settings → General there's now a "Change domain" dialog. EmDash first checks that the new domain really serves the site and only then switches. Anyone still signed in at the old address moves to the new one with "Continue on", without an email, and adds a passkey there. All other users can get an email with the way to the new sign-in page, as long as the site has a plugin that sends email. The details are in our article on EmDash 1.2.

After my first reply, Paul added one more thought that, for me, describes the goal:

That's the bar we measure ourselves against.

He wasn't the only one

The same day, Shane Skwarek wrote in the same thread that the installation had confused him too. After that, he took a Figma design through Claude and had a complete EmDash site in about an hour.

Both belong together: what EmDash can do only lands if the path there doesn't scare people off at the start.

That's the real value of Paul's tweet. A bug that only shows up on a path we rarely take ourselves stays invisible until someone trips over it and says so. Most people don't say so. They close the tab and try something else. Everyone who writes down where they got stuck instead spares everyone after them the same frustration.

Paul's tweet isn't a one-off either. EmDash 1.2 contains 128 pull requests from 24 people and one bot. 51 of them come from Daniel and me, and most of the rest from the community. In our getting started guide I had described how the site title from the setup wizard got lost. Daniel fixed the bug. Many people report a bug and build the fix themselves.

What's still missing

In my second reply to Paul I announced three things. Two have shipped. The third hasn't: new sites should start hidden from search engines while you're still building them, and only enter the search index when you click "Go live". Today a fresh site, sample posts and all, can be found from the first minute. The pull request for it has been open since 1 October. Whether new sites should start this way by default is a product decision that hasn't been made yet.

And Paul's bar still stands. WordPress says in its installation guide that in most cases installing takes less than five minutes. EmDash isn't there yet on every path, especially not on your own server, where you still have to set the address first. Where else EmDash stands next to WordPress, we've laid out in our guide for agencies. We'd rather say that ourselves than have someone else say it for us.

Tell us where it gets stuck

If you try EmDash and get stuck somewhere, say so. It doesn't have to be a perfect bug report. "I clicked X and then saw Y" is often enough to find the cause.

• On GitHub: bugs as an issue, ideas in the Discussions.
• In public, like Paul: a post on X with #EmDash. We read along.
• Here: in the comments below this article. Daniel and I are both EmDash maintainers, and what you write here goes straight into the project.

Thank you, Paul. Thank you, Shane. And thank you to everyone who takes the time to write down what didn't work. That's exactly how EmDash gets better.