Seminar Magnolia CMS – Architektur und Plattformgrundlagen

Das Seminar schafft ein belastbares Gesamtbild der Magnolia-Architektur, der Inhaltsmodelle, der Author-Public-Topologie und der möglichen Ausgabekanäle. 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. Plattformaufbau und Laufzeitmodell
2. Inhalte, Apps und Veröffentlichung
3. Rendering und Headless-Ausgabe
4. Projekt- und Betriebsentscheidungen
5. Zielgruppe und Voraussetzungen
6. Didaktik und Arbeitsweise

Plattformaufbau und Laufzeitmodell

Inhaltsverzeichnis

• Author- und Public-Instanzen
• Module, Konfiguration und Ressourcen
• JCR-Repositories und Workspaces
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Author- und Public-Instanzen, Module, Konfiguration und Ressourcen und JCR-Repositories und Workspaces 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- und Public-Instanzen 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 Module, Konfiguration und Ressourcen 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: JCR-Repositories und Workspaces werden schrittweise konfiguriert oder implementiert. Eine Referenzarchitektur wird aus Komponenten, Datenflüssen und Verantwortungsgrenzen 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: Architekturübersicht mit Komponenten und Datenflüssen.

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

Inhalte, Apps und Veröffentlichung

Inhaltsverzeichnis

• Seiten, Komponenten und Bereiche
• strukturierte Inhalte in Content Apps
• Assets, Versionen und Publishing
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Seiten, Komponenten und Bereiche, strukturierte Inhalte in Content Apps und Assets, Versionen und Publishing 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: Seiten, Komponenten und Bereiche 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 in Content Apps 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: Assets, Versionen und Publishing werden schrittweise konfiguriert oder implementiert. Ein Inhalt wird vom Modell über die Bearbeitung bis zur Veröffentlichung nachvollzogen. 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: Content-Lifecycle-Skizze mit Zuständen und Rollen.

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

Rendering und Headless-Ausgabe

Inhaltsverzeichnis

• FreeMarker-basiertes Rendering
• Delivery API und externe Frontends
• Caching, Vorschau und redaktionelle Kontrolle
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet FreeMarker-basiertes Rendering, Delivery API und externe Frontends und Caching, Vorschau und redaktionelle Kontrolle 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: FreeMarker-basiertes Rendering 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 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: Caching, Vorschau und redaktionelle Kontrolle werden schrittweise konfiguriert oder implementiert. Zwei Delivery-Modelle werden anhand von Anforderungen und Betriebsfolgen verglichen. 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: Entscheidungsmatrix für klassisches, hybrides und Headless-Rendering.

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

Projekt- und Betriebsentscheidungen

Inhaltsverzeichnis

• Edition und Funktionsumfang
• Umgebungen und Deployment-Modell
• Rollen, Governance und Lernpfade
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Edition und Funktionsumfang, Umgebungen und Deployment-Modell und Rollen, Governance und Lernpfade 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: Edition und Funktionsumfang 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 Umgebungen und Deployment-Modell 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: Rollen, Governance und Lernpfade werden schrittweise konfiguriert oder implementiert. Ein kompaktes Zielbild für ein Beispielvorhaben wird bewertet und priorisiert. 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: Entscheidungsprotokoll für die weitere Vertiefung.

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: IT-Architektur, technische Projektleitung, Entwicklung, Betrieb, Product Owner, Beratung und erfahrene Key-User.

Voraussetzungen: Allgemeines Verständnis von Webanwendungen, Content-Management und HTTP; Magnolia-Vorkenntnisse sind nicht erforderlich.

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.