EmDash 1.3.1: sicherere Änderungen, weniger hängende Seiten

Getestet mit dem Update einer Kopie von The Weekly Dash von EmDash 1.3.0 auf 1.3.1, mit Astro 7.3.5 und Node.js 24.

EmDash 1.3.1 ist am 18. Oktober 2026 erschienen, drei Tage nach 1.3.0. Es ist ein reines Fehlerbehebungs-Release: nichts Neues zu lernen, keine Änderung am Aufbau deiner Datenbank, nur Korrekturen. 41 Änderungen stecken darin. 23 davon haben die beiden Bots des Projekts geschrieben, emdashbot und emdash-autofix, und jede hat ein Mensch geprüft und freigegeben. Neun sind von mir, den Rest haben sieben weitere Leute beigesteuert, die meisten davon Übersetzer. Danke euch allen.

Die meisten Korrekturen sind klein, ein paar betreffen aber deine Inhalte und wer sie sehen darf. Klingt einer dieser Punkte nach deiner Site, aktualisiere bald:

Du ziehst Beiträge oder andere Einträge zurück, und zwar in einem Inhaltstyp, der keine Revisionen (ältere Fassungen) aufbewahrt. Bisher konnten deine nächsten Änderungen dabei überschrieben werden.
Deine Site hat Abonnenten oder andere Benutzer, die keine Entwürfe sehen sollen. Über die API oder einen KI-Assistenten, der per MCP verbunden ist, konnten sie Unveröffentlichtes lesen.
Deine Site läuft auf Cloudflare Workers und zeigt Kategorien oder Tags. Ein einziger Besucher, der im falschen Moment ging, konnte diese Seiten für alle anderen hängen lassen.

EmDash 1.3.1 in Kürze

Dein Schreiben: Änderungen überstehen das Zurückziehen, ein neuer Eintrag fragt nach, bevor du ihn ungespeichert verlässt, und neue Links öffnen im selben Tab.
Wer was sieht: Entwürfe bleiben vor Abonnenten verborgen, und Mitwirkende sehen nur noch Knöpfe, die sie auch nutzen dürfen.
Cloudflare: Ein halb fertiges Update zeigt eine Fehlermeldung statt leerer Seiten, Seiten mit Kategorien und Tags bleiben nicht mehr hängen, und der Cache hält keine alten Website-Einstellungen mehr fest.
Kommandozeile: emdash login findet die richtige Site, und die CLI bleibt hinter Cloudflare Access angemeldet.
Sprachen: Den Admin gibt es jetzt auf Russisch, und Japanisch, Indonesisch und Hindi sind vollständiger.

Korrekturen, die dein Geschriebenes schützen

Änderungen verschwinden nach dem Zurückziehen nicht mehr

Das ist die wichtigste Korrektur. In einem Inhaltstyp ohne Revisionen zeigte der Editor nach dem Zurückziehen eines Eintrags bei jedem Speichern wieder den alten, veröffentlichten Text. Hast du danach noch einmal gespeichert, hat dieser alte Text deine Änderungen überschrieben. Jetzt bleiben deine Änderungen erhalten, auch bei Einträgen, die du vor dem Update zurückgezogen hast (#4207). Hast du so etwas schon einmal gemacht, schau kurz nach, ob dein neuester Text noch da ist.

Ein neuer Eintrag fragt, bevor du gehst

Hast du einen neuen Eintrag angefangen und im Admin eine andere Seite angeklickt, bevor du ihn zum ersten Mal gespeichert hattest, war er einfach weg, ohne Warnung. Jetzt fragt der Admin vorher nach, und wenn du den Tab neu lädst oder schließt, fragt auch dein Browser (#4206).

Links öffnen wieder im selben Tab

Jeder Textlink, den du im Editor oder beim Bearbeiten direkt auf der Seite gesetzt hast, wurde so gespeichert, dass er in einem neuen Tab öffnet, ob du das wolltest oder nicht. Ausgesucht hat sich das niemand: Es war eine Voreinstellung in einem Werkzeug, auf dem der Editor aufbaut. Neue Links öffnen jetzt im selben Tab (#4106). Links, die du vor dem Update gespeichert hast, öffnen weiter in einem neuen Tab. Willst du das ändern, setz den Link neu.

Bildunterschriften werden gespeichert

In Bildfeldern konntest du eine Bildunterschrift eintippen, gespeichert wurde sie aber nie. Jetzt schon, und sie kommt auch mit, wenn du eine Seed-Datei exportierst oder importierst (#4201). Verlorene Bildunterschriften holt das Update nicht zurück: Wähl das Bild neu aus oder bearbeite seine Bildunterschrift, dann speichern und veröffentlichen.

Wer was sehen darf

Drei meiner Korrekturen drehen sich darum, wer was sehen und tun darf. Sie bauen auf den Korrekturen für Mitwirkende aus 1.3 auf:

Entwürfe bleiben privat. Abonnenten und andere Benutzer, die keine Entwürfe lesen dürfen, konnten über die API trotzdem sehen, welche Kategorien, Tags und Übersetzungen ein Entwurf oder ein geplanter Beitrag hatte. Ein KI-Assistent, der per MCP verbunden war, konnte sogar die unveröffentlichten Änderungen selbst lesen. Jetzt bekommen sie „nicht gefunden“, und über MCP sehen sie nur, was veröffentlicht ist (#4179).
Nur Knöpfe, die funktionieren. Mitwirkende und Autoren sahen Duplizieren, Veröffentlichen, Zurückziehen und Planen auch bei Einträgen, bei denen ein Klick nur ein „Nein“ brachte. Ein Eintrag, den sie nicht speichern dürfen, öffnet sich jetzt nur zum Lesen, mit einem Hinweis, warum (#4177).
Benutzerzahl nur für Admins. Das Dashboard zeigte, wie viele Benutzer die Site hat, auch Leuten, die die Benutzerliste gar nicht sehen dürfen. Jetzt sehen nur noch Administratoren diese Karte (#4181).

Weniger Überraschungen auf Cloudflare

Eine Fehlermeldung statt leerer Seiten

Wenn du EmDash aktualisierst, bringt deine Site ihre Datenbank normalerweise beim ersten Aufruf nach dem Deployment selbst auf den neuen Stand. EmDash nennt diese Schritte Migrationen. Liefen sie nicht durch, lieferte eine Site auf Workers weiter Seiten ohne Inhalt aus und meldete dabei, alles sei in Ordnung. Werkzeuge, die prüfen, ob deine Site erreichbar ist, merkten nichts. Jetzt antwortet die Site mit einem Fehler, 503 („vorübergehend nicht verfügbar“), bis die Datenbank auf dem neuen Stand ist (#4069).

Außerdem startet eine laufende Site die richtig großen Umstellungen nicht mehr von selbst, also solche, die jeden Eintrag und jede ältere Fassung anfassen, etwa die Datumsumstellung aus 0.39.0. Kommst du von 0.38 oder älter, führ vor dem Deployment emdash migrate aus, wie es die Doku unter Apply large content migrations from the CLI erklärt. Zeigt deine Site nach einem Update eine 503, schau ins Log deines Workers im Cloudflare-Dashboard. Dort steht, was los ist: Entweder wartet noch eine Datenbank-Umstellung, die du mit emdash migrate anwendest, oder eine frühere ist hängen geblieben und blockiert den Rest. Für diesen Fall gibt es Release a stuck migration lock.

Seiten mit Kategorien und Tags bleiben nicht mehr hängen

Auf Workers konnte ein einzelner Besucher jede Seite lahmlegen, die Kategorien, Tags oder die Zahl der Beiträge dazu zeigt. Ging er genau im falschen Moment, während EmDash seine Liste der Kategorien, Tags oder Inhaltstypen lud, wartete jeder spätere Besucher, den dieselbe Kopie deiner Site bediente, bis Cloudflare mit einem Fehler 524 aufgab. Jetzt hält ein Besucher, der früh geht, niemanden mehr auf (#4203).

Der Cache lässt alte Einstellungen los

Nach dem Leeren des Caches konnten Seiten mit alten Website-Einstellungen wieder im Cache landen: mit veraltetem Titel, altem Logo oder ohne den Tag, mit dem du Google und anderen zeigst, dass die Site dir gehört. Jetzt liest EmDash die Einstellungen frisch, wenn es den Cache füllt, und prüft die Einstellungen, die es sich merkt, noch einmal, sobald sie 30 Sekunden alt sind (#4226). Wie wir den Cache auf dieser Site nutzen, steht in Edge-Caching für EmDash auf Cloudflare.

Kleinere Korrekturen auf Cloudflare

Die Suche ist auf D1 schneller: Sie fragt die Datenbank seltener, auch wenn nichts passt, und eine leere Suche fragt gar nicht mehr (#4220).
Plugins, die Daten speichern, schreiben nicht mehr bei jedem Start dieselbe Einrichtung neu. Das spart Schreibzugriffe auf D1 (#4229).
Viele auf einmal: Bis zu 100 Kommentare auf einmal ändern oder einen Beitrag mit mehr als 100 Autoren speichern scheitert nicht mehr an einem Datenbankfehler (#4256).
Startinhalte: Kamen mehrere Besucher im selben Moment auf eine neue Site, konnten ihre Startmenüs und Widgets doppelt erscheinen. Auf D1 ist das behoben (#4225).
Bildqualität: Hast du Astro mit quality="low" oder ähnlich nach leichteren Bildern gefragt, schickte EmDash auf Cloudflare trotzdem das Original in voller Größe. Jetzt bedeuten low, mid, high und max 25, 50, 80 und 100 (#4221).

Weiterleitungen und Menüs

Alte Weiterleitungen: Änderst du die Adresse eines Beitrags (seinen Slug), leitet EmDash Besucher von der alten Adresse zur neuen weiter. Hast du später einen neuen Eintrag unter der alten Adresse veröffentlicht, kamen Besucher nie bei ihm an. Jetzt entfernt das Veröffentlichen die alte Weiterleitung (#4074).
Menüs: Menüeinträge, deren übergeordneter Eintrag fehlte, in einem anderen Menü stand oder eine Schleife bildete, konnten aus dem Menü auf deiner Site verschwinden. Solche Änderungen werden jetzt mit einem Fehler abgelehnt, und Menüs, in denen schon fehlerhafte Daten stecken, bleiben bearbeitbar (#4255).

Kleine Korrekturen im Admin

Das Titel-Trennzeichen zwischen Seitentitel und Site-Name unter Einstellungen → SEO lässt sich jetzt löschen und ersetzen. Der Standard steht als Hinweis im leeren Feld (#4241).
Screenreader lesen in den Dialogen von Plugin-Blöcken jetzt die Feldnamen vor (#4197), und bei Bestätigungsfenstern aus Plugins klebt der Text nicht mehr am Rand (#4219).
Die Anmeldeseite bittet nicht mehr bei jeder Anmeldeart um ein „Handle“, sondern nur noch dort, wo es eins gibt (#4013).
Bilder mit verschwommener Vorschau beim Laden behalten jetzt den Fokuspunkt, den du gesetzt hast (#4170).
Betreibst du deine Site auf einem eigenen Server mit Node.js und liegen deine Medien in R2 oder einem anderen S3-kompatiblen Speicher, brechen Vorschauen und Downloads nach wiederholten Anfragen nicht mehr mit Zeitüberschreitung ab (#4043).
Formular-Plugin: Felder, die nur unter einer Bedingung erscheinen sollen, bleiben versteckt, bis sie erfüllt ist (#4249). Eine einzelne Checkbox steht jetzt neben ihrem Label, statt sich über das ganze Formular zu ziehen (#4247), und ein angehaktes Kästchen wird auch als angehakt gespeichert (#4248).

Die Kommandozeile hinter Cloudflare Access

Zwei Korrekturen für Probleme, die ich im Artikel über API, CLI und MCP beschrieben habe:

emdash login und emdash logout gehen jetzt wie alle anderen Befehle zur Site in EMDASH_URL. Bisher haben sie es ohne --url immer bei http://localhost:4321 versucht (#4180).
Musste die Anmeldung von emdash login erneuert werden, scheiterte hinter Cloudflare Access jeder Befehl: Die Anfrage zum Erneuern ging ohne die zusätzlichen Header raus, die Access verlangt. Jetzt schickt sie sie mit, wie jede andere Anfrage (#4239).

Der Admin in mehr Sprachen

Russisch ist neu und in der Sprachauswahl wählbar (#3556). Japanisch (#4222, #4230, #4257), Indonesisch (#4142, #4211) und Hindi (#4104) sind vollständiger, und Indonesisch deckt schon den neuen Versionsverlauf und den Schalter gegen KI-Training aus 1.3 ab. Italienisch hat jetzt eine übersetzte Navigation, ist aber noch nicht wählbar (#4264). Danke an alle, die EmDash übersetzen.

Für Entwickler

Baust du Templates, Plugins oder Skripte, sind diese Punkte für dich:

Bildunterschriften: Lies caption direkt am Wert des Bildfelds. Es steht jetzt auch in den erzeugten Typen, und das ältere meta.caption bleibt dort, wo es existiert, synchron (#4201).
Fehler nicht mehr verdeckt: Warf eine Route einen Fehler, führte die Middleware für Weiterleitungen sie ein zweites Mal aus und verdeckte so den ursprünglichen Fehler. Jetzt kommt er bei Astro an (#4161).
Sprachen mit Codes: Gibt deine Astro-Konfiguration einer Sprache einen Pfad und eigene Codes, etwa { path: "en", codes: ["en-US"] }, finden Abfragen mit Astro.currentLocale jetzt Einträge unter beiden Schreibweisen (#4224).
Eigene Felder während einer Migration: getEmDashCollection() lieferte nichts, wenn where oder orderBy ein eigenes Feld nutzte, solange die Migration 086_relations_structural noch ausstand (#4024).
Spaltengrenze auf D1: Stieß ein Inhaltstyp an die Spaltengrenze von D1, blieb ein neues Feld ohne Spalte im Schema stehen. Hast du eine Spalte freigemacht, legst du es jetzt ohne Fehler FIELD_EXISTS an (#4070).
<Image> aus emdash/ui akzeptiert bei astro check die Eigenschaft quality (#4221).
Wrangler ist für @emdash-cms/cloudflare jetzt optional und nur noch nötig, wenn du sandbox() nutzt (#4234).
EmDashClient aus emdash/client führt deine interceptors jetzt auch beim automatischen Erneuern des Tokens aus (#4239).
Dashboard-API: userCount in GET /_emdash/api/dashboard bekommen jetzt nur noch Administratoren (#4181).

Vor dem Update: Was du prüfst

1.3.1 ändert nichts am Aufbau deiner Datenbank, und die meisten Korrekturen brauchen nichts von dir. Schau dir vorher kurz diese Punkte an. Die meisten betreffen dich nur, wenn du Templates oder Skripte baust:

Du kommst von 0.38 oder älter: Auf Workers führst du vor dem Deployment emdash migrate aus. Sonst zeigt deine Site eine 503, bis die Datenbank auf dem neuen Stand ist (#4069).
Links in neuen Tabs: Neue Textlinks öffnen im selben Tab, alte weiter in einem neuen. Setzt dein Template target="_blank" selbst, ändert sich für dich nichts (#4106).
Bildunterschriften: Lies in deinen Templates caption. Vor dem Update verlorene Bildunterschriften kommen nicht von selbst zurück (#4201).
KI-Agenten über MCP: Für Benutzer, die keine Entwürfe lesen dürfen, liefert content_get jetzt die veröffentlichte Fassung. Meldet sich ein Agent als so ein Benutzer an und braucht Entwürfe, gib ihm eine Rolle, die sie lesen darf (#4179).
Skripte, die Menüs bearbeiten: Ein ungültiger übergeordneter Eintrag führt jetzt zu einem Fehler, statt gespeichert zu werden (#4255).
Sprachen mit Codes: Einträge, die unter dem Pfad und unter einem Code gespeichert sind, bleiben getrennt. EmDash führt nichts zusammen und löscht nichts, Listen können also beide zeigen (#4224).
Anmeldung über AT Protocol: Diese Anmeldeart braucht jetzt @lingui/react (Lingui 5). Installiert dein Paketmanager das nicht von selbst, füg es selbst hinzu (#4013).

So aktualisierst du auf EmDash 1.3.1

Wie immer ist ein Update ein Deployment: Du installierst die neue Version und stellst deine Site neu online. Deine Inhalte bleiben, wo sie sind, in der Datenbank. Am einfachsten geht das mit upgrade-emdash:

npx upgrade-emdash@latest
npm run deploy

Ich habe das an einer Kopie von The Weekly Dash ausprobiert. Ein Probelauf mit --dry-run zeigte zwei Pakete, die von 1.3.0 auf 1.3.1 gehen, mit 25 Changelog-Einträgen. Das echte Update brauchte 15 Sekunden, keine Änderung an der Datenbank, frischte die Skills für KI-Agenten in .agents/skills auf, und die Site ließ sich danach ohne Fehler bauen. The Weekly Dash selbst ist noch am selben Abend auf 1.3.1 umgestiegen, die Seite, die du gerade liest, läuft also schon damit.

Lieber von Hand? Auf einer Site aus der Cloudflare-Vorlage sind es zwei Befehle:

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

Halte beide Pakete auf derselben Version, sonst warnt dich der Build. Willst du vorher einen Wiederherstellungspunkt setzen und einen Weg zurück haben, falls etwas schiefgeht, zeigt dir EmDash aktualisieren Schritt für Schritt, wie das geht.

Und bei dir?

Hat dich einer dieser Fehler erwischt, oder klappt nach 1.3.1 noch etwas nicht? Schreib es unten in die Kommentare. Kevin und ich sind beide Maintainer bei EmDash, und wir lesen die Kommentare: Was du uns hier erzählst, fließt direkt zurück ins Projekt.