Ein Tweet, zwei Releases: Wie Feedback aus der WordPress-Welt EmDash besser macht

Am 1. April 2026 stellte Cloudflare ein neues CMS vor und nannte es gleich den «geistigen Nachfolger von WordPress». Ein neues CMS, in TypeScript geschrieben, angekündigt am 1. April, mit einem Namen, der an das Satzzeichen erinnert, das als typisch für KI-Texte gilt. Kein Wunder, dass manche an einen Scherz glaubten. Matt Kane, der leitende Entwickler, musste gegenüber The Register klarstellen: «Name is a joke but the project is real.» Unter dem Blogpost von WordPress-Mitgründer Matt Mullenweg schrieb ein Leser trocken: «They posted this on April 1st… I'm not falling for it.»

Mullenweg selbst nahm EmDash ernst und schrieb ein ausführliches Feedback. Er lobte die Technik, die Migrationswerkzeuge und das Tempo, wies den Anspruch auf die Nachfolge von WordPress aber zurück. Und er schrieb einen Satz, der hängen bleibt: «Stuff breaks at the edges.» An den Rändern geht etwas kaputt.

Fünf Monate später, am 28. September, erschien EmDash 1.0. Cloudflare eröffnete den Blogpost zum Release mit genau der Frage aus dem April: «Was this just an April Fools' joke? It was not.» Der Cloudflare-Blog läuft da schon seit August selbst auf EmDash. Über 175 Leute haben bis dahin am Projekt mitgearbeitet.

Mit 1.0 kamen auch Leute aus der WordPress-Welt vorbei, um nachzusehen, was da eigentlich abgeliefert wurde. Einer von ihnen war Paul von WPTuts, der Leuten hilft, mehr aus ihrer WordPress-Website herauszuholen. Zwei Tage nach dem Release, am 30. September um 21:33 Uhr, schrieb er nach seinem ersten Tag mit EmDash diesen Tweet:

Auf Deutsch: Wer mit WordPress mithalten will, muss die Installation in den Griff bekommen. Konfigurationsdateien von Hand ändern, nur um sich anmelden zu können, ist keine gute Erfahrung.

Er hatte recht, und Mullenweg auch: Genau an so einem Rand war etwas kaputt. Und weil Paul es öffentlich und konkret aufgeschrieben hat, statt EmDash still wieder zu löschen, war der Fix am nächsten Vormittag gemergt und am Abend veröffentlicht. Sechs Tage später kam der zweite Fix, den sein Tweet ausgelöst hat. Diese Geschichte will ich erzählen, weil sie zeigt, was Feedback in einem Open-Source-Projekt bewirken kann.

Vorweg: Ich bin Maintainer bei EmDash und habe die beiden Fixes in diesem Artikel selbst geschrieben. Lies das also als Blick von innen. Alle Daten sind verlinkt, damit du sie nachprüfen kannst.

Was Paul passiert ist

Paul hatte EmDash über den Button «Deploy to Cloudflare» installiert. Das ist der schnellste Weg zu einer eigenen Site: ein Klick, Cloudflare legt alles an, du öffnest die Adresse und richtest deine Site ein.

Genau dieser Weg war kaputt. Seit EmDash 0.40.1 vom 25. September verlangt das Setup ausserhalb der lokalen Entwicklung eine fest eingestellte Adresse der Website, also siteUrl, EMDASH_SITE_URL oder SITE_URL. Die Regel kam mit einem Sicherheitsfix und ist richtig. Nur fragt der Deploy-Button nie nach dieser Adresse. Wer so installierte, kam bis zum Einrichtungs-Assistenten und blieb dort mit dem Fehler SITE_URL_REQUIRED stecken. Weiter ging es nur mit Handarbeit an der Konfiguration, und genau die hat Paul beschrieben.

Beim Nachforschen bin ich auf ein zweites Problem gestossen, das Paul noch gar nicht erreicht hatte. Ein Passkey gilt nur für die Adresse, auf der er angelegt wurde. Wer seine Site später von der Adresse unter workers.dev auf die eigene Domain umzieht, kann sich dort nicht mehr anmelden.

Vom Tweet zum Release

Am nächsten Morgen um 8:56 Uhr habe ich Paul geantwortet: Ursache gefunden, der Fehler liegt bei uns und nicht bei dir, ich arbeite an Lösungen für beide Probleme. Und ich habe gefragt, was ihn sonst noch gestört hat.

Danach ging es schnell:

Vom Tweet bis zum gemergten Fix vergingen etwas mehr als 13 Stunden, bis zum Release gut 21.

Das Setup in 1.1.0. Auf Cloudflare übernimmt der Einrichtungs-Assistent jetzt https:// und den Hostnamen, auf dem er läuft, als Adresse der Site. Der Fix ist klein, 59 Zeilen kamen dazu, 4 fielen weg. Deploy-Button klicken, Adresse öffnen, Konto anlegen: Mehr braucht es nicht mehr. Eine Grenze bleibt, und der Changelog nennt sie offen: Wer EmDash auf einem eigenen Node.js-Server betreibt, muss die Adresse weiterhin vor dem Setup eintragen.

Der Domainwechsel in 1.2.0. Dieser Fix ist deutlich grösser, über 2000 Zeilen in 45 Dateien, weil hier die Anmeldung mitspielt. Unter Einstellungen → Allgemein gibt es jetzt den Dialog «Domain ändern». EmDash prüft zuerst, ob die neue Domain die Site wirklich ausliefert, und stellt erst dann um. Wer noch auf der alten Adresse angemeldet ist, kommt mit «Weiter auf …» ohne E-Mail auf die neue und legt dort einen Passkey an. Alle anderen Nutzer bekommen auf Wunsch eine E-Mail mit dem Weg zur neuen Anmeldeseite, sofern die Site ein Plugin hat, das E-Mails verschickt. Die Details stehen in unserem Artikel zu EmDash 1.2.

Auf meine erste Antwort hatte Paul noch einen Satz nachgeschoben, der für mich das Ziel beschreibt:

Daran messen wir uns.

Er war nicht der Einzige

Am selben Tag schrieb Shane Skwarek im selben Thread, dass ihn die Installation auch verwirrt hatte. Danach hat er mit Figma und Claude in etwa einer Stunde eine komplette Site mit EmDash gebaut.

Beides gehört zusammen: Was EmDash kann, kommt erst an, wenn der Weg dorthin nicht schon am Anfang abschreckt.

Das ist der eigentliche Wert von Pauls Tweet. Ein Fehler, der nur auf einem Weg auftritt, den wir selbst selten gehen, bleibt unsichtbar, bis jemand darüber stolpert und es sagt. Die meisten sagen es nicht. Sie schliessen den Tab und probieren etwas anderes. Jeder, der stattdessen aufschreibt, wo er hängen geblieben ist, erspart allen nach ihm denselben Frust.

Pauls Tweet ist auch kein Einzelfall. In EmDash 1.2 stecken 128 Pull Requests von 24 Personen und einem Bot. 51 davon kommen von Daniel und mir, der grösste Teil vom Rest aus der Community. In unserem Einsteiger-Artikel hatte ich beschrieben, dass der Titel aus dem Einrichtungs-Assistenten verloren ging. Daniel hat den Fehler behoben. Viele melden einen Fehler und bauen den Fix gleich selbst.

Was noch fehlt

In meiner zweiten Antwort an Paul habe ich drei Dinge angekündigt. Zwei sind geliefert. Das dritte nicht: Neue Sites sollen unsichtbar für Suchmaschinen starten, solange du sie noch aufbaust, und erst mit einem Klick auf «Live schalten» in den Suchindex kommen. Heute ist eine frische Site mit ihren Beispielbeiträgen ab der ersten Minute auffindbar. Der Pull Request dafür ist seit dem 1. Oktober offen. Ob neue Sites standardmässig so starten sollen, ist eine Produktentscheidung, und die steht noch aus.

Und Pauls Massstab gilt weiter. WordPress schreibt in seiner Installationsanleitung, die Installation dauere in den meisten Fällen weniger als fünf Minuten. So weit ist EmDash noch nicht auf jedem Weg, vor allem nicht auf dem eigenen Server, wo du die Adresse weiterhin vorher eintragen musst. Wo EmDash sonst im Vergleich zu WordPress steht, haben wir im Leitfaden für Agenturen zusammengetragen. Das sagen wir lieber selbst, bevor es jemand anderes tun muss.

Sag uns, wo es hakt

Wenn du EmDash ausprobierst und irgendwo hängen bleibst, sag es. Es muss kein perfekter Bugreport sein. «Ich habe X geklickt und dann Y gesehen» reicht oft schon, um die Ursache zu finden.

• Auf GitHub: Fehler als Issue, Ideen in den Discussions.
• Öffentlich wie Paul: Ein Post auf X mit #EmDash. Wir lesen mit.
• Hier: In den Kommentaren unter diesem Artikel. Daniel und ich sind beide Maintainer bei EmDash, und was du hier schreibst, nehmen wir direkt ins Projekt mit.

Danke, Paul. Danke, Shane. Und danke an alle, die sich die Zeit nehmen, aufzuschreiben, was nicht funktioniert hat. Genau so wird EmDash besser.