Module — weniger ist bei Drupal besonders viel mehr.

Kern und beigesteuert.

Drupal unterscheidet zwischen Modulen im Kern und beigesteuerten Modulen aus der Gemeinschaft. Kernmodule werden mit dem System gepflegt und springen bei Hauptversionen automatisch mit. Beigesteuerte Module haben eigene Veröffentlichungszyklen und eigene Pflegestände.

Daraus folgt die wichtigste Regel beim Aufbau: Was mit Kernmodulen lösbar ist, löst man mit Kernmodulen. Jedes beigesteuerte Modul ist ein Prüfpunkt bei jedem Versionssprung — und ein Risiko, wenn der Betreuer aufgibt.

Was der Kern kann.

Drupal hat über die Jahre viele verbreitete Module in den Kern übernommen. Was heute ohne Zusatz geht:

• Felder an allen Entitäten — Inhalte, Benutzer, Taxonomie, Medien.
• Ansichten für Listen, Filter, Blöcke, Feeds und Datenexporte.
• Medienverwaltung mit wiederverwendbaren Dateien.
• Mehrsprachigkeit einschließlich Übersetzung von Inhalten und Konfiguration.
• Workflows mit Entwurfs- und Freigabezuständen.
• Layout-Werkzeug für Seitenaufbau.
• Schnittstelle zum Abruf von Inhalten.

Die Punkte vier bis sechs waren früher Gründe für mehrere Module. Wer eine ältere Installation betreut, findet dort regelmäßig Module, die inzwischen überflüssig sind — und die beim nächsten Sprung Arbeit machen würden (Versionssprung).

Installieren und entfernen.

1. Vorher sichern.
2. In der Testumgebung beginnen.
3. Über die Abhängigkeitsverwaltung hinzufügen, nicht per Dateiupload.
4. Aktivieren, über Kommandozeile oder Backend.
5. Zwischenspeicher leeren (Cache).
6. Konfiguration exportieren, damit der Zustand versioniert ist.

Beim Entfernen gilt die umgekehrte Reihenfolge, und ein Punkt ist wichtig: Erst deinstallieren, dann aus der Abhängigkeitsverwaltung entfernen. Wer die Dateien löscht, während das Modul noch aktiv ist, hinterlässt einen Zustand, aus dem Drupal nicht sauber herausfindet.

Die zwei Schritte.

Ein Punkt, der Umsteiger von anderen Systemen regelmäßig verwirrt: Herunterladen und Aktivieren sind getrennt. Die Abhängigkeitsverwaltung legt die Dateien ab; aktiviert wird danach separat.

Dasselbe beim Entfernen: Deinstallieren entfernt die Daten und Konfiguration des Moduls aus der Datenbank; aus der Abhängigkeitsverwaltung entfernen löscht die Dateien. Beides gehört gemacht — sonst bleiben entweder Daten zurück oder Dateien, die niemand mehr nutzt.

Verwaiste Konfiguration deinstallierter Module ist eine typische Fehlerquelle beim Konfigurationsimport. Das lässt sich prüfen und bereinigen.

Konflikte.

Die Abhängigkeitsverwaltung meldet, wenn zwei Pakete unvereinbare Fassungen verlangen. Die Meldung nennt die Beteiligten — sie zu lesen lohnt sich, auch wenn sie unübersichtlich wirkt.

Typische Muster: Ein Modul verlangt eine ältere Drupal-Fassung. Zwei Module verlangen unvereinbare Fassungen einer gemeinsamen Bibliothek. Die PHP-Version passt nicht. Eine Fassung ist festgenagelt und blockiert.

Vorgehen: Gibt es eine neuere Fassung? Wird das Modul noch gebraucht? Kann der Kern es? Gibt es Ersatz? Erst danach über Ausnahmen nachdenken.

Ein häufiger Abbruchgrund ist übrigens kein Konflikt, sondern zu knapper Arbeitsspeicher. Die Meldung sieht dann ganz anders aus (Speicherlimit).

Fehlerquelle eingrenzen.

1. Statusbericht lesen — er meldet viele Probleme von selbst.
2. Protokoll lesen — der Dateipfad verrät meist das Modul.
3. In der Testumgebung arbeiten.
4. Verdächtiges Modul deaktivieren, einzeln.
5. Zwischenspeicher leeren und prüfen.
6. Bei Erfolg: Fassung prüfen, Fehlerbericht ansehen, Ersatz erwägen.

Schritt eins ist der Drupal-Vorteil: Der Statusbericht nennt veraltete Module, fehlende Abhängigkeiten, Konfigurationsprobleme und Sicherheitshinweise an einer Stelle. Das spart meist den Rest der Liste (Weiße Seite).

Pflegestand bewerten.

Die letzte Zeile verdient Aufmerksamkeit und ist wenig bekannt: Nicht jedes beigesteuerte Modul wird vom Sicherheitsteam betreut. Module ohne diese Abdeckung bekommen keine koordinierten Sicherheitsmeldungen. Das ist bei der Auswahl ein hartes Kriterium — besonders für öffentliche Stellen (Sicherheit).

Eigene Module.

Wenn es für eine Anforderung nichts Passendes gibt, ist ein eigenes Modul der saubere Weg — und bei Drupal ist das ein etablierter, gut dokumentierter Vorgang, kein Notbehelf.

Was dazugehört: eine klare Struktur mit Abhängigkeitsangaben, Konfiguration als exportierbare Objekte statt fest verdrahtet, saubere Nutzung der vorgesehenen Schnittstellen und Dokumentation.

Der entscheidende Punkt für die Zukunft: Wer sich an die vorgesehenen Schnittstellen hält, baut etwas, das Hauptversionssprünge übersteht — und wenn nicht, meldet die Vorab-Analyse genau die Stellen, die anzupassen sind. Das ist Drupals größte Stärke im Betrieb.

Anpassungen sauber halten.

Manchmal braucht ein Modul eine Korrektur, die der Betreuer noch nicht eingespielt hat. Drupal hat dafür ein etabliertes Verfahren: Korrekturen werden als Dateien hinterlegt und bei jeder Installation automatisch angewendet.

Das ist dem Bearbeiten der Moduldateien weit überlegen — die wären beim nächsten Update weg. Wichtig dabei: Die Korrekturen gehören in die Versionsverwaltung, mit einem Kommentar, worum es geht und wo der zugehörige Fehlerbericht steht.

Und sie gehören regelmäßig überprüft: Wenn die Korrektur in einer neuen Fassung enthalten ist, muss sie weg — sonst bricht die Installation, weil sie nicht mehr anwendbar ist. Das ist eine typische Überraschung beim Versionssprung (Update).

Aufräumen.

Einmal im Jahr, am besten vor einem geplanten Versionssprung:

• Aktivierte Module durchgehen — wird jedes genutzt?
• Prüfen, was der Kern inzwischen kann.
• Nicht gepflegte Module identifizieren und ersetzen.
• Verwaiste Konfiguration entfernter Module bereinigen.
• Hinterlegte Korrekturen prüfen — noch nötig?
• Entwicklungsmodule im Produktivbetrieb entfernen.
• Abdeckung durch das Sicherheitsteam prüfen.

Punkt zwei ist der ergiebigste: In gewachsenen Installationen finde ich regelmäßig drei bis fünf Module, die durch Kernfunktionen überflüssig geworden sind. Jedes davon weniger bedeutet weniger Pflege und einen einfacheren nächsten Sprung.

Punkt sechs ist ein Sicherheitsthema: Entwicklungs- und Diagnosemodule geben im Produktivbetrieb Informationen preis, die dort nicht hingehören.

Wenn du nicht weiterkommst.

Wenn ein Modul Ärger macht oder du vor einem Sprung wissen musst, was mit deinen Modulen passiert. 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.