EmDash-Admin im Alltag: Was schnell geht und was du vorher entscheiden solltest

Deine EmDash-Site läuft, so wie in Kevins Einstiegsartikel beschrieben, und jetzt öffnest du den Adminbereich unter /_emdash/admin. Was tust du hier im Alltag eigentlich, und wo kannst du dir etwas verbauen, das sich später nicht mehr geradebiegen lässt?

Die erste Frage ist schnell beantwortet. Inhalte anlegen, Bilder einbinden, Autoren und Rubriken pflegen, das lernst du an einem Nachmittag. Spannender finde ich die zweite. Ein paar Entscheidungen am Inhaltsmodell bleiben, und die markiere ich dir unterwegs, damit du sie vor dem ersten Beitrag triffst.

Die offizielle Dokumentation unter docs.emdashcms.com erklärt jede Funktion, allerdings nur auf Englisch, und ich erzähle sie hier nicht nach. Ich zeige dir den deutschen Adminbereich aus Sicht einer Redakteurin und die Stellen, an denen wir beim Bau von theweeklydash.com hängen geblieben sind. Geprüft habe ich alles mit EmDash 1.1.0, die Screenshots stammen aus einer lokalen Kopie dieser Site.

Collections, Felder und Einträge

Drei Begriffe tragen das ganze Modell. Eine Collection ist eine Art von Inhalt, etwa Posts oder Pages. Ein Feld ist eine einzelne Angabe darin, zum Beispiel der Titel oder das Beitragsbild. Und ein Eintrag ist ein einzelner gespeicherter Inhalt. Der deutsche Adminbereich nennt Collections „Sammlungen“ und verwaltet sie unter Inhaltstypen. Die wichtigsten Begriffe im Vergleich:

Vielleicht wunderst du dich, dass im deutschen Adminbereich unter „Inhalt“ bei uns „Pages“ und „Posts“ stehen statt „Seiten“ und „Beiträge“. Die Bezeichnungen von Collections und Feldern sind Daten und gehören nicht zur Oberfläche. Jede hat genau eine Bezeichnung, egal in welcher Sprache der Adminbereich läuft. Unser Seed hat die Labels des Templates übernommen, deshalb steht im deutschen Adminbereich „Title“ und „Excerpt“. Im englischen steht umgekehrt „Cover-Zeile“, weil wir genau dieses eine Feld deutsch benannt haben. Entscheide dich also früh für die Sprache deiner Redaktion und benenne alles darin.

Das Schema lebt in der Datenbank

Bezeichnungen kannst du jederzeit ändern. Beim Rest des Modells hilft es zu wissen, wo er liegt. Wenn du dir aus diesem Artikel nur eine Sache merkst, dann die Überschrift dieses Abschnitts. EmDash speichert Collections, Felder und Taxonomien in derselben Datenbank wie die Inhalte. Die Datei seed/seed.json beschreibt nur den Startzustand und wird genau einmal angewendet, auf eine leere Datenbank und bevor der Einrichtungsassistent durchgelaufen ist. Änderst du danach seed.json und deployst, passiert an der laufenden Site gar nichts. So steht es auch in der Doku zur Schema-Evolution.

Ein neues Feld für die Live-Site legst du deshalb unter Inhaltstypen mit Feld hinzufügen an. Wir halten uns dabei an eine feste Reihenfolge:

• Wenn etwas dazukommt, legen wir zuerst das Feld im Adminbereich an und mergen danach den Code, der es liest. Code, der ein fehlendes Feld liest, bekommt schlicht nichts zurück.
• Wenn etwas wegfällt, mergen wir erst den Code, der das Feld nicht mehr benutzt, und löschen dann das Feld.

Im selben Pull Request ziehen wir seed.json nach. Sonst startet jede neue Datenbank, etwa eine lokale oder eine Vorschau-Umgebung, mit dem alten Modell.

Jetzt zu den Entscheidungen, die bleiben. Sobald ein Feld existiert, stehen drei Dinge fest.

• Der Slug. Der Dialog „Feld bearbeiten“ sperrt ihn mit dem Hinweis „Feld-Slugs können nach dem Erstellen nicht mehr geändert werden“. Templates fragen den Slug ab, nicht die Bezeichnung, und die darfst du jederzeit ändern.
• Der Typ. Einen Typwechsel bietet der Adminbereich gar nicht an. Über die API kommst du nur zwischen Kurztext, Langtext und Slug hin und her, alles andere ist eine Datenmigration.
• Das Löschen. Ein gelöschtes Feld nimmt seine Spalte mit allen Werten mit. Mit dem Papierkorb für Einträge hat das nichts zu tun.

Unser Feld cover_line ist ein gutes Beispiel. Es ist ein Langtext, weil das Cover bis zu drei Zeilen zeigt. Hätten wir es als einzeiligen Kurztext angelegt, hätten wir es löschen und neu anlegen müssen.

Eine Lücke hat 1.1.0 noch. Ob ein Feld übersetzbar ist, kannst du im Adminbereich nicht einstellen, weil der Dialog dafür keinen Schalter hat. Standard ist „übersetzbar“, jede Sprache bekommt also ihren eigenen Wert. Soll ein Feld in allen Sprachen gleich sein, etwa eine Artikelnummer, legst du es über den Seed oder die API mit translatable: false an. Nachträglich umstellen ist laut Doku wieder eine Migration.

Vom Entwurf zum veröffentlichten Beitrag

So viel zum Modell. Die tägliche Arbeit im Editor ist deutlich entspannter.

Legst du einen neuen Eintrag an, zeigt die rechte Spalte erst einmal nur „URL & Sprache“. Als Entwurf legt EmDash den Eintrag erst beim ersten Speichern an, und danach tauchen Veröffentlichen, Eigentümer, Autorenangaben, Übersetzungen, Taxonomien, SEO und Revisionen auf. Suchst du also eine Rubrik und findest sie nicht, speichere einfach einmal.

Ab dann speichert der Editor zwei Sekunden nach deiner letzten Eingabe von selbst, und der Knopf wechselt dabei von „Wird gespeichert...“ zu „Gespeichert“. Klickst du selbst auf Speichern, setzt du einen festen Punkt in den Revisionen. Mit Wiederherstellen holst du eine ältere Revision zurück. Dabei entsteht eine neue Revision und die alten bleiben erhalten, hier kannst du also wenig kaputt machen.

Gespeichert heißt aber noch nicht öffentlich. Erst Jetzt veröffentlichen macht einen Entwurf sichtbar. Ist ein Beitrag schon veröffentlicht, landet jede Änderung zuerst in einem Entwurf, und deine Leser sehen die alte Fassung, bis du Änderungen veröffentlichen wählst. Den Entwurf prüfst du mit Vorschau, die öffentliche Fassung mit Live-Ansicht. Das gilt auch für den Slug, die URL ändert sich erst beim Veröffentlichen.

Planen öffnet einen Kalender mit Uhrzeit und zeigt dir die Zeitzone an, bei uns „Europe/Berlin (MESZ)“. Auf Cloudflare veröffentlicht ein Cron Trigger die geplanten Beiträge. Bei uns läuft er mit */5 * * * *, ein Beitrag für 9:00 Uhr erscheint also bis 9:05 Uhr. Was wann erscheint, siehst du im Kalender in der Seitenleiste.

Arbeiten zwei Leute am selben Beitrag, sperrt EmDash ihn für die zweite Person. Sie kann Schreibgeschützt öffnen oder Übernehmen. Die Sperre gilt pro Sprache, an der englischen Fassung kann also gleichzeitig jemand anderes arbeiten.

Eine Regel haben wir uns selbst auferlegt. Inhalte ändern wir nur im Adminbereich und nie per SQL auf der Live-Datenbank. SQL umgeht nämlich die Revisionen und, mit Edge-Caching, auch das Leeren des Caches. Der Beitrag bleibt dann veraltet im Cache stehen.

Bilder sind Objekte, keine URLs

Beim Text verzeiht EmDash also viel. Bei Bildern gibt es dagegen zwei Aktionen ohne Rückweg.

In der Medienbibliothek lädst du Dateien über Dateien hochladen hoch, bis zu 50 MB pro Datei. SVG lehnt EmDash standardmäßig ab, weil SVG-Dateien Skripte enthalten können. Formate, Ordner und Zuschneiden erklärt die Doku zur Medienbibliothek.

Ein Bildfeld speichert keine URL, sondern ein Objekt mit Media-ID, Abmessungen, Alt-Text und Speicherort. Beim Entwickeln behandelst du post.data.featured_image deshalb nie als String, sondern renderst es mit <Image image={...} /> aus emdash/ui und prüfst vorher auf image?.id.

Für die Redaktion hat das eine Folge, die ich lokal nachgestellt habe. EmDash kopiert den Alt-Text in den Eintrag, sobald du das Bild auswählst. Änderst du ihn danach in der Medienbibliothek, behält der Beitrag den alten Text, und ein eigenes Eingabefeld für den Alt-Text hat das Bildfeld nicht. Pflege den Alt-Text also, bevor du das Bild einbindest. Korrigierst du ihn später, wählst du das Bild im Beitrag einfach noch einmal aus.

Drei Knöpfe rund ums Bild klingen ähnlich, wirken aber verschieden. Ersetzen wählt für diesen einen Beitrag ein anderes Bild. Medienelement bearbeiten öffnet das Original in der Bibliothek, und was du dort änderst, kann jeden Beitrag treffen, der das Bild nutzt. Bild ersetzen in der Bibliothek tauscht die Datei hinter der Media-ID überall aus, und das lässt sich nicht rückgängig machen.

Im Auswahldialog heißt der Bestätigungsknopf in 1.1.0 „Einfachauswahl“. Das ist ein Übersetzungsfehler, gemeint ist „Auswählen“.

Die zweite Aktion ohne Rückweg ist das Löschen, also schau vorher unter Verwendet in nach. Es gibt keinen Papierkorb, und Verweise repariert EmDash auch nicht, ein Beitrag zeigt danach einfach ein kaputtes Bild. Allerdings ist die Liste nur so gut wie die Erfassung der Medienverwendung unter Einstellungen. In 1.1.0 ist sie von Haus aus aktiv: Unsere frische lokale Datenbank und die Live-Site melden sie beide als bereit. Den Schritt aus der Doku, sie einmal einzuschalten, brauchten wir deshalb nicht. Außerdem kennt sie nur Bild- und Dateifelder, Bilder und Galerien im Fließtext und die Website-Einstellungen Logo, Favicon und Standardbild für geteilte Links, aber keine eigenen Blöcke.

Übersetzungen: jede Sprache ein eigener Eintrag

Bis hierhin hätte eine Sprache gereicht. Bevor die zweite ins Spiel kommt, hier das Grundprinzip.

Jede Übersetzung ist ein eigener Eintrag mit eigenem Slug, eigenem Status und eigenen Revisionen. Zusammengehalten werden die Fassungen von einer Übersetzungsgruppe. Der deutsche Beitrag kann also schon veröffentlicht sein, während der englische noch Entwurf ist. Die Liste unter Posts zeigt immer nur eine Sprache, umschalten kannst du mit der Sprachauswahl neben der Überschrift.

Übersetzen in der Spalte „Übersetzungen“ legt die englische Fassung sofort als Entwurf an und kopiert alle Felder. In 1.1.0 wandert dabei auch der deutsche Slug mit, die englische URL lautet dann /en/emdash-admin-alltag, bis du den Slug änderst. Erledige das, bevor du veröffentlichst.

Menüs funktionieren genauso. Unsere Hauptnavigation gibt es auf Deutsch und Englisch, jeweils mit eigenen Links, und eine Übersetzung legst du unter Menüs an. Die Widget-Bereiche Sidebar und Footer gibt es bei uns auch, sie sind aber leer.

Autorenangaben und Rubriken funktionieren nach demselben Prinzip, und genau dort wird es knifflig.

Autorenangaben sind keine Benutzer

Wer einen Beitrag angelegt hat, steht unter Eigentümer. Wer darüber als Autor erscheint, steht unter Autorenangaben, auf Englisch Bylines. Eine Autorenangabe ist ein öffentliches Profil mit Name, Slug, Kurzbiografie, Avatar und Website. Sie kann zu einem Benutzerkonto gehören, muss aber nicht, Gastautoren brauchen also kein Konto.

Ordne dein eigenes Profil deinem Konto zu („Zugeordneter Benutzer“). Ohne diese Zuordnung hat ein neuer Beitrag keine Autorenangabe, bis du eine auswählst. Mit Zuordnung nimmt EmDash das Profil des Eigentümers, wenn keins ausgewählt ist.

Mit zwei Sprachen wird es heikel. Autorenangaben gibt es pro Sprache, verbunden über eine gemeinsame Übersetzungsgruppe, und ein Konto kann pro Sprache genau ein Profil haben. EmDash 1.1.0 sucht die Autorenangabe streng in der Sprache des Beitrags und fällt nicht auf die Standardsprache zurück. Fehlt die englische Fassung deines Profils, erscheint dein englischer Beitrag ohne Autor. Leg sie deshalb im Dialog „Autorenangabe bearbeiten“ unter Übersetzungen an. Ein Seed kann keine Übersetzungen von Autorenangaben anlegen, darum gibt es in unserem Repository pnpm run demo:bylines, das die englischen Profile in die lokale Datenbank schreibt.

Die Profil-Links unter unseren Artikeln, etwa Bluesky und GitHub, sind eigene Felder unter Autorenangaben-Schema. Die haben wir als nicht übersetzbar angelegt, damit ein Link in beiden Sprachen gilt. Auch diese Felder kann ein Seed nicht anlegen.

Und noch eine Falle, falls du Autorenangaben per Skript pflegst. PUT /_emdash/api/admin/bylines/:id ersetzt das ganze Profil. Lässt du Kurzbiografie, Avatar, Website oder Benutzer weg, setzt EmDash sie auf leer. Ich habe das lokal mit einem PUT nur aus Name und Slug nachgestellt, danach war die Biografie weg. Eigene Felder bleiben dagegen stehen, wenn du sie weglässt. Lies das Profil also immer erst und schreib es dann vollständig zurück.

Rubriken und Themen

Bei Rubriken sitzt die eigentliche Falle nicht in der Sprache, sondern im Slug.

EmDash bringt zwei Taxonomien mit, das hierarchische category und das flache tag. Wir nutzen beide und haben nur die Bezeichnungen geändert. Kategorien heißen bei uns Rubriken (Einstieg, Anleitungen, Hintergrund, Changelog), Schlagwörter heißen Themen (Astro, Cloudflare, Performance, Plugins, WordPress). Mit diesen Namen stehen sie auch direkt in der Seitenleiste.

Der Name category steht im Code und bleibt, die Bezeichnungen kannst du jederzeit ändern. Bei den Slugs sieht es anders aus. Jede Rubrik hat bei uns eine Farbe und ein Zeichen, Mint und » für Einstieg, Gelb und einen Geviertstrich für Anleitungen, Pink und ¶ für Hintergrund, Violett und die Versionsnummer für Changelog. In EmDash ist beides keine Eigenschaft des Begriffs. Es hängt in unserem Code am deutschen Slug, und die englischen Slugs wie guides werden auf die deutschen abgebildet. Dazu verlinkt die Hauptnavigation /rubrik/anleitungen als feste URL. Änderst du den Slug einer Rubrik im Adminbereich, sind Farbe, Menülink und alte URLs auf einen Schlag weg.

Wie viel an einer Rubrik hängt, haben wir kurz vor dem Start gesehen, als aus der Rubrik Plugins ein Thema wurde. Dafür brauchte es einen Pull Request mit Umleitungen von /rubrik/plugins auf /thema/plugins, neue Menüeinträge in beiden Sprachen und für jeden betroffenen Artikel eine neue Zuordnung. Deshalb legen wir Rubrik-Slugs einmal fest und fassen sie danach nicht mehr an.

Begriffe gibt es pro Sprache, verbunden wie Beiträge. Die Zuordnung zum Beitrag teilen sich aber alle Fassungen. Ordnest du den deutschen Beitrag „Anleitungen“ zu, zeigt die englische Fassung von selbst „Guides“. Du übersetzt also jeden Begriff einmal und nicht jeden Beitrag.

Bei Themen rate ich zu wenigen, die du wirklich mehrfach vergibst. Eine Themenseite mit weniger als zwei Beiträgen bekommt bei uns noindex und fehlt in der Sitemap, zwanzig Themen mit je einem Beitrag sind also zwanzig dünne Seiten. Für Nachzügler gibt es auf der Taxonomieseite Zu Beiträgen hinzufügen. Dort fügst du bis zu 50 Beitrags-URLs ein und hängst den Begriff an alle auf einmal. Löschst du einen Begriff, verschwindet er aus allen Beiträgen, die Beiträge selbst bleiben.

Ein Namenskonflikt ist uns erst im englischen Adminbereich aufgefallen. Dort heißen unsere Rubriken „Sections“. EmDash hat aber schon einen eigenen Menüpunkt „Sections“ für wiederverwendbare Inhaltsblöcke, auf Deutsch „Abschnitte“. In der englischen Seitenleiste stehen jetzt also zwei Einträge „Sections“ untereinander. Prüf neue Bezeichnungen deshalb in beiden Sprachen.

Fazit

Zurück zu den beiden Fragen vom Anfang. Den Alltag im Adminbereich lernt eine Redakteurin an einem Nachmittag, denn Speichern, Vorschau, Planen und Übersetzen funktionieren so, wie du es erwartest. Die eigentliche Arbeit liegt davor. Benenne alles in der Sprache deiner Redaktion, wähle Feld-Slugs und Feldtypen, die zum Inhalt passen, und leg Rubrik-Slugs so fest, dass du sie nie wieder anfassen musst. Mit zwei Sprachen kommt hinzu, dass jede Autorenangabe ihre Übersetzung braucht, sonst fehlt der Autor. Und wenn du auf der Live-Site etwas am Schema änderst, tust du das im Adminbereich und nicht im Seed.