Drupal-Entwickler für Updates, Wartung und eigene Module

Behörden, Hochschulen und Verbände

Drupal läuft oft dort, wo eine Organisation viele Websites mit vielen Redaktionen und fein abgestuften Rechten betreibt: Hochschulen, Landes- und Kommunalverwaltungen, Verbände. Für öffentliche Stellen des Bundes gilt die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV 2.0), in Österreich und der EU insgesamt die Richtlinie (EU) 2016/2102. Barrierefreiheit prüfe ich bei jedem Upgrade mit.

Was ich übernehme

Wartung und Sicherheitsupdates mit einem nachvollziehbaren Composer-Workflow, Migration von Drupal 7 auf eine neue Drupal-11-Installation und Upgrades von 10 auf 11, eigene Module und Themes, Deployments mit Drush, Caching und Datenbankoptimierung, Anbindung an CRM und Single Sign-on, Headless-Frontends über JSON:API. Drupal 12 ist für die Woche vom 7. Dezember 2026 geplant, neue Module schreibe ich so, dass dieser Schritt günstig bleibt.

Was ich vermeide

Ich rate nicht zu einem Neubau oder einem Wechsel zu WordPress, wenn Drupal zur Organisation passt. Mehrere Websites aus einer Installation, detaillierte Redaktionsrechte und mehrsprachige Inhalte sind Stärken von Drupal. Eine Migration zwischen Drupal und WordPress, in beide Richtungen, schlage ich nur vor, wenn die Website der Plattform entwachsen ist oder das Team sie nicht pflegen kann.

Wie läuft eine Migration von Drupal 7 auf Drupal 11 ab?

Ein Upgrade an Ort und Stelle gibt es für Drupal 7 nicht. Ich setze eine neue Drupal-11-Installation auf und übernehme Inhalte, Benutzer, Dateien und Taxonomien mit den Core-Modulen Migrate und Migrate Drupal. Auf dem Testsystem läuft drush migrate:import so oft, bis die Zahl der Datensätze mit der alten Datenbank übereinstimmt. Views baue ich von Hand neu, Field Collections werden meist zu Paragraphs, und das alte PHPTemplate-Theme ersetzt ein neues Twig-Theme. Migrate Drupal ist als veraltet markiert und entfällt mit Drupal 12.0, ein Nachfolger als Contrib-Modul ist nicht vorgesehen. Deshalb bringe ich Drupal-7-Websites jetzt auf Drupal 11 und gehe von dort weiter. Alte Adressen, die in Bescheiden, Formularen und PDFs stehen, bekommen Weiterleitungen über das Redirect-Modul. Vor dem letzten Import pausiert die Redaktion kurz, die alte Website bleibt schreibgeschützt online, bis beide eine vereinbarte Zeit parallel gelaufen sind.

Was wird vor einem Drupal-Upgrade geprüft?

Auf einer Kopie der Website installiere ich das Modul Upgrade Status per Composer. Es lässt PHPStan über eigenen Code und Contrib-Module laufen, baut auf drupal-check auf und listet veraltete API-Aufrufe sowie Module, die noch keine Version für Drupal 11 haben. Mechanische Korrekturen übernimmt Drupal Rector (Paket palantirnet/drupal-rector), jede umgeschriebene Zeile sehe ich selbst durch. Die Website muss bereits auf Drupal 10.3.0 oder neuer laufen, weil Drupal 11 die Update-Funktionen älterer Versionen entfernt hat, und der Server braucht PHP 8.3 oder neuer. Bei Behörden mit eigenem Rechenzentrum klären wir das vorab mit dem Betrieb. Ein einziges Modul ohne Drupal-11-Version reicht, damit Composer das gesamte Upgrade nicht auflösen kann. Fehlt nur die Versionsangabe, installiert das Drupal-Lenient-Plugin für Composer das Modul mit einem Patch, ist der Code selbst defekt, korrigiere oder ersetze ich das Modul. composer update --dry-run zeigt vorher, welcher Fall vorliegt. Sie bekommen eine Modulliste mit Aufwand pro Eintrag als Grundlage für ein Leistungsverzeichnis.

Was gehört in einen Wartungsvertrag für Drupal?

Sicherheitsreleases für den Drupal-Core erscheinen an einem Mittwoch im Monat, meist dem dritten, für Contrib-Module an jedem Mittwoch, jeweils zwischen 16:00 und 22:00 UTC, also am Abend mitteleuropäischer Zeit. Den Hinweis lese ich am selben Abend, am Donnerstagmorgen liegt die Aktualisierung auf dem Testsystem. Der Ablauf ist immer gleich: composer update für die betroffenen Pakete, drush updatedb, drush config:export, Kontrolle der Seiten, die die Redaktion am meisten nutzt, Sicherung von Datenbank und Dateien, dann die Auslieferung auf das Live-System. Neue Nebenversionen des Core gehen einige Wochen später denselben Weg, nach der ersten Fehlerbehebungsversion. Der Export steht dort, weil eine Update-Funktion die aktive Konfiguration ändern kann. Landet diese Änderung nicht im Sync-Verzeichnis, macht sie das nächste Deployment mit drush config:import wieder rückgängig. Im Wartungsvertrag stehen die Reaktionszeit bei kritischen Sicherheitshinweisen und wer die Freigabe für das Live-System erteilt, damit eine Aktualisierung nicht auf eine Unterschrift wartet.