Core und Modul Updates

By PierreAdmin , 17 September 2026

Step by Step Anleitung für Core und Modul-Updates.

Reihenfolge Core und Contrib Updates

Bei Updates spielt es eine Rolle, ob zuerst Core oder die Module/Themes updated werden. Patch und Minor bezeichnet man als Update, ein Major Versionssprung als Upgrade.

Reminder:

1.13.2
│ │  └─ Patch
│ └──── Minor
└────── Major

Patch-Update, z. B. 11.4.6 → 11.4.7

  • Normalerweise Core zuerst
  • Core aktualisieren
  • Datenbank-Updates ausführen
  • Cache leeren
  • Configuration exportieren
  • Website und Status Reports prüfen
  • Git-Diff prüfen
  • Funktionierenden Stand committen
  • Danach Contrib-Module aktualisieren

Minor-Update, z. B. 11.4 → 11.5

  • Zuerst Core Release Notes prüfen
  • Kompatibilität der verwendeten Contrib-Module prüfen
  • Falls erforderlich, kompatible Contrib-Versionen zuerst aktualisieren
  • Änderungen testen und committen
  • Danach Core aktualisieren
  • Erneut testen und committen

Major-Upgrade, z. B. 11 → 12

  • Nicht wie ein normales Update behandeln
  • Bestehende D11-Site zuerst upgradefähig machen
  • Contrib-Module und Custom Code auf D12-Kompatibilität prüfen
  • Notwendige Contrib-Updates möglichst noch unter D11 durchführen
  • Deprecations und inkompatible Komponenten bereinigen
  • Funktionierenden D11-Ausgangszustand sichern
  • Erst danach Core auf D12 upgraden

Updates vorbereiten

Vor Core oder Contrib Updates sollten wir immer einen saubern Stand haben, um bei Problemen schnell wieder zur ursprünglichen Version zurückkehren zu können.

  • Config exportieren.
    • drushh cex
  • DB-Dump erstellen
    Neben Datum:Zeit ist es auch sinnvoll den Grund zu ergänzen: z.B. vor update core 11.4.7.
  • Git-Stand sichern, damit der Working Tree sauber ist
    status > add > comitten > push
    Das ist wichtig, damit wir die geänderten Daten, bei den Core-Updates im Speziellen die Settings-Vorlagen in git diffen können.

Core updaten

Bei Minor oder Major Updates hilft die why und why-not Abfrage, Abhängigkeiten vorher zu prüfen. (Siehe Composer Basics). Detailiertere Beschreibung folgt, sobald das ein Thema ist.

  • Updates abfragen 
    • composer outdated 'drupal/*'
      • Das zeigt uns Core und Contrib, für die neuere Versionen verfügbar sind.. 
  • Security Advisories prüfen
    • composer audit
      •  Damit werden uns die Security relevanten Core und Contrib Informationen angezeigt und gleich auch die Links zu den Beschreibungen ausgegeben
  • Update simulieren
    • composer update 'drupal/core-*' --with-all-dependencies --dry-run
      • Composer berechnet den Update-Vorgang, ohne composer.json, composer.lock oder vendor tatsächlich zu verändern, bzw. irgendwelche Daten zu ändern. Im Output wird angezeigt, welche Elemente geändert werden würden. 
      • Mögliche Probleme, die ein dry-run aufzeigen kann:
        • 1. Ein Contrib-Modul blockiert die neue Core-Version
          Beispiel sinngemäss:
          • drupal/modulename requires drupal/core ^10 || ~11.3 but drupal/core 11.4.x is required
          • Das installierte Modul erlaubt die gewünschte Core-Version laut seiner Versionsvorgabe nicht.
          • Zur Diagnose:
            composer why-not 'drupal/core' 11.4.7
        • 2. Eine Dependency blockiert das Update
          • Ein Modul oder Drupal Core benötigt beispielsweise eine neuere Symfony-, Twig- oder andere Library-Version, während ein anderes Paket nur eine ältere Version erlaubt.
          • Composer kann keinen gemeinsamen Dependency-Stand auflösen.
        • 3. PHP-Version ist nicht kompatibel
          Beispiel sinngemäss:
          • requires php >=8.3 
            your php version does not satisfy that requirement
          • Die gewünschte Paketversion verlangt eine andere PHP-Version als die aktuell verwendete.
        • 4. PHP-Extension fehlt
          Beispiel sinngemäss:
          • requires ext-xyz *
            it is missing from your system
          • Eine benötigte PHP-Erweiterung ist nicht installiert bzw. für die von Composer verwendete PHP-Version nicht aktiviert.
        • 5. composer.json verhindert das Update
          • Eine explizite Versionsvorgabe kann eine benötigte neuere Paketversion blockieren.
            Beispiel:
            • "drupal/modulename": "1.13.0"
            • Composer darf dann dieses Modul nicht auf 1.14 oder 1.15 aktualisieren, selbst wenn dies für den gewünschten Dependency-Stand erforderlich wäre.
        • 6. Teil-Update kann nicht aufgelöst werden
          • Composer soll nur bestimmte Pakete aktualisieren, eine dazugehörige Dependency ist aber in composer.lock auf einer nicht passenden Version festgehalten.
          • Typische Meldungen enthalten beispielsweise:
            • - package is fixed to version ...
              - package is locked to version ...
              - partial update ...
        • 7. Konflikt zwischen Paketen
          • Zwei Pakete verlangen inkompatible Versionen derselben Dependency.
          • Composer kann dann keinen Versionssatz finden, der gleichzeitig alle Anforderungen erfüllt.
      • Vorgehen bei einem Fehler
        • Nicht mit Gewalt weiterfahren und nicht sofort Versionsvorgaben ändern.
        • Zuerst die Composer-Meldung lesen und den Verursacher ermitteln.
        • Hilfreiche Befehle:
        • composer why 'drupal/modulename'
        • Zeigt, warum ein Paket installiert ist.
        • composer why-not 'drupal/core' 11.4.7
        • Zeigt, was die gewünschte Core-Version verhindert.
        • composer show 'drupal/modulename'
        • Zeigt Informationen und Abhängigkeiten eines installierten Pakets.
  • Update starten
    • Wenn der dry-run keine Auffälligkeiten zeigt, führen wir das effektive Update durch:
    • composer update 'drupal/core-*' --with-all-dependencies
  • Datenbank updaten, Cache leeren
    • Enweder direkt in drush oder über die URL /update.php
    • drushh updb
drushh cr
  • Config export, DB dump und git clean
    Diese drei Schritte schliessen das Update sauber ab. Danach haben wir ein sauberes Git, einen DB-Dump und einen aktuellen Config Export. Darauf können wir für weitere Updates die schief laufen dann wieder zurückgreifen oder einfach ab diesem Stand sauber weiter arbeiten
    • Config Export drushh cex 
    • DB Dump erstellen
    • git clearen = git add -A, git commit 'update xy done', git push

Contrib (Module) updaten

Nicht vergessen auch hier zuerst: git clearen, DB Dump, drushh cex

  • Updates abfragen 
    • composer outdated 'drupal/*'
      • Das zeigt uns Core und Contrib, für die neuere Versionen verfügbar sind.
      • TIPP: Patches und Minor Updates werden Rot angezeigt, Major Update Gelb gehighlighted. Bei Major Updates (z.B. Devel 5.2.5 > 6.0.2 lohnt sich ein kurzer Check mit why-not.
      •  composer why-not 'drupal/devel' 6.0.0
      • Wird in der Ausgabe angezeigt, dass die 6er Version nicht mit unserer Drupal-Version kompatibel ist, muss man bei der 5 bleiben, ansonsten kann man die 6 testen > MERKE > composer.json ^5.2 auf ^6.0 ändern, damit das Update auch läuft.
  • Security Advisories prüfen
    • composer audit
      •  Damit werden uns die Security relevanten Core und Contrib Informationen angezeigt und gleich auch die Links zu den Beschreibungen ausgegeben.
  • Update simulieren
    • composer update --with-all-dependencies --dry-run

oder für einzelne Module:

composer update 'drupal/backup_migrate' 'drupal/pathauto' 'drupal/devel' --with-all-dependencies --dry-run
    • ## WICHTIG: Falls bei outdated 'drupal/*' Updates angezeigt wurden, im --dry-run aber nichts gemacht wurde, müssen wir die composer.json Datei prüfen, ob dort Constraints falsch gesetzt sind. Z.B. fixe Versionen, oder Ranges, wo wir keine Updates möchten. Das kann z.B. auch bei gepatchten Sachen sein, dass man dort explizit Updates vermeiden möchte, wobei hier auch anzumerken ist, dass patches wenn man es über Composer macht irgendwo vermerkt werden. Weiss ich jetzt nicht... muss ich noch nachtragen.
    • Constraints fixen
      Falls wir Constrainsts fixen möchten, können wir das direkt in der Composer.json Datei händisch ändern, oder mittels Composer. In einem Beispiel z.B. wie folgt. Hier waren die drei Module auf eine fixe Version beschränkt. Das Zauberwort heisst hier --no-update, was nur die Änderung in der composer.json Datei bewirkt.
      Zur Kontrolle in git kurz diffen.
      • composer require --no-update 'drupal/backup_migrate:^5.1' 'drupal/pathauto:^1.13'
composer require --dev --no-update 'drupal/devel:^5.3'
    • Update simulieren wiederholen
      zur Sicherheit lassen wir den --dry-run nochmal laufen.
      • composer update --with-all-dependencies --dry-run

oder für einzelne Module:

composer update 'drupal/backup_migrate' 'drupal/pathauto' 'drupal/devel' --with-all-dependencies --dry-run
  • Update starten
    • Wenn der dry-run keine Auffälligkeiten zeigt, führen wir das effektive Update durch:
    • composer update --with-all-dependencies

oder für einzelne Module:

composer update 'drupal/backup_migrate' 'drupal/pathauto' 'drupal/devel' --with-all-dependencies
  • Datenbank updaten, Cache leeren
    • Entweder direkt in drush oder über die URL /update.php
    • drushh updb
drushh cr
  • Config export, DB dump und git clean
    Diese drei Schritte schliessen das Update sauber ab. Danach haben wir ein sauberes Git, einen DB-Dump und einen aktuellen Config Export. Darauf können wir für weitere Updates die schief laufen dann wieder zurückgreifen oder einfach ab diesem Stand sauber weiter arbeiten
    • Config Export drushh cex 
    • DB Dump erstellen
    • git clearen = git add -A, git commit 'update xy done', git push
Composer