Drupal verabschiedet sich von .module – und das ist mehr als Aufräumen
Drupal räumt auf. Diesmal an einer Stelle, die fast so alt ist wie das System selbst. Der Abschied von der .module-Datei erzählt mehr über die Zukunft des Systems als über eine Dateiendung: Ein weiterer historischer Sonderweg weicht einer Architektur mit klaren Zuständigkeiten.
Die .module-Datei gehört zu Drupal wie Hooks, Nodes und die Frage, warum dieses eine Modul eigentlich noch installiert ist. Generationen von Projekten sind damit gewachsen. Manche sehr ordentlich. Andere mit einer erstaunlichen Begabung, das Provisorium zur Dauerlösung zu machen.
Für Drupal 11.5 ist die Dateiendung als veraltet markiert. Das automatische Laden dieser Dateien soll mit Drupal 13 entfallen. Der Abschied beginnt also mit einer Übergangsphase. Er ist kein Löschbefehl.
Eine Datei kann viel Geschichte sammeln.
Eine .module-Datei ist geduldig.
Ein Hook hier. Eine Hilfsfunktion dort. Noch eine Sonderlogik, weil es gerade schnell gehen musste. Alles funktioniert. Manchmal erstaunlich lange.
Genau darin liegt das Problem.
Die Datei stellt keine Rückfragen. Sie nimmt die Anpassung am Formular ebenso auf wie die Geschäftsregel, den Zugriff auf einen externen Dienst und die kleine Funktion, die inzwischen fünf andere Stellen benutzen. Mit den Jahren wird aus einem überschaubaren Einstiegspunkt ein Archiv früherer Entscheidungen.
Das ist kein Beweis für schlechte Entwickler:innen. Es ist die Folge einer Struktur, die das Zusammenlegen leicht macht und die Trennung der Verantwortung dem Team überlässt. Unter Zeitdruck gewinnt dann häufig die nächste freie Zeile.
Wer später etwas ändern will, muss erst herausfinden, was hier zusammengehört. Und was nur zufällig in derselben Datei wohnt.
Hooks bleiben. Ihre Umgebung verändert sich.
Hooks sind Drupals Erweiterungspunkte. Über sie greifen Module in Abläufe ein, ergänzen Verhalten oder verändern vorhandene Daten. Diese Möglichkeit bleibt erhalten.
Mit objektorientierten Hooks wandern Implementierungen in Klassen. PHP-Attribute kennzeichnen, auf welchen Hook eine Methode reagiert. Bereits Drupal 11.2 hatte die letzten APIs dafür geöffnet, die zuvor noch eine .module-Datei benötigten.
Die fachliche Arbeit lässt sich daneben in Services bündeln: Komponenten mit einer benannten Aufgabe, etwa für eine Schnittstelle oder eine Geschäftsregel. Dependency Injection übergibt ihnen die benötigten Abhängigkeiten ausdrücklich. So wird sichtbar, welche anderen Dienste eine Komponente braucht.
Ein Hook kann damit ein schmaler Einstieg bleiben. Er reagiert auf den Drupal-Ablauf und übergibt die eigentliche Arbeit an den zuständigen Service. Das erleichtert es, Verhalten getrennt zu prüfen und dieselbe Logik an anderer Stelle zu verwenden.
Drupal wird ein Stück gewöhnlicher. Das ist ein Fortschritt.
Seit Drupal 8 gehören Symfony-Komponenten, Services und ein Dependency-Injection-Container zur Grundlage des Systems. Die objektorientierten Hooks führen diese Entwicklung weiter.
Drupal verlässt damit einen weiteren historischen Sonderweg. Mehr Code folgt Mustern, die auch außerhalb des Drupal-Kosmos zur modernen PHP-Entwicklung gehören. Das hilft beim Einstieg, beim Lesen und bei der Zusammenarbeit mit Entwickler:innen, die andere Symfony-basierte Systeme kennen.
Die Dateiendung ist dabei das sichtbare Detail. Die interessantere Frage lautet: Lassen sich Zuständigkeiten und Abhängigkeiten im Code erkennen?
Eine Klasse kann genauso zum Abstellraum werden wie eine .module-Datei. Wer nur sämtliche Funktionen in eine einzige große Klasse verschiebt, hat vor allem die Verpackung gewechselt. Gute Architektur braucht weiterhin Urteilskraft: Was gehört zusammen? Wo endet eine Verantwortung? Welche Abhängigkeit ist wirklich nötig?
Eine Deprecation ist noch kein Migrationsprojekt.
Eine bestehende, funktionierende .module-Datei sollte niemand aus Prinzip umschreiben. Eine Änderung braucht einen Nutzen, einen passenden Zeitpunkt und überprüfbares Verhalten. Auch die unterstützten Drupal-Versionen und andere Module, die vorhandene Funktionen aufrufen, gehören in diese Entscheidung.
Für neue Entwicklung ist die Richtung dagegen klar: Die nächste Geschäftsregel sollte ihren Platz nicht deshalb in der .module-Datei finden, weil dort schon so viel liegt. Neue Architektur entsteht besser um getrennte Komponenten, passende Services und explizite Abhängigkeiten.
Im Bestand lohnt sich der Blick auf die Stellen, die ohnehin verändert werden. Dort lassen sich Verantwortlichkeiten schrittweise herauslösen, Tests ergänzen und alte Aufrufe kontrolliert ablösen. Besonders gemeinsam genutzte Funktionen verlangen einen sauberen Übergang.
So entsteht Fortschritt im normalen Projektverlauf. Der große Umbau auf Verdacht kann warten.
Gute Wartung beginnt vor dem nächsten Major Release.
E-Fork-Kunden können dieser Entwicklung gelassen entgegensehen. Wir verfolgen die Arbeit der Drupal-Community seit Langem und haben die Richtung früh erkannt. Entsprechend bilden wir Logik dort ab, wo sie hingehört: in Event Subscribern, Services, Controllern und Plugins.
Diese Bausteine erfüllen unterschiedliche Aufgaben. Event Subscriber reagieren auf Ereignisse, Services bündeln fachliche Arbeit, Controller verarbeiten Anfragen und Plugins liefern austauschbare Implementierungen. Auch Hooks behalten ihren Platz. Entscheidend ist, dass Zuständigkeiten klar bleiben und Abhängigkeiten sichtbar werden.
Das schafft eine gute Ausgangslage für kommende Updates. Welche eigenen Module sind betroffen? Welche Logik ist schwer zu testen? Wo erschwert eine versteckte Abhängigkeit schon heute die Weiterentwicklung? Diese Fragen prüfen wir laufend.
Aus den Antworten wird ein belastbarer Plan: Sicherheitsupdates bleiben laufende Pflicht. Architekturarbeit bekommt nachvollziehbare Prioritäten und ein eigenes Budget. Der nächste Versionswechsel wird früh geprüft, statt am Ende des Updatepfads Überraschungen zu sammeln.
Weniger historische Sonderfälle machen Updates nicht automatisch mühelos. Sie können aber die Zahl der Stellen verringern, an denen ein Team zuerst alte Gewohnheiten entschlüsseln muss.
Die .module-Datei hat Drupal lange gute Dienste geleistet. Ihr Abschied verdient Ruhe. Und eine klare Entscheidung darüber, worauf wir die nächsten Jahre aufbauen.
Technischer Hintergrund: Drupal-Change-Record zur .module-Deprecation und Drupal 11.2: objektorientierte Hooks. Stand: 7. Oktober 2026.
FAQ
-
Nein. Hooks bleiben Erweiterungspunkte. Ihre Implementierung verlagert sich in objektorientierte Klassen; die Möglichkeit, Drupal-Verhalten gezielt zu erweitern, bleibt bestehen.
-
Nein. Die Deprecation ab Drupal 11.5 ist eine Übergangsphase. Erst für Drupal 13 ist das Ende des automatischen Ladens vorgesehen. Vor dem Entfernen müssen benötigte Funktionen und Aufrufe sauber umgestellt und getestet sein.
-
Weil heutige Architekturentscheidungen den späteren Aufwand bestimmen. Neue Logik konsequent zu trennen und bestehende Abhängigkeiten zu erfassen kostet meist weniger, als kurz vor einem großen Update alles gleichzeitig umbauen zu müssen.
-
Eigene Module gehören früh in die Kompatibilitätsprüfung. Anpassungen lassen sich nach Risiko und Nutzen planen und mit fachlichen Tests absichern. Laufende Sicherheitsupdates bleiben davon unabhängig notwendig. Die Umstellung ist eine planbare Entwicklungsaufgabe, kein Grund für hektische Eingriffe in ein funktionierendes System.