Von Drupal 10 auf 11 — geordnet, wenn man vorarbeitet.

Das Prinzip.

Drupal entfernt Funktionen nicht überraschend. Was in einer künftigen Hauptversion wegfällt, wird vorher als veraltet gekennzeichnet und bleibt noch eine Weile nutzbar. Wer diese Hinweise abarbeitet, solange die alte Fassung läuft, hat beim Sprung kaum noch etwas zu tun.

Daraus folgt die wichtigste Regel: Die Vorbereitung passiert in Drupal 10, nicht in 11. Ein System, das in der letzten 10er-Fassung ohne Hinweise auf veraltete Schnittstellen läuft und dessen Module alle eine 11er-Fassung haben, springt meist ohne Drama.

Vorab-Analyse.

Es gibt ein Modul, das genau dafür gebaut ist: Es prüft Kern, beigesteuerte Module und eigenen Code auf Verträglichkeit mit der nächsten Hauptversion und erzeugt eine Liste.

1. Analysemodul installieren in der aktuellen Fassung.
2. Bericht erzeugen und vollständig lesen.
3. Module sortieren: bereit, Fassung in Arbeit, eingestellt.
4. Eigenen Code auf gemeldete Stellen prüfen.
5. PHP-Anforderung gegen den Server halten.
6. Entscheiden, was ersetzt, angepasst oder gestrichen wird.

Dieser Bericht ist der Projektplan. Er sagt präzise, was zu tun ist — das ist eine Qualität, die andere Systeme in dieser Form nicht bieten, und sie wird oft nicht genutzt (Fristen).

Veraltete Schnittstellen.

Der Kern der Vorarbeit. Wenn eigener Code oder ein Modul eine Funktion nutzt, die in der nächsten Hauptversion entfällt, meldet die Analyse das samt Datei und Zeile.

Diese Stellen lassen sich in der alten Fassung beheben — die neuen Schnittstellen existieren dort bereits parallel. Das ist der entscheidende Vorteil: Man arbeitet im laufenden System, ohne Risiko, und der eigentliche Sprung wird klein.

Für häufige Muster gibt es Werkzeuge, die einen Teil der Anpassungen automatisch vornehmen. Den Rest macht man von Hand — und bei einem gewachsenen eigenen Modul ist das der Posten, der die Zeit kostet.

Testumgebung.

Nicht verhandelbar. Die Datenbankaktualisierung ist nicht umkehrbar, und ein Rückweg besteht nur über die Sicherung.

Bei Drupal ist die Testumgebung angenehmer als bei anderen Systemen, weil sich die Konfiguration exportieren und zwischen Umgebungen übertragen lässt. Wer das nutzt, kann den Vorgang sauber proben und anschließend reproduzieren (Testumgebung).

Die Testfassung vor Suchmaschinen sperren — und die Sperre nach dem Umschalten entfernen (robots.txt).

PHP anheben.

Drupal 11 verlangt mindestens PHP 8.3. Heb die Version an, solange noch Drupal 10 läuft — dann siehst du getrennt, was an der Laufzeitumgebung liegt und was am Versionssprung.

Was dabei typischerweise bricht: eigener Code mit überholten Konstrukten, ältere Module, Bibliotheken. Die Meldungen sind meist eindeutig und nennen Datei und Zeile.

Prüf vorher, ob dein Hosting die nötige Fassung anbietet — und gleich mit, ob die für Drupal 12 nötige höhere Fassung absehbar verfügbar sein wird (Hosting).

Composer.

Drupal verwaltet Kern und Module über die Abhängigkeitsverwaltung. Beim Hauptversionssprung wird die Anforderung angehoben und die Auflösung angestoßen.

Hier entstehen die meisten Abbrüche, und sie haben fast immer dieselbe Form: Ein Modul verlangt eine Fassung, die mit der neuen Hauptversion unvereinbar ist. Die Meldung nennt die beteiligten Pakete — sie zu lesen lohnt sich.

Vorgehen bei einem Konflikt: Gibt es eine neuere Fassung? Wird das Modul noch gebraucht? Gibt es Ersatz? Erst danach über Ausnahmen nachdenken — und eine erzwungene Auflösung verschiebt den Widerspruch nur.

Zwei praktische Hinweise: Der Vorgang braucht Arbeitsspeicher; auf knappen Servern scheitert er daran und nicht an den Paketen. Und die erzeugte Sperrdatei gehört in die Versionsverwaltung, damit auf allen Umgebungen dasselbe läuft.

Datenbankaktualisierung.

Nach dem Aktualisieren der Dateien laufen die Datenbankaktualisierungen — über die dafür vorgesehene Adresse im Backend oder, besser, über die Kommandozeile.

Die Kommandozeile ist vorzuziehen, weil der Vorgang bei größeren Installationen länger dauert als eine Browseranfrage erlaubt. Über die Weboberfläche bricht er dann mitten in der Aktualisierung ab — und das ist ein unangenehmer Zustand.

Vorher: Sicherung. Und die Website während des Vorgangs in den Wartungszustand versetzen, damit niemand in eine halb aktualisierte Installation schreibt.

Konfiguration.

Ein Drupal-Vorteil, den man kennen sollte: Die Konfiguration liegt nicht nur in der Datenbank, sondern lässt sich als Dateien exportieren, versionieren und zwischen Umgebungen übertragen.

Beim Versionssprung heißt das: Konfiguration in der Testumgebung exportieren, prüfen, in die Live-Umgebung importieren. Das macht den Vorgang reproduzierbar statt zu einer Reihe von Klicks, die niemand nachvollziehen kann.

Worauf zu achten ist: Neue Hauptversionen bringen neue Konfigurationsschlüssel mit, und entfernte Module hinterlassen verwaiste Einträge. Nach dem Sprung lohnt ein Abgleich, welche Konfiguration noch zu installierten Modulen gehört.

Theme.

Bei Hauptversionssprüngen die übliche Nacharbeit. Drupal nutzt eine moderne Templating-Schicht, und zwischen Hauptversionen ändern sich Vorlagen und Variablen.

Ein eigenes Theme, das von einem Kerntheme abgeleitet ist, kann überholte Vorlagen enthalten. Sie funktionieren teils noch, geben aber nicht mehr dasselbe aus — dann fehlen Elemente oder die Gestaltung verrutscht.

Vorgehen: Eigene Vorlagen auflisten, mit der neuen Kernfassung vergleichen, Anpassungen gezielt übertragen. Und prüfen, ob eine Vorlage überhaupt noch gebraucht wird.

Typische Fehler.

Bei Zeile zwei gilt: Protokoll lesen statt raten. Drupal protokolliert ausführlich und nennt die Stelle (Weiße Seite).

Durchprüfen.

1. Statusbericht ansehen — er meldet die meisten Probleme von selbst.
2. Jeden Inhaltstyp aufrufen und bearbeiten.
3. Ansichten prüfen — Listen, Filter, Blöcke.
4. Formulare absenden und Mailempfang prüfen.
5. Rechte testen mit einem Konto je Rolle.
6. Mehrsprachigkeit, falls vorhanden.
7. Suche ausprobieren.
8. Mobil gegenprüfen.

Punkt drei verdient Aufmerksamkeit: Ansichten sind bei Drupal zentral und liefern einen großen Teil der Seiteninhalte. Wenn eine Ansicht nach dem Sprung anders filtert oder sortiert, fällt das erst auf, wenn jemand genau hinsieht.

Nacharbeit.

• Zwischenspeicher vollständig leeren (Cache).
• Statusbericht auf verbliebene Warnungen prüfen.
• Suchindex neu aufbauen.
• Zeitgesteuerte Aufgaben prüfen — laufen sie noch?
• Konfiguration exportieren und in die Versionsverwaltung aufnehmen.
• Analysemodul erneut laufen lassen — diesmal für die übernächste Hauptversion.
• Auf 11.3 oder höher gehen, das ist Voraussetzung für den nächsten Sprung.

Punkt sechs und sieben sind der eigentliche Gewinn dieses Vorgangs: Wer direkt nach dem Sprung die nächste Analyse laufen lässt, hat zwei Jahre Zeit, die Hinweise abzuarbeiten — und der nächste Sprung wird eine Formalie.

Wenn du nicht weiterkommst.

Wenn der Sprung ansteht und du ihn nicht am laufenden System ausprobieren willst. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Bei einem laufenden Ausfall hilft der Notfall-Support, dauerhaft begleitet die Drupal-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management-Systeme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme nicht nur aus der Anwendung, sondern von innen: Datenmodell, Rechtekonzept, Templating, Modularchitektur, Caching, Betrieb.

Bei Drupal zahlt sich das besonders aus, weil das System konsequenter durchkonstruiert ist als die meisten anderen: Alles ist Entität, alles hat Felder, alles läuft über definierte Schnittstellen. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo eine Installation gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob deine Installation weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.