Ich habe in den vergangenen Jahren viel mit selbstgebauten CMS gearbeitet, habe unterschiedliche Migrationen und Weiterentwicklungen auf und innerhalb von WordPress redaktionell verantwortet und eng mit den Entwicklern bei Nutzerführung, Website-Struktur und Datenbanken zusammengearbeitet. Dazu habe ich mit meinem GitHub-Pages-Projekt eine Website komplett ohne CMS aufgebaut. Was mir aber fehlte, ist ein tieferer Einblick in andere CMS.
Warum GSB?
Ganz konkret fehlten mir Erfahrungen in TYPO3- und Headless-CMS-Technologien. Doch das bin ich jetzt angegangen. Und da ich mich schon länger für die öffentliche Verwaltung interessiere, habe ich mir beim ITZBund die Möglichkeiten von GSB11 angeschaut. Der Government Site Builder (GSB 11) ist das Content-Management-System des Bundes. Es wurde eigentlich entwickelt, “um moderne, barrierefreie und zukunftssichere Internetauftritte für Behörden zu ermöglichen.” Da es aber auf TYPO3 basiert, vollständig auf Open-Source-Technologien setzt und als Open Code auch bereitgestellt wird, schlage ich damit zwei Fliegen mit einer Klappe: TYPO3 und das neue Verwaltungs-CMS auf einmal zu lernen.
Dafür habe ich einige neue Dinge lernen müssen, bevor ich mit dem CMS starten konnte. Ich habe zum ersten Mal einen eigenen Server bei einem Hoster gemietet und ein CMS installiert. Beim Einrichten und beim Styling der Seite hat mir die KI in Form von Codex sehr geholfen und assistiert. Um die grundsätzliche Machbarkeit zu prüfen, habe ich mit der KI vorab eine lokale Testumgebung aufgesetzt, die auch nach der Serverinstallation für Test vor groberen Eingriffen ins Live-System herhalten muss. Die Testumgebung läuft auf einer externen SSD. Eine virtuelle Maschine, Ubuntu, eine Docker-Integration und darin das GSB11 sind dabei die Grundlagen.
Individuell und dennoch nah am Original
Ziel des Ganzen ist, möglichst nah an meinem Grunddesign meiner GitHub-Page zu bleiben und dennoch mit den GSB11-Grundelementen auszukommen, soweit es geht. Das ist schon bei recht einfachen Blöcken zum Teil nicht trivial. Dennoch läuft das GSB11-Projekt bisher ohne tiefgreifende Anpassungen stabil und mit einem annehmbaren optischen Ergebnis. Am GSB11-Core selbst wurde kein Quellcode verändert. Die Anpassungen liegen in der Konfiguration, im Sitepackage und zusätzlichen Extensions. Was ich anpassen musste (von Codex zusammengestellte Liste):
- Design: eigene CSS-Regeln, Schriften, Farben, Rasterhintergrund und auswählbare Containerfarben
- Markenauftritt: eigenes Logo/Porträt, Favicon und angepasster Backend-Anmeldebereich.
- Seitengerüst: eigene Vorlagen für Header, Footer und Navigation sowie Korrekturen der Menü-Darstellung
- Unterseiten-Teaser: zusätzliche Optionen für Anzahl und Sortierung nach Datum; eigenes Teaser-Datum in den Seiteneigenschaften. Dafür wurden die bestehenden Datenbanktabellen um Felder ergänzt
- Suche: TYPO3 Indexed Search installiert und konfiguriert
- Externe Einbettungen: offizielle Extension gsb_consent installiert und aktiviert
Noch in Bearbeitung aktuell:
- Artikelarchiv: eigene Extension mit Artikeldatensätzen, Auswahlbegriffen und Backend-Formularen; 626 Artikel importiert.
- RAG-Suche für Masterarbeit mit Anbindung an OpenAI-API vorbereitet
Mit den Anpassungen kann ich also gefühlt 90 Prozent meiner bestehenden GitHub-Seite nachbauen. Automatisierungen sind noch nicht angebunden und einige Darstellungen nicht übernommen, weil ich meinem Grundprinzip von möglichst wenig Anpassungen im CMS treu bleiben möchte.
Ich bin schneller als die KI
Was mir bei der Bedienung von TYPO3, beziehungsweise dem GSB11 auffällt: Schon nach wenigen Tagen mit dem CMS bin ich beim Einbau von Content schneller als Codex beim Einbauen des gleichen Contents in meine per Codex gepflegte GitHub-Pages-Seite. Dazu sind Änderungen und Anpassungen an der Seite in der Regel einfacher und ebenfalls schneller möglich. Verlinkungen, ein zusätzliches Bild oder ein Button: TYPO3 ist selbstverständlich einfacher zu bedienen, als eine hardcoded Seite immer wieder per Codex zu aktualisieren. Dafür gibt man jedoch Flexibilität bei der Gestaltung und Darstellung auf und muss mit laufenden Kosten für das Hosting rechnen.
Mir gefallen beide Ansätze und damit werde ich beide Seiten parallel laufen lassen, um
- weiter Erfahrung zu sammeln
- Unterschiede deutlich machen zu können
- mich selbst zu beobachten, wo ich in Zukunft intuitiv eher hin tendiere
- Möglichkeiten auszunutzen, die nur in einer Variante realisierbar sind
Mit GSB11 soll das Projekt aber nicht zu Ende sein. Ich plane die Seite noch in einer Headless-Version und einer WordPress-Variante aufzusetzen. Am Ende sollen alle Versionen als Auswahl für den Nutzer zur Verfügung stehen.