Seminar Magnolia CMS – Headless, Delivery API und externe Frontends

Das Seminar entwickelt eine tragfähige Headless- oder Hybridarchitektur mit Content-Modell, Delivery API, Referenzen, Assets, Lokalisierung, Frontend-Integration, Sicherheit und Cache-Strategie. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Headless-Zielbild und Content-Vertrag
2. Delivery-Endpunkte konfigurieren
3. Referenzen, Assets und zusammengesetzte Antworten
4. Frontend-Integration und redaktionelle Vorschau
5. Sicherheit, Cache und Betrieb
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Headless-Zielbild und Content-Vertrag

Inhaltsverzeichnis

• Kanäle, Frontends und Redaktionsanforderungen
• strukturierte Inhalte und Seiteninhalt
• API-Vertrag, Versionierung und Verantwortungen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Kanäle, Frontends und Redaktionsanforderungen, strukturierte Inhalte und Seiteninhalt und API-Vertrag, Versionierung und Verantwortungen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Kanäle, Frontends und Redaktionsanforderungen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für strukturierte Inhalte und Seiteninhalt wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: API-Vertrag, Versionierung und Verantwortungen werden schrittweise konfiguriert oder implementiert. Ein Kanalportfolio wird in Content-Modelle und eindeutig versionierte API-Verträge übersetzt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Headless-Architektur mit Content- und API-Verträgen.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Delivery-Endpunkte konfigurieren

Inhaltsverzeichnis

• Workspace, Root-Pfad und erlaubte Properties
• Filter, Sortierung, Pagination und Tiefe
• lokalisierte Inhalte und Ausgabeformate
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Workspace, Root-Pfad und erlaubte Properties, Filter, Sortierung, Pagination und Tiefe und lokalisierte Inhalte und Ausgabeformate zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Workspace, Root-Pfad und erlaubte Properties werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Filter, Sortierung, Pagination und Tiefe wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: lokalisierte Inhalte und Ausgabeformate werden schrittweise konfiguriert oder implementiert. Ein Delivery-Endpunkt wird minimal freigegeben und mit realistischen Abfragen geprüft. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Endpunktdefinition mit Abnahmeabfragen.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Referenzen, Assets und zusammengesetzte Antworten

Inhaltsverzeichnis

• JCR- und Content-App-Referenzen
• Asset-Links, Metadaten und Renditions
• Rich-Text-Verweise und Antwortgröße
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet JCR- und Content-App-Referenzen, Asset-Links, Metadaten und Renditions und Rich-Text-Verweise und Antwortgröße zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: JCR- und Content-App-Referenzen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Asset-Links, Metadaten und Renditions wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Rich-Text-Verweise und Antwortgröße werden schrittweise konfiguriert oder implementiert. Mehrere referenzierte Inhalte werden in einer kontrollierten Antwort aufgelöst. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Referenz- und Payload-Konzept mit Größenlimits.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Frontend-Integration und redaktionelle Vorschau

Inhaltsverzeichnis

• Datenmapping und Komponentenregistry
• SPA- und Template-Definitionen
• Fehlerzustände, Preview und Authoring-Kontext
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Datenmapping und Komponentenregistry, SPA- und Template-Definitionen und Fehlerzustände, Preview und Authoring-Kontext zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Datenmapping und Komponentenregistry werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für SPA- und Template-Definitionen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Fehlerzustände, Preview und Authoring-Kontext werden schrittweise konfiguriert oder implementiert. Ein externes Frontend rendert Inhalte und wird für redaktionelle Vorschau vorbereitet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Frontend-Integrationsmuster mit Fehler- und Preview-Fluss.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Sicherheit, Cache und Betrieb

Inhaltsverzeichnis

• REST-Rollen und Pfadfreigaben
• CORS, Authentisierung und Eingabegrenzen
• Cache, Invalidierung, Monitoring und Vertragsfehler
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet REST-Rollen und Pfadfreigaben, CORS, Authentisierung und Eingabegrenzen und Cache, Invalidierung, Monitoring und Vertragsfehler zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: REST-Rollen und Pfadfreigaben werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für CORS, Authentisierung und Eingabegrenzen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Cache, Invalidierung, Monitoring und Vertragsfehler werden schrittweise konfiguriert oder implementiert. Ein Endpunkt wird gehärtet, zwischengespeichert und gegen unzulässige Anfragen getestet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Betriebsstandard für sichere Content-Auslieferung.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: Frontend- und Full-Stack-Entwicklung, Lösungsarchitektur, API Engineering, Magnolia-Entwicklung, Integration und technische Projektleitung.

Voraussetzungen: Magnolia-Grundkenntnisse, sichere JSON- und HTTP-Kenntnisse sowie Erfahrung mit einem modernen Frontend-Framework oder serverseitigem Web-Frontend.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.