Seminar Squidex – Kompaktseminar: Headless CMS für Redaktion und Entwicklung

Das Kompaktseminar vermittelt in drei Tagen ein gemeinsames, durchgängiges Arbeitsmodell für Squidex. Redaktionelle, administrative und technische Perspektiven werden so verbunden, dass ein Projektteam einen Pilotinhalt selbst modellieren, pflegen, ausliefern und betreiben kann.

Die Breite steht bewusst vor Spezialtiefe. Alle Übungen folgen derselben Beispiel-App: vom App- und Schemaentwurf über Mehrsprachigkeit, Workflow und Assets bis zur API-Abfrage, Frontenddarstellung und grundlegenden Betriebsplanung.

Zielgruppe

Interdisziplinäre Projektteams aus Redaktion, Product Ownership, Entwicklung, Administration und technischer Projektleitung

Voraussetzungen

Allgemeine Web- und CMS-Kenntnisse; für Entwicklungsübungen sind Grundkenntnisse in HTTP, JSON und JavaScript hilfreich

Seminarziele

• Zentrale Squidex-Begriffe und Verantwortlichkeiten teamübergreifend verstehen.
• Ein mehrsprachiges Content-Modell mit Komponenten und Referenzen erstellen.
• Inhalte, Workflows und Assets redaktionell pflegen und veröffentlichen.
• API-Zugriff und eine einfache Frontend-Ausgabe nachvollziehbar umsetzen.
• Rollen, Hosting, Backup, Sicherheit und nächste Vertiefungsschritte einordnen.

Inhaltsübersicht

1. Zielgruppe und Voraussetzungen
2. Seminarziele
3. Tag 1: Architektur, Apps und Content-Modell
4. Tag 2: Redaktion, Workflow, Assets und Governance
5. Tag 3: API, Frontend, Automatisierung und Betrieb
6. Praxisprojekt und Abnahme

1. Tag 1: Architektur, Apps und Content-Modell

Dieser Themenblock verbindet fachliche Entscheidung, konkrete Konfiguration und überprüfbare Abnahme. Die Schritte werden an einer durchgängigen Beispiel-App umgesetzt und mit geeigneten Positiv- und Negativfällen kontrolliert.

Schrittweises Vorgehen

1. Headless-Architektur und Rollen entlang einer Benutzerreise einordnen.
2. Team und App für den Pilotfall strukturieren.
3. Schema mit geeigneten Feldtypen und Validierungen anlegen.
4. Komponente und Content-Referenz modellieren.
5. Lokalisierbare Felder und zwei Sprachen konfigurieren.
6. Modell mit Beispielinhalten und API-Ausgabe prüfen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

2. Tag 2: Redaktion, Workflow, Assets und Governance

Der Abschnitt wird als vollständiger Arbeitsablauf bearbeitet: Ausgangslage erfassen, Zielzustand festlegen, Konfiguration umsetzen, Verhalten testen und die betriebliche beziehungsweise redaktionelle Übergabe dokumentieren.

Schrittweises Vorgehen

1. Inhalte erstellen, bearbeiten und zwischen Sprachen vergleichen.
2. Status und Übergänge für einen einfachen Freigabeprozess festlegen.
3. Vorschau, Veröffentlichung, Rückzug und Korrektur durchspielen.
4. Assets hochladen, taggen, mit Metadaten versehen und referenzieren.
5. Rollen und Berechtigungen für Redaktion und Administration zuordnen.
6. Redaktionelle Qualitätscheckliste und Governance-Regeln dokumentieren.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

3. Tag 3: API, Frontend, Automatisierung und Betrieb

Die Inhalte werden nicht isoliert demonstriert. Jede Entscheidung wird anhand von Auswirkungen auf Redaktion, API, Sicherheit, Betrieb und spätere Änderungen bewertet und anschließend praktisch validiert.

Schrittweises Vorgehen

1. Technischen API-Client mit minimalen Rechten anlegen.
2. Inhalte per REST und einer GraphQL-Abfrage abrufen.
3. Lokalisierte Inhalte und Assets in einer kleinen Webansicht ausgeben.
4. Veröffentlichungsereignis über Regel beziehungsweise Webhook weitergeben.
5. Cloud- und Self-Hosting-Verantwortung, Monitoring und Backup einordnen.
6. Pilot-Backlog, Risiken und passende Vertiefungsseminare festlegen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

Praxisprojekt und Abnahme

Ein interdisziplinäres Team baut eine kleine mehrsprachige Content-Lösung vom Schema über Redaktion und Asset-Pflege bis zur API- und Frontend-Ausgabe.

Arbeitsschritte

1. Pilotfall, Rollen und App-Struktur festlegen.
2. Content-Modell und Sprachen konfigurieren.
3. Redaktion, Workflow und Asset-Bibliothek praktisch nutzen.
4. API-Client und einfache Frontend-Ausgabe umsetzen.
5. Betriebs- und Vertiefungsplan als Projektübergabe erstellen.

Abnahmekriterien

• Der fachliche Anwendungsfall ist mit repräsentativen Daten vollständig durchgespielt.
• Fehler-, Berechtigungs- und Wiederanlaufszenarien sind kontrolliert geprüft.
• Konfiguration, Tests und Verantwortlichkeiten sind so dokumentiert, dass der Transfer in eine eigene Umgebung möglich ist.