Seminar Magnolia CMS – Kompaktseminar Content, Entwicklung und Betrieb

Das dreitägige Kompaktformat vermittelt einen zusammenhängenden Überblick über Architektur, Redaktion, Content-Modelle, Templates, Headless-Ausgabe, Integration, Administration, Sicherheit und Betrieb. 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. Tag 1: Architektur, Redaktion und Inhalte
2. Tag 2: Templates, Headless und Integration
3. Tag 3: Administration, Sicherheit und Betrieb
4. Zielgruppe und Voraussetzungen
5. Didaktik und Arbeitsweise

Tag 1: Architektur, Redaktion und Inhalte

Inhaltsverzeichnis

• Author-Public-Modell und Content-Lifecycle
• Pages, Komponenten, Assets und Publishing
• Content Types, Content Apps und Governance
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Author-Public-Modell und Content-Lifecycle, Pages, Komponenten, Assets und Publishing und Content Types, Content Apps und Governance 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: Author-Public-Modell und Content-Lifecycle 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 Pages, Komponenten, Assets und Publishing 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: Content Types, Content Apps und Governance werden schrittweise konfiguriert oder implementiert. Ein Inhaltsfall wird von der Modellierung über die Bearbeitung bis zur Veröffentlichung aufgebaut. 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: Gemeinsames Content-Zielbild mit Rollen und Qualitätsregeln.

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

Tag 2: Templates, Headless und Integration

Inhaltsverzeichnis

• Light Modules, YAML und FreeMarker
• Delivery API, Referenzen und externe Frontends
• REST-Client, Datenmapping und Fehlerpfade
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Light Modules, YAML und FreeMarker, Delivery API, Referenzen und externe Frontends und REST-Client, Datenmapping und Fehlerpfade 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: Light Modules, YAML und FreeMarker 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 Delivery API, Referenzen und externe Frontends 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: REST-Client, Datenmapping und Fehlerpfade werden schrittweise konfiguriert oder implementiert. Ein Inhalt wird klassisch und per API ausgegeben und mit einem Drittsystem verbunden. 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: Technischer Prototyp mit Template- und API-Vertrag.

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

Tag 3: Administration, Sicherheit und Betrieb

Inhaltsverzeichnis

• Benutzer, Rollen und ACLs
• Härtung, Backup und Monitoring
• Deployment, Störung und Upgradeplanung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Benutzer, Rollen und ACLs, Härtung, Backup und Monitoring und Deployment, Störung und Upgradeplanung 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: Benutzer, Rollen und ACLs 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 Härtung, Backup und Monitoring 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: Deployment, Störung und Upgradeplanung werden schrittweise konfiguriert oder implementiert. Die Referenzumgebung wird abgesichert, überwacht, gesichert und in einem kontrollierten Störungsfall 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: Betriebsbaseline mit Rechte-, Sicherungs- und Releasecheckliste.

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: Einführungsteams, technische Projektleitung, Product Owner, Architektur, Lead-Redaktion, Entwicklung und Betrieb mit bereichsübergreifender Verantwortung.

Voraussetzungen: Allgemeines Verständnis von Webplattformen und digitalen Prozessen; technische Übungen setzen grundlegende YAML-, HTTP- und Systemkenntnisse voraus.

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.