Migration zu Next.js / Astro in Hannover

Sie planen den Umzug auf Astro oder Next.js, und die Frage aus der Redaktion lautet: Wo schreibe ich künftig, und wie sehe ich vorher, wie die Seite aussieht? Genau daran scheitern Migrationen im Alltag, nicht am Frontend. Ich arbeite allein und schriftlich, aus Gdynia, und klare Antworten auf diese Fragen gehören bei mir in den Umfang, bevor eine Zeile Code entsteht.

#Wo liegen die Inhalte nach dem Umzug?

Astro und Next.js zeigen Inhalte an, sie verwalten keine. Die Astro-Dokumentation sagt es so: Das CMS hilft beim Schreiben, erzeugt aber keine Website, die den Inhalt anzeigt. Es gibt drei Wege, und die Wahl hängt an Ihrer Redaktion, nicht am Framework.

Git-basiert. Decap CMS nennt sich ein Open-Source-CMS für Ihren Git-Workflow. Es ist eine React-App, die für Redakteure Commits erzeugt, sodass sie weder Code noch Git anfassen müssen. Die Inhalte liegen laut Dokumentation als Dateien im Repository, die Felder als YAML-Kopf und darunter der Text. Keystatic speichert lokal, direkt in GitHub oder beides. Beide laufen mit Astro und Next.js, Keystatic hat dafür eigene Anleitungen.

API-basiert. Die Astro-Dokumentation unterscheidet zwei Arten: CMS mit eigener Astro-Integration, etwa Storyblok, und solche mit einem JavaScript-SDK, das Sie installieren und zum Abrufen nutzen. Hier laufen Konten, Rollen und Medienverwaltung beim Anbieter. Welche Auftragsverarbeitung und welche Serverregion dafür gelten, kläre ich vor dem Projekt schriftlich mit Ihnen.

WordPress headless. Astro holt Inhalte über die eingebaute REST-API unter [Ihre-Seite]/wp-json/wp/v2/, optional auch über WPGraphQL oder Gato GraphQL. Eigene Inhaltstypen müssen dafür in der REST-API freigegeben sein. Die Astro-Anleitung nennt die Schnittstelle standardmäßig als ohne Anmeldung abrufbar, Sie können aber eine Authentifizierung verlangen. Der Vorteil: Ihre Redaktion behält Oberfläche, Rollen und Gewohnheiten, auch die vorhandenen Beiträge müssen nicht in ein neues Format wandern.

Meine Empfehlung folgt der Redaktion. Zwei Personen, die selten schreiben, kommen mit einem Git-basierten CMS gut aus. Ein Team mit Terminplänen und Freigaben fährt mit WordPress headless oder einem API-CMS besser. Beides begründe ich Ihnen schriftlich.

Foto: Christian A. Schröder (ChristianSchd), CC BY-SA 4.0, Wikimedia Commons.

#Wie sieht die Redaktion Entwürfe, bevor sie live gehen?

Bei einer statisch gebauten Seite gibt es zunächst nur das Veröffentlichte. Eine Vorschau muss man deshalb bewusst einbauen.

Next.js Draft Mode. Laut Next.js-Dokumentation zeigt der Draft Mode Redakteuren Entwürfe, ohne auf die Revalidierung zu warten. Zwischengespeicherte oder vorab erzeugte Inhalte werden dabei umgangen, andere Besucher sehen weiter die gecachte Version. Ein Route Handler ruft draft.enable() auf und setzt das Cookie __prerender_bypass. Das CMS öffnet beim Klick auf Vorschau eine URL wie /api/draft?secret=...&slug=.... Die Dokumentation warnt, dass der Handler ohne Geheimnis öffentlich wäre: Jeder könnte den Modus für sich einschalten. Sie empfiehlt, den Slug im CMS zu prüfen und das Ziel aus dem abgerufenen Beitrag zu nehmen, nicht aus dem Parameter, um offene Weiterleitungen zu vermeiden. Liefert das CMS Entwürfe unter einer anderen Adresse, verzweige ich den Abruf anhand von isEnabled.

Astro. Einen eigenen Vorschaumodus beschreibt die Astro-Dokumentation nicht. Ich löse es mit dem, was dort beschrieben ist: On-Demand-Rendering erzeugt eine Seite pro Aufruf statt beim Build, nötig ist ein Adapter, und eine einzelne Route schalten Sie mit export const prerender = false um. Eine solche Vorschauroute liest den Entwurf aus dem CMS und ist durch ein Geheimnis geschützt. Das ist meine Umsetzung, keine Funktion von Astro, und ich sage es so, damit Sie wissen, was gebaut wird.

Bei Decap und Keystatic ohne Server gibt es keinen Entwurf im CMS-Sinn, sondern eine Datei auf einem Branch. Die Vorschau ist dann ein Build dieses Branches, den ich auf einer nicht öffentlichen Adresse bereitstelle.

#Wie kommt die Änderung auf die Live-Seite?

Nach der Freigabe muss die Website erfahren, dass sich etwas geändert hat. Bei Astro mit statischem Build startet die Veröffentlichung einen neuen Build, bei kleinen Seiten dauert das, bei großen plane ich es gezielt. Bei Next.js kann ein Webhook des CMS einen Route Handler aufrufen, der revalidateTag ausführt. Die Dokumentation beschreibt das als Stale-While-Revalidate: Die nächste Anfrage bekommt noch den alten Inhalt, im Hintergrund entsteht der neue. Ist ein Eintrag sofort zu entfernen, gibt es dafür { expire: 0 }. Die Revalidierung läuft beim Besuch der Seite an, nicht beim Aufruf selbst, deshalb erscheinen Änderungen nicht überall gleichzeitig.

Für Ihre Redaktion heißt das: Veröffentlichen ist nicht immer sofort sichtbar. Das lege ich vorher fest und schreibe es in die Anleitung.

#Rollen und Freigabe: Wer darf was?

WordPress. Die Rollen sind bekannt: Der Editor veröffentlicht und verwaltet auch Beiträge anderer, der Author nur eigene, der Contributor schreibt und verwaltet eigene Beiträge, kann sie aber nicht veröffentlichen. Die REST-API kennt die Status publish, future, draft, pending und private. Beim Auflisten gilt standardmäßig publish. Für Zugriffe von außen beschreibt die WordPress-Dokumentation Cookie-Authentifizierung mit Nonce und seit WordPress 5.6 Anwendungspasswörter über HTTPS. Für ein Frontend, das Entwürfe liest, braucht es also ein eigenes Konto mit passenden Rechten, kein offenes Konto.

Decap CMS. Standardmäßig committet es direkt auf den Hauptbranch. Mit publish_mode: editorial_workflow kommt ein Prüfschritt hinzu. Die Dokumentation deutet an, dass jeder Eintrag im Workflow einen eigenen Branch bekommt. Die genauen Status und den Ablauf der Prüfung zeige ich Ihnen im Projekt am konkreten Backend.

Keystatic. Im GitHub-Modus richtet sich die Anmeldung nach den Rechten im Repository, Mitarbeitende brauchen Schreibzugriff. Die Oberfläche zeigt eine Branch-Auswahl, und mit branchPrefix begrenzen Sie die sichtbaren Branches. Wer keine GitHub-Konten verteilen will, wählt besser einen anderen Weg.

#Was muss Ihre Redaktion lernen?

• Neue Anmeldung und neue Oberfläche. Der Wechsel vom Theme-Editor ins CMS ist klein, wenn WordPress bleibt, und größer bei Decap oder einem API-CMS.
• Vorschau ist ein eigener Schritt. Wer WordPress kennt, klickt auf Vorschau und erwartet das Theme. Künftig öffnet sich das neue Frontend.
• Verzögerung bis zur Veröffentlichung. Siehe oben: Ein Build oder eine Revalidierung liegt dazwischen.
• Inhalte in festen Feldern. Aus freien Layouts werden Felder. Das ist die Gegenseite der strukturierten Inhalte, die Suchmaschinen und Filter brauchen.
• Bilder und Dateien. Der Ort der Medien und die Regeln für Dateinamen und Alternativtexte ändern sich je nach Weg.
• Was die Redaktion nicht mehr tun muss. Plugin-Updates für das Frontend entfallen. Bleibt WordPress im Hintergrund, bleiben sie dort.

Für die Einweisung schreibe ich eine kurze Anleitung mit Bildschirmfotos aus Ihrer eigenen Installation und beantworte Rückfragen schriftlich.

#Was gilt dabei für eine Website aus Niedersachsen?

Ein externes API-CMS oder ein Vorschaudienst ist ein weiterer Empfänger von Redaktionsdaten, etwa Benutzernamen und E-Mail-Adressen Ihrer Redakteure. Für Unternehmen in Niedersachsen ist der Landesbeauftragte für den Datenschutz Niedersachsen zuständig. Auf lfd.niedersachsen.de hat er einen eigenen Bereich für die Wirtschaft. Vor der Wahl des CMS gehören diese Fragen auf den Tisch: Wer ist Auftragsverarbeiter, in welcher Region liegen die Daten, und steht der Dienst in Ihrem Verzeichnis der Verarbeitungstätigkeiten?

#Checkliste: Entscheidung vor dem Projekt

1. Wie viele Personen schreiben, und wie oft?
2. Braucht es eine zweite Person zur Freigabe?
3. Haben alle Beteiligten ein GitHub-Konto, oder wollen Sie das nicht?
4. Sollen Entwürfe vor Veröffentlichung im echten Layout erscheinen?
5. Wie schnell muss eine Korrektur sichtbar sein?
6. Welche Inhalte liegen schon in WordPress und sollen nicht umziehen?
7. Wer ist Auftragsverarbeiter für das CMS?

#Häufige Fragen

Kann meine Redaktion bei WordPress bleiben? Ja. WordPress läuft als Headless-Backend weiter, Astro oder Next.js holen die Inhalte über die REST-API. Oberfläche und Rollen bleiben, neu ist die Vorschau, die ich im Frontend einrichte.

Braucht jeder Redakteur ein GitHub-Konto? Bei Keystatic im GitHub-Modus ja, denn der Zugriff richtet sich nach den Rechten im Repository und verlangt Schreibzugriff. Bei Decap CMS übernimmt das CMS die Commits, welche Anmeldung dafür nötig ist, hängt vom gewählten Backend ab. Bei einem API-CMS gibt es eigene Konten.

Sieht der Redakteur Entwürfe, ohne dass Besucher sie sehen? Ja. Bei Next.js setzt der Draft Mode ein Cookie nur im Browser des Redakteurs. Andere Besucher bekommen weiter die zwischengespeicherte oder vorab erzeugte Seite.

Wann erscheint eine Änderung auf der Live-Seite? Das hängt vom Modell. Bei einer statischen Astro-Seite löst die Veröffentlichung einen neuen Build aus. Bei Next.js kann ein Webhook gezielt ein Cache-Tag ungültig machen, die Seite wird dann beim nächsten Aufruf neu erzeugt.

Wie funktioniert die Freigabe durch eine zweite Person? Bei Decap CMS über publish_mode: editorial_workflow, bei WordPress über die Rollen: Ein Contributor kann schreiben, aber nicht veröffentlichen. Bei Keystatic läuft die Prüfung über Branches im Repository.

Was kostet die Umstellung der Redaktion? Preise nenne ich hier nicht. Nach Ihrer Anfrage erhalten Sie von mir schriftlich einen Umfang mit den Schritten, die Ihre Redaktion betreffen.

#Wie starte ich mit Ihnen?

Schicken Sie mir die Adresse Ihrer Website, das aktuelle CMS, die Zahl der Redakteure, den gewünschten Zeitpunkt und eine kurze Beschreibung, wie bei Ihnen heute veröffentlicht wird. Die erste Einschätzung bekommen Sie schriftlich und ohne Rechnung. Der Weg dafür ist das Kontaktformular. Allgemein zum Ablauf einer Migration lesen Sie die Seite zur Migration zu Next.js und Astro, zur Wahl des Redaktionssystems die Seite zur Headless-CMS-Entwicklung. Wireframes und Gestaltung stellen Sie, die Umsetzung übernehme ich.