EmDash 1.3: besser im Team, gründlicher beim WordPress-Umzug

Getestet mit EmDash 1.3.0 und dem Update von 1.2.0 mit der Blog-Vorlage für Cloudflare, Astro 7.3.8 und Node.js 22.

Bis jetzt war EmDash vor allem ein CMS für Leute, die allein schreiben. Wer einer Kollegin nur das Entwerfen erlauben wollte, stiess auf Fehlermeldungen, und wer wissen wollte, wer einen Absatz umgeschrieben hat, las rohes JSON. EmDash 1.3 ändert das. Dazu kommt ein WordPress-Import, der deutlich mehr von der alten Site mitnimmt, und Seiten auf Cloudflare, die weniger auf die Datenbank warten.

110 Pull Requests sind seit 1.2 zusammengekommen, von 18 Leuten und einem Bot. 32 davon sind von Daniel und mir, 28 allein von Noah Pham, der unter anderem den neuen Versionsverlauf gebaut hat. Wir sagen dir, was davon für dich zählt, was wir beim Update erlebt haben und welche zehn Punkte du vorher prüfen solltest. Neu bei EmDash? Dann fang mit unserem Einstieg in EmDash an.

EmDash 1.3 in Kürze

• Für Teams: Mitwirkende können ihre Entwürfe endlich speichern, und der Versionsverlauf zeigt jede Änderung samt Namen.
• Für WordPress-Umsteiger: ACF-Felder, interne Links und dynamische Blöcke kommen beim Import an.
• Für Sites auf Cloudflare: weniger Wartezeit auf D1 und ein Workers Cache, den Entwürfe nicht mehr leeren.
• Fürs Schreiben auf der Website: Visual Editing bekommt die Leiste des Admins und eine Bildauswahl.
• Für die Sichtbarkeit: ein Schalter in den SEO-Einstellungen, der KI-Crawler bittet, deine Texte nicht zum Training zu nutzen.
• Neue Vorlagen: Blog und Marketing sehen neu aus, und seit dem 16. Oktober bekommt sie auch, wer mit npm create emdash eine neue Site anlegt.

Zu mehreren an einer Site arbeiten

Mitwirkende können ihre Entwürfe speichern

EmDash kennt die Rolle Contributor für Leute, die schreiben, aber nicht veröffentlichen sollen, etwa Gastautoren oder Praktikanten. In 1.2 war sie kaum zu gebrauchen: Anlegen ging, aber schon das nächste Speichern, das Sperren des Eintrags und das Setzen von Kategorien scheiterten mit „403“. Jetzt bearbeiten Mitwirkende ihre eigenen Einträge, solange sie Entwürfe sind, im Admin, über die API und über MCP (#4133). Veröffentlichen oder veröffentlichte Beiträge ändern können sie weiterhin nicht.

Auch das Dashboard funktioniert jetzt für Benutzer, die keine Entwürfe sehen dürfen, etwa Abonnenten (#4171). Und wer seine Leute über Cloudflare Access anmeldet, sollte die Rollen-Nummern prüfen: Der Hinweis im Code nannte Rolle 30 „Editor“, tatsächlich darf 30 eigene Beiträge veröffentlichen. Für Leute, die nur entwerfen sollen, ist 20 richtig (#4053).

Sehen, wer was geändert hat

Dass EmDash alte Fassungen aufbewahrt, half bisher nur, wenn man wusste, welche man suchte. Im Bereich Revisionen standen die Unterschiede als JSON, ohne Namen. Jetzt öffnet ein Klick auf eine Fassung sie im Editor (#4136). Was dazukam, ist farbig hinterlegt, was wegfiel, durchgestrichen, und jede Person hat ihre eigene Farbe. Eine kurze Liste nennt die Änderungen in Worten und springt beim Klick an die Stelle. Wiederherstellen geht über eine Leiste am unteren Rand. Solange eine alte Fassung offen ist, kannst du weder speichern noch veröffentlichen, und Ungespeichertes geht dabei nicht verloren.

Im deutschen Admin sind diese Texte noch englisch, etwa „Changed the title“. Für Entwickler: Die API und das MCP-Werkzeug revision_list liefern zu jeder Fassung jetzt auch den Namen dessen, der sie gespeichert hat.

Autoren mit allem anlegen

Wer im Editor einen neuen Autor anlegte, bekam bisher nur Name und Slug. Jetzt öffnet Erstellen dasselbe Formular wie die Autorenseite, mit Website, Bio, Avatar, verknüpftem Benutzer und eigenen Feldern (#4050). Neu angelegte Autoren sind dabei keine Gastautoren mehr, ausser du schaltest das im Formular ein. Die Autorenseite selbst sagt jetzt, was fehlt, statt den Knopf ohne Erklärung grau zu lassen (#3967).

Umzug von WordPress: der Import nimmt mehr mit

Wer von WordPress umzieht, bekommt mit 1.3 mehr von der alten Site herüber. Den grössten Teil dieser Fixes haben Daniel und ich geschrieben:

• ACF-Felder. Über das Plugin EmDash Exporter kommen die Werte von Advanced Custom Fields jetzt vollständig an. Jedes Feld einer ACF-Gruppe wird zum Feld in EmDash, Wiederholungen, Gruppen und Beziehungen landen als JSON. Verknüpfte Beiträge und Benutzer kommen nur als ID mit, Passwörter und fremde Inhalte bleiben draussen (#4092). Wie wir das bisher von Hand gelöst haben, steht im Artikel zum ACF-Import.
• Interne Links. Links auf die alte WordPress-Domain werden zu relativen Pfaden, die Struktur der Permalinks bleibt. Weichen deine Routen ab, brauchst du Weiterleitungen (#3892).
• Dynamische Blöcke. Blöcke, die WordPress erst beim Aufruf erzeugt, etwa „Neueste Beiträge“ oder Blöcke aus Plugins, verschwanden bisher spurlos. Jetzt bleiben sie als HTML-Block mit dem Original-Kommentar stehen, damit du siehst, was dort war (#4055).
• Bot-Schutz. Blockt der Bot-Schutz von Cloudflare den Import, sagt EmDash das jetzt und erklärt, wie du ihn durchlässt. Bisher hiess es nur, WordPress sei nicht erkannt worden (#4150).
• Kleinere Fixes. Der XML-Import legt keine Sammlungen für die internen Typen von ACF mehr an (#4090), Hoster, die Anfragen ohne User-Agent blocken, antworten nicht mehr mit 403 (#4113), und die Zahl der übersprungenen Einträge stimmt (#4056).

Ob sich der Umzug für Kundenprojekte lohnt, klärt unser Leitfaden für Agenturen. Und wer von WordPress kommt, findet den Einstieg in EmDash für WordPress-Umsteiger.

Schneller auf Cloudflare

Weniger Warten auf D1

Jede Abfrage an D1 ist eine Fahrt durchs Netz zur Datenbank. Einen Teil davon verursachte EmDash selbst, und darüber bin ich auf unserer eigenen Site gestolpert: Mit session: "auto" schickte es bei jeder Seite Einstellungen, Menüs, Widget-Bereiche und Begriffe vorab los. Eine Session arbeitet ihre Abfragen nacheinander ab, also stand die eigentliche Abfrage der Seite hinten an. In dieser Konfiguration lässt EmDash das jetzt bleiben. Diesen PR habe ich geschrieben (#3937).

Besser noch ist es, die Abfragen zu bündeln. Neue Sites aus den Cloudflare-Vorlagen tun das ab jetzt, für eine bestehende Site reicht eine Zeile in astro.config.mjs:

database: d1({ binding: "DB", session: "auto", coalesce: true }),

Abfragen, die gleichzeitig starten, laufen dann in einer einzigen Fahrt. The Weekly Dash läuft seit Wochen so. coalesce ist noch experimentell: Startet ein Schreiben gleichzeitig mit einem Lesen, kann das Schreiben zuerst laufen. Noch mehr als die Zahl der Fahrten zählt ihre Länge, also wo die Datenbank steht. Das zeigen wir in D1-Region und Ladezeit.

Dazu kommen zwei kleinere Einsparungen. Passen die Kommentare auf eine Seite, holt getComments() sie mit einer Abfrage statt zwei (#3907). Und nach einem Cold Start spart EmDash bis zu zwei Abfragen, wenn der Plugin-Marktplatz eingeschaltet ist (#3584).

Ein Cache, der länger hält

Auf Cloudflare legt EmDash fertige Seiten in den Workers Cache und löscht sie, sobald sich etwas ändert. In 1.2 löschte schon das Anlegen oder Duplizieren eines Entwurfs alle Seiten mit einer Beitragsliste, obwohl Leser davon nichts sehen. Das habe ich bei Messungen für einen Artikel über den Cache gefunden und behoben (#4128). Veröffentlichen und Korrekturen an veröffentlichten Beiträgen leeren die Listen weiterhin. Wie wir den Cache auf dieser Site einsetzen, steht in Edge-Caching für EmDash auf Cloudflare.

• Weiterleitungen greifen sofort. Eine neue Weiterleitung für eine Seite im Cache wurde bisher ignoriert, bis die Kopie ablief (#3982, #3997).
• Gespeichert heisst gespeichert. Schlug das Leeren des Caches fehl, meldete der Admin einen Fehler, obwohl die Änderung längst gespeichert war. Jetzt meldet er Erfolg und schreibt den Fehler ins Log (#3987).

Neue Vorlagen für Blog und Marketing

Die Blog-Vorlage, aus der auch The Weekly Dash entstanden ist, hat ein neues Design (#3951) und folgt jetzt der Sprache der Site. Seitensprache, Datumsformat und RSS-Feed waren bisher fest auf Englisch, sodass Screenreader auch deutsche Beiträge englisch vorlasen (#3966). Die Marketing-Vorlage ist komplett neu: Sie startet mit einer erfundenen Firma samt Fotos, und alles, was bisher im Code stand, pflegst du im Admin (#3969). Dafür kann der Menü-Editor jetzt Menüs umbenennen und Einträgen CSS-Klassen geben.

Am Tag des Releases kamen die neuen Vorlagen bei npm create emdash noch nicht an, denn der Befehl lädt sie nicht aus dem Hauptprojekt, sondern aus einem eigenen Repository. Dort wurden sie am 16. Oktober nachgezogen (templates#64). Wer jetzt eine neue Site anlegt, bekommt die neuen Vorlagen. Bestehende Sites betrifft das nicht, das Update ändert ihr Aussehen ohnehin nicht.

Bearbeiten direkt auf der Website

Visual Editing, also das Schreiben direkt auf der fertigen Seite, hinkte dem neuen Editor aus 1.2 hinterher. Jetzt hat es dieselbe Leiste für Formatierung und Links und dasselbe Slash-Menü (#4117). Bilder fügst du mit /image aus der Mediathek ein und bearbeitest Alt-Text und Bildunterschrift an Ort und Stelle (#4137). Hochladen geht auf der Seite nicht, neue Bilder lädst du vorher im Admin hoch.

Wichtiger im Alltag sind vielleicht die Fixes: Ein leerer Text, etwa in einem neuen Beitrag, lässt sich jetzt überhaupt auf der Seite bearbeiten, und das Speichern beim Verlassen eines Felds legt nicht mehr jedes Mal eine neue Revision an (#3942). Ein Klick in ein Feld markiert nicht mehr den ganzen Text, sodass der erste Tastendruck alles ersetzte (#4014).

robots.txt: Suche ja, KI-Training nein

Für viele Sites ist die Frage gerade, ob KI-Firmen ihre Texte zum Training nutzen dürfen. EmDash 1.3 hat dafür unter Einstellungen → SEO einen Schalter Disallow AI training (#3623). Diesen PR habe ich geschrieben. Eingeschaltet trägt er die bekannten Trainings-Crawler in robots.txt ein, darunter GPTBot, ClaudeBot, Google-Extended und CCBot, und ergänzt die Zeile Content-Signal: search=yes, ai-train=no.

Für die Sichtbarkeit ist wichtig, was der Schalter nicht tut: Er sperrt keine Suchmaschine. Google findet deine Seiten weiter, Google-Extended regelt nur das Training. Auch die Crawler, mit denen ChatGPT für Antworten sucht, stehen nicht auf der Liste, du bleibst also in KI-Antworten auffindbar. Der Schalter ist aus, bis du ihn einschaltest, und er gilt auch für eine eigene robots.txt. Wie alles in dieser Datei ist er eine Bitte. Seriöse Crawler halten sich daran, andere nicht.

Kleine Fixes im Admin

• Ein geleertes Zahlenfeld wird als leer gespeichert statt als 0, und Dezimalzahlen wie 4.50 blockieren das Speichern nicht mehr (#3791). Ein geleertes optionales URL-Feld lässt sich wieder speichern (#4076).
• Wer einen Eintrag nur öffnet, erzeugt keinen Entwurf mehr. Bisher standen bei Inhalten aus MCP „Ausstehende Änderungen“, die niemand gemacht hatte (#4035).
• Tabellen aus Google Docs mit ausgerichteten oder verbundenen Zellen lassen sich einfügen (#4141).
• Die Gliederung im Editor springt beim Klick auf eine Überschrift zuverlässig dorthin und zeigt beim Scrollen, wo du bist (#4152).
• /video öffnet zuerst die Mediathek, wie /image (#3936), und Uploads in einen Ordner der Mediathek landen in diesem Ordner (#4081).
• Das OG-Bild im SEO-Bereich zeigt die Vorschau im Format, das soziale Netzwerke nutzen (#4115).
• Der erste Admin ist nach dem Anlegen des Passkeys gleich angemeldet, statt auf der Anmeldeseite zu landen (#4000).
• Die Suche findet wieder etwas, wenn die Anfrage Wörter wie „and“ oder „or“ enthält (#3202).

Für Agenturen, Entwickler und KI-Agenten

• MCP: content_create nimmt jetzt seo und publishedAt an (#4102). Schreibvorgänge ohne Block-Feld scheitern nicht mehr (#3824), und Blöcke ohne _type gehen durch, wenn nur ein Typ erlaubt ist (#3825).
• Plugin-Werkzeuge über MCP: Plugins mit Namen wie @acme/calendar liefern ihre Werkzeuge unter Namen, die MCP-Clients akzeptieren. Ein Werkzeug mit fehlerhaftem Schema legt nicht mehr alle anderen lahm (#988).
• Passende Versionen: astro build und astro dev warnen, wenn emdash und @emdash-cms/cloudflare verschiedene Versionen haben, und nennen den Befehl, der das behebt (#4058).
• Hängende Migration: emdash migrate --take-over-lock <id> führt Migrationen unter einer hängengebliebenen D1-Sperre aus, ohne dass ein Worker sie dazwischen schnappt (#4068). Die Migration für Datumsangaben läuft auf grossen D1-Datenbanken in Paketen und macht nach einem Abbruch dort weiter, wo sie stand (#4072).
• CLI: emdash whoami funktioniert hinter Cloudflare Access und taugt als Prüfung, ob die Site erreichbar ist (#4034). emdash seed legt Medien nicht mehr doppelt an (#3921).
• Formular-Plugin: Die tägliche Zusammenfassung wird wieder verschickt (#3979), und dasselbe Formular kann zweimal auf einer Seite stehen (#3031).

Der Admin auf Deutsch und in mehr Sprachen

Den deutschen Admin hat Daniel vervollständigt (#4084). Die englischen Reste aus 1.2, die wir im Artikel zu EmDash 1.2 gezeigt hatten, etwa „Basic blocks“ oder „Upload or choose a video“, sind übersetzt. Englisch sind nur die Texte der neuen Funktionen aus 1.3, zum Beispiel im Versionsverlauf und beim Schalter gegen KI-Training.

Kroatisch ist als neue Sprache dazugekommen, zu rund 99 % übersetzt (#3934). Polnisch (#3970) und Französisch (#4134) sind vollständig, Schwedisch, Hindi und Indonesisch vollständiger. Italienisch hat einen ersten Anfang, ist aber noch nicht auswählbar (#4026). Datumsangaben folgen jetzt überall der Sprache des Admins statt der des Browsers (#3292).

Wie EmDash entschieden wird

Eine Änderung sieht man im Admin nicht, sie betrifft aber alle, die mitarbeiten: EmDash hat jetzt festgeschriebene Regeln für Governance und Beiträge (#3808). Es gibt eine öffentliche Liste der Maintainer, eine Roadmap, Feature-Pläne für überschaubare Vorhaben und RFCs für grössere Entscheidungen, dazu Regeln für Code, der mit KI entstanden ist. Daniel und ich sind beide Maintainer.

Update auf EmDash 1.3: das solltest du vorher prüfen

Eine neue Datenbank-Migration bringt 1.3 nicht mit. Die meisten Änderungen brauchen nichts von dir, diese zehn Punkte solltest du aber vor dem Update anschauen:

1. Gastautoren: Autoren, die du im Editor anlegst, sind nicht mehr automatisch Gastautoren. Liest deine Vorlage byline.isGuest, zeigt sie neue Autoren als normale Autoren, ausser du schaltest im Formular Gastautor ein. Bestehende Autoren ändern sich nicht (#4050).
2. Rollen bei Cloudflare Access: Hast du defaultRole oder roleMapping auf 30 gesetzt, damit Leute nicht veröffentlichen können, nimm 20. Rolle 30 darf eigene Beiträge veröffentlichen (#4053).
3. Frühere ACF-Importe: Hast du Beziehungs- oder Benutzerfelder schon mit einer älteren Version importiert, prüfe diese JSON-Felder auf ganze WordPress-Beiträge oder Benutzer. Ein neuer Import überspringt bestehende Einträge und korrigiert sie nicht (#4092).
4. Leere Zahlenfelder: Ein geleertes Zahlenfeld ist jetzt leer statt 0. Rechnet deine Vorlage mit dem Wert, fang den leeren Fall ab (#3791).
5. Leere URL-Felder: Ein geleertes optionales URL-Feld ist jetzt null statt einer leeren Zeichenkette (#4076).
6. `where` mit einem Objekt: where: { feld: { in: [...] } } hat nie gefiltert und lieferte stillschweigend alle Einträge. Jetzt steht eine Warnung im Log. Für eine Liste nimmst du ein Array: where: { feld: [...] } (#3265).
7. MCP-Namen von Plugins: Hast du Aufrufe von Plugin-Werkzeugen mit Namen wie @acme/calendar gespeichert, heissen sie jetzt acme__calendar__<werkzeug> (#988).
8. Plugins ohne Sandbox: Mit sandbox: false startet die Site nicht mehr, wenn das Plugin-System nicht geladen werden kann. Bisher startete sie still ohne Plugins aus dem Marktplatz (#3584).
9. Visual Editing in eigenen Vorlagen: Im Bearbeitungsmodus ist ein leeres Portable-Text-Feld jetzt ein leeres Array statt null (#3942).
10. Eigener Admin mit `ContentEditor`: Der Callback onRevisionRestored darf jetzt ein Promise zurückgeben. Liest dein Admin item nicht aus der content-Abfrage des Eintrags, musst du es im Callback neu laden (#4136).

So aktualisierst du auf EmDash 1.3

Ein Update ist ein Deployment: Du hebst die Pakete im Projekt an und stellst die Site neu online. Deine Inhalte bleiben in der Datenbank. Am einfachsten geht das mit upgrade-emdash:

npx upgrade-emdash@latest
npm run deploy

Ich habe das an einer Kopie unserer Testsite mit der Blog-Vorlage für Cloudflare ausprobiert. Der Probelauf mit --dry-run meldete zwei Pakete von 1.2.0 auf 1.3.0 und 48 Changelog-Einträge. Das echte Update brauchte 31 Sekunden, brachte keine neue Migration, und der Build lief danach ohne Fehler durch. Alle sieben Beiträge waren noch da. Neu legt der Befehl dabei sechs Skills für KI-Agenten in .agents/skills ab, darunter einen fürs Aktualisieren selbst. Die Datei .emdash/UPGRADE.md mit allen Änderungen ist als Arbeitsauftrag für dich oder einen Agenten gedacht.

Von Hand geht es weiterhin, bei einer Site aus der Cloudflare-Vorlage mit zwei Befehlen:

npm install emdash@latest @emdash-cms/cloudflare@latest
npm run deploy

Halte emdash und @emdash-cms/cloudflare auf derselben Version, ab 1.3 warnt der Build sonst. Auf Cloudflare startet jeder Deploy mit einem leeren Cache. Plane das Update deshalb nicht direkt vor einer Veröffentlichung, auf die viele Leser warten.

Wie du vorher einen Sicherungspunkt setzt und im Notfall zurückkommst, zeige ich Schritt für Schritt in EmDash aktualisieren.

Und bei dir?

Arbeitest du mit mehreren Leuten an einer EmDash-Site, oder ziehst du gerade von WordPress um? Was hilft dir an 1.3 am meisten, und wo hakt es noch? Schreib es unten in die Kommentare. Daniel und ich sind beide Maintainer bei EmDash und lesen mit: Was du hier meldest, nehmen wir direkt ins Projekt mit.