PROGRESSIVE Drupal – Features für den öffentlichen Sektor

Wer im öffentlichen Sektor eine Website ausschreibt, kennt das Muster. Barrierefreiheit, Datenschutz, Mehrsprachigkeit und ein sauberes Rechtekonzept stehen im Lastenheft. Am Ende werden sie im Projekt mühsam zusammengesucht. Jede Agentur baut dieselben Grundlagen neu, jedes Mal etwas anders.

PROGRESSIVE Drupal dreht das um. Es ist keine leere Drupal-Installation, sondern eine Distribution auf Basis von Drupal 11. Die wiederkehrenden Anforderungen sind ab Werk umgesetzt, gepatcht und aufeinander abgestimmt.

„Die richtigen Entscheidungen, bereits getroffen" ist kein Marketing-Claim. Dahinter steckt eine composer.json mit rund 100 kuratierten Modulen. Dazu eine Theme-Architektur, die diese Entscheidungen trägt.

Was eine Distribution ausmacht

Drupal Core ist bewusst zurückhaltend. Es gibt ein Fundament und überlässt fast alles dem Projekt. Das ist die Stärke von Drupal. Im öffentlichen Sektor ist es zugleich die Falle: Bis Barrierefreiheit, Consent und Workflows stehen, sind Wochen vergangen.

Eine Distribution bündelt diese Entscheidungen einmal, versioniert und wartbar. Bei PROGRESSIVE Drupal heißt das konkret: ein definierter Modul-Stack und ein komponentenbasiertes Theme. Dazu Patches gegen bekannte Contrib-Probleme. Und Konfiguration, die als Code mitläuft statt im Backend zusammengeklickt zu werden.

Barrierefreiheit – auf Komponentenebene, nicht als Overlay

Barrierefreiheit nach BITV 2.0 und WCAG 2.1 beginnt in der Architektur, nicht im Abnahmetest. Die Theme-Komponenten sind von Anfang an darauf ausgelegt, von der Tastaturnavigation bis zur Beschriftung von Formularfeldern. Für Nutzer:innen kommt ein eigenes Barrierefreiheits-Widget hinzu, im Einsatz etwa bei der Universität Siegen.

Im Redaktionsalltag übernimmt das Modul Editoria11y die laufende Kontrolle. Es prüft Inhalte direkt im Editor. Redakteur:innen sehen Probleme, bevor sie veröffentlichen: fehlende Alternativtexte, leere Links, falsche Überschriftenhierarchien.

Das ist der Unterschied zu den verbreiteten Overlay-Widgets. Sie kaschieren Barrieren mit einer JavaScript-Schicht, statt sie im Markup zu beheben.

Datenschutz – DSGVO-konform, ohne Umweg über fremde Server

Beim Datenschutz gilt: möglichst keine externen Ressourcen. Wo sie doch nötig sind, blockiert sie das cookies-Modul bis zur Einwilligung. Schriften werden lokal eingebunden statt über ein US-CDN geladen. Karten und Videos laden erst nach Consent.

Mehrsprachigkeit – mit maschineller Vorübersetzung

Mehrsprachige Auftritte sind im öffentlichen Sektor die Regel. PROGRESSIVE Drupal bringt die Übersetzungsverwaltung TMGMT mit, angebunden an DeepL. Redaktionen lassen Inhalte maschinell vorübersetzen und geben sie anschließend frei.

Der Aufwand sinkt deutlich. Die redaktionelle Kontrolle bleibt.

Redaktion @ Skala – Konfiguration als Code

Föderale Strukturen brauchen klare Rollen. Die Distribution bringt granulares Rechtemanagement, Versionierung und Freigabe-Workflows mit. Wichtiger noch ist der Umgang mit Strukturen: Taxonomien, Blöcke, Menüs. Sie werden nicht nur in der Datenbank gepflegt, sondern als Konfiguration exportiert und versioniert.

drush ea      # Taxonomie-Terms, Blöcke, Menü-Links → Konfiguration
drush cex     # Konfiguration exportieren (Git-tracked)
# ... auf dem Zielsystem:
drush deploy  # Config-Import + DB-Updates + Cache
drush ia      # Strukturen wieder importieren

Das klingt unspektakulär. Genau das ist der Punkt. Änderungen sind nachvollziehbar, überprüfbar und rückrollbar.

Suche und Integration – ehrlich getrennt

Bei der Suche lohnt eine ehrliche Unterscheidung. Ab Werk bringt die Distribution die Search API mit Datenbank-Backend mit. Das deckt einen Großteil der Anforderungen ab, ohne zusätzliche Infrastruktur.

Anspruchsvollere Setups ergänzt man projektspezifisch, etwa um eine Solr-Suche, Single Sign-on oder eine Campus-Anbindung. Diese Bausteine gehören nicht in jede Installation. Deshalb sind sie bewusst nicht Teil des Kerns.

Designsystem – ein CD, das durchgehalten wird

Das Frontend basiert auf einem komponentenorientierten Theme mit Bootstrap 5. Jede Komponente bringt ihr eigenes SCSS und ihre eigene Library mit. Geladen wird sie nur dort, wo sie vorkommt. Das hält die Seiten schlank.

# childtheme.libraries.yml — Komponente nur bei Bedarf laden
karten:
 css:
   component:
     css/components/karten.min.css: { minified: true }

Über die Figma-Anbindung dient das Design-System zugleich als lebendes CD-Manual. Was im Design entschieden wird, landet strukturiert im Frontend.

Wie weit das trägt, zeigt der KonKoop-Atlas des Leibniz-Instituts für Länderkunde. Das Forschungsportal nutzt interaktive Karten, Filter und kartengestütztes Storytelling. Komplexe Komponenten, die im selben Design-System konsistent bleiben.

Betrieb – das Unsichtbare, das den Unterschied macht

Im laufenden Betrieb zahlen sich die getroffenen Entscheidungen aus. config_split trennt Entwicklungs- von Produktiv-Konfiguration. backup_migrate sichert planbar. Performance ist kein nachträglicher Patch, sondern Teil der Bauweise: jedes Render-Array mit definierten Cache-Kontexten und -Tags. Updates laufen über Composer. Contrib-Module werden nie direkt verändert, sondern nur über dokumentierte Patches.

Im Einsatz

PROGRESSIVE Drupal läuft in der Praxis, nicht nur im Pitch. Die Universität Siegen betreibt darauf einen großen Web-Auftritt, barrierefrei und bei dezentraler Redaktion. Das Finanzministerium NRW setzt auf Drupal von uns für „Die Zukunft Steuern", die Plattform der Finanzämter. Auch der KonKoop-Atlas und der Pflegewegweiser NRW laufen auf diesem Fundament.

Fazit

Jede einzelne dieser Entscheidungen lässt sich auch im Projekt treffen. Der Unterschied ist, dass sie hier schon getroffen, getestet und gewartet ist. Das spart Zeit, senkt das Risiko und macht Vergabeverfahren planbarer. Gerade dort, wo Barrierefreiheit und Datenschutz nicht verhandelbar sind.

Mehr zu PROGRESSIVE Drupal