Drupal umziehen — vier Dinge, und eines davon kennt kaum jemand.

Bestandsaufnahme.

1. Drupal-Version und PHP-Version am Ausgangsort.
2. Verfügbare PHP-Fassungen am Ziel — Drupal ist hier anspruchsvoll.
3. Modulliste mit Versionen.
4. Zeitgesteuerte Aufgaben auf dem alten Server.
5. Privates Dateiverzeichnis — gibt es eines, wo liegt es?
6. Zwischenspeicherdienste, falls eingerichtet.
7. Kommandozeilenzugriff am Ziel — bei Drupal wichtig.
8. Größe: Dateianzahl und Datenbankgröße.

Punkt fünf ist der am häufigsten vergessene: Drupal kann Dateien in einem nicht öffentlichen Verzeichnis ablegen, das außerhalb des Webverzeichnisses liegt. Wer nur das Webverzeichnis überträgt, lässt diese Dateien zurück — und sie fehlen dann im Betrieb (Private Dateien).

Punkt sieben ist bei Drupal kein Komfort: Zwischenspeicher leeren, Datenbankaktualisierung und Konfigurationsimport laufen über die Kommandozeile deutlich zuverlässiger (Hosting-Anforderungen).

Ziel vorbereiten.

PHP-Fassung einstellen, benötigte Erweiterungen prüfen, Datenbank anlegen, Grenzen für Arbeitsspeicher und Laufzeit prüfen. Drupal braucht mehr als einfachere Systeme — das ist Folge der Architektur.

Wenn am Ziel ein Zwischenspeicherdienst verfügbar ist, lohnt es, das gleich mit einzurichten. Wenn nicht, muss die Konfiguration entsprechend angepasst werden, sonst sucht Drupal einen Dienst, den es nicht gibt.

Dateien übertragen.

Das gesamte Projektverzeichnis wandert mit — einschließlich der Teile außerhalb des Webverzeichnisses. Bei einer Installation über die Abhängigkeitsverwaltung liegt das Webverzeichnis in einem Unterordner, und darüber liegen weitere Dateien.

Diese Struktur muss am Ziel abgebildet werden. Wenn der Hoster ein festes öffentliches Verzeichnis vorgibt, muss das passen — sonst liegen Dateien im Netz, die dort nicht hingehören.

Nicht mitkopieren: das Zwischenspeicherverzeichnis und die Abhängigkeitsverzeichnisse, falls am Ziel Kommandozeilenzugriff besteht. Letztere lassen sich dort neu aufbauen und machen einen erheblichen Teil der Dateien aus.

Private Dateien.

Ein eigener Abschnitt, weil es so oft schiefgeht. Drupal unterscheidet öffentliche und private Dateien. Öffentliche liegen im Webverzeichnis, private in einem gesonderten Verzeichnis, das von außen nicht erreichbar ist und dessen Auslieferung über Drupal mit Rechteprüfung läuft.

Beim Umzug sind drei Dinge zu tun: das private Verzeichnis mit übertragen, am Ziel außerhalb des öffentlichen Bereichs anlegen, und den Pfad in der Einstellungsdatei anpassen.

Wenn das vergessen wird, fehlen Dateien, die über geschützte Bereiche ausgeliefert werden — und das fällt erst auf, wenn jemand sie abrufen will. Prüf nach dem Umzug gezielt eine private Datei.

Datenbank übertragen.

1. Export über die Kommandozeile, bei Drupal meist die bessere Wahl.
2. Zeichensatz beachten.
3. Am Ziel einspielen.
4. Tabellenzahl vergleichen.
5. Stichprobe auf Inhalte und Umlaute.

Ein praktischer Hinweis: Drupals Zwischenspeicher liegt je nach Einrichtung in Datenbanktabellen, die beim Export erheblich Volumen ausmachen. Wer vor dem Export den Zwischenspeicher leert, bekommt eine deutlich kleinere Datei — bei großen Installationen macht das einen spürbaren Unterschied.

Die Einstellungsdatei.

Hier stehen die umgebungsabhängigen Angaben. Anzupassen sind:

Zeile fünf ist eine Drupal-Eigenheit: Aus Sicherheitsgründen prüft Drupal, unter welchem Hostnamen es aufgerufen wird. Steht die neue Domain oder die Testadresse nicht in der Liste, verweigert Drupal den Dienst mit einer entsprechenden Meldung. Das verwirrt beim ersten Mal und ist schnell behoben.

Für umgebungsabhängige Einstellungen ist eine lokale Zusatzdatei vorgesehen, die von der Hauptdatei eingebunden wird. Diese gehört nicht in die Versionsverwaltung — die Hauptdatei dagegen schon.

Der Hash-Schlüssel.

Das Detail, das kaum jemand kennt und das regelmäßig Ärger macht. In der Einstellungsdatei steht ein zufällig erzeugter Schlüssel, aus dem unter anderem Sitzungen und bestimmte Prüfwerte abgeleitet werden.

Wird am Ziel eine frische Installation aufgesetzt und deren Einstellungsdatei weiterverwendet, hat sie einen anderen Schlüssel. Die Folge: Bestehende Sitzungen gelten nicht mehr, und je nach Konstellation treten merkwürdige Fehler bei Formularen und Prüfwerten auf.

Richtig ist, den Schlüssel aus der alten Einstellungsdatei zu übernehmen. Dann bleibt alles konsistent.

Umgekehrt gilt: Wenn eine Installation kompromittiert war, gehört der Schlüssel ausdrücklich erneuert — er ist ein Geheimnis (Sicherheit).

Dateirechte.

Drupal braucht Schreibrechte im Dateiverzeichnis und im privaten Verzeichnis. Die Einstellungsdatei und ihr Verzeichnis sollten dagegen schreibgeschützt sein — Drupal warnt im Statusbericht, wenn das nicht der Fall ist.

Typisches Bild nach einem Umzug: Dateien gehören dem übertragenden Benutzer, nicht dem Webserver. Dann kann Drupal nicht schreiben, und je nach Stelle entsteht eine weiße Seite oder ein stiller Fehler.

Setz keine pauschal weit offenen Rechte. Der Statusbericht sagt dir nach dem Umzug, was stimmt und was nicht — das ist der schnellste Weg zur Kontrolle.

Zwischenspeicher.

Der alte Zwischenspeicher enthält Pfade und kompilierte Dienste des alten Servers. Mitkopiert führt er zuverlässig zu Fehlern.

Also: nicht übertragen, und falls doch geschehen, am Ziel leeren — über die Kommandozeile oder durch Entfernen der entsprechenden Verzeichnisse und Tabelleninhalte. Drupal baut alles neu auf (Cache leeren).

Unter Testadresse prüfen.

1. Testadresse in die Liste vertrauenswürdiger Hostnamen aufnehmen.
2. Startseite und Inhaltstypen aufrufen.
3. Statusbericht ansehen — er meldet die meisten Probleme von selbst.
4. Private Datei abrufen.
5. Formular absenden und Mailempfang prüfen.
6. Anmeldung mit einem Testkonto.
7. Ansichten prüfen.

Schritt drei ist der effizienteste: Drupals Statusbericht meldet Rechteprobleme, fehlende Verzeichnisse, nicht ausgeführte Aktualisierungen und Konfigurationsabweichungen an einer Stelle.

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

Umschalten und danach.

Umgeschaltet wird über die Namenseinträge; einige Tage vorher die Gültigkeitsdauer senken (DNS).

Danach zu prüfen:

• Echte Domain in die Liste vertrauenswürdiger Hostnamen, Testadresse entfernen.
• Statusbericht ohne Warnungen?
• Suchmaschinensperre entfernt?
• Zeitgesteuerte Aufgaben neu eingerichtet und laufen sie?
• Suchindex neu aufbauen.
• Mailversand testen.
• Zertifikat gültig, Verlängerung aktiv (SSL).
• Erst nach zwei Wochen kündigen.

Punkt vier ist bei Drupal besonders wichtig: Die Wartungsaufgaben erledigen Indexierung, Aufräumarbeiten und Warteschlangen. Ohne sie wirkt zunächst alles normal, und nach Wochen fällt auf, dass die Suche nichts Neues findet (Wartung).

Häufige Fehler.

• Privates Dateiverzeichnis vergessen.
• Hash-Schlüssel nicht übernommen.
• Vertrauenswürdige Hostnamen nicht angepasst.
• Zwischenspeicher mitkopiert.
• Zwischenspeicherdienst eingetragen, den es am Ziel nicht gibt.
• Dateirechte falsch.
• Zeitgesteuerte Aufgaben vergessen.
• PHP-Fassung am Ziel zu alt.
• Zu früh gekündigt.

Die ersten drei stehen alle in derselben Datei und erklären zusammen die Mehrzahl aller Probleme nach einem Drupal-Umzug.

Wenn du nicht weiterkommst.

Wenn ein Umzug ansteht oder danach etwas nicht mehr funktioniert. 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.