WordPress Search & Replace in der Datenbank

Nach einem Umzug oder dem Erstellen eines Duplikats einer WordPress-Seite müssen die URLs in der Datenbank angepasst werden. Da Plugins in der Datenbank teils eigene URL-Einträge erstellen, reicht es leider nicht aus, die Haupt-URL in der Datenbank zu ändern. Und genau an dieser Stelle kommt das Tool „Search Replace DB“ zum Einsatz. Erfahre hier, wie du das Tool installierst und anwendest.

Installation

Du brauchst das Zip von Github aus dem Projekt. Gehe dazu auf folgende Adresse und klicke bei „Clone or Download“ auf „Download Zip“.

Link: interconnectit/Search-Replace-DB auf Github (Link öffnet sich in einem neuen Fenster).

Jetzt entpackst du das Archiv und lädst den Ordner „Search-Replace-DB-master“ in den Hauptordner deiner WordPress-Installation – da, wo die wp-config.php liegt! Deine Ordnerstruktur sollte dann wie folgt aussehen:

...
Search-Replace-DB-master
...
wp-config.php
...

Search-&-Replace-Tool öffnen

Öffne nun deinen Browser und folgende URL:

http[s]://[deine_url]/Search-Replace-DB-master/index.php

Es sollte direkt in der Zeile „database“ deine korrekten Zugangsdaten für deine Datenbank stehen. Diese Variablen liest das Skript aus der wp-config.php aus.

Datenbank-Einträge suchen und ersetzen

Wenn die Zugangsdaten für die Datenbank-Verbindung stimmen, dann musst du in der „search/replace“-Zeile die alte und die neue TLD eintragen.

Beispiel! Die alte Domain lautet „altedomain.de“ und die neue Domain lautet „neuedomain.de“. Du musst jetzt in das Feld „search for…“ „altedomain.de“ eintragen und in „replace with…“ die neue Domain „neuedomain.de“.

MACH EIN BACKUP DEINER DATENBANK!!!!1elf!!1

Ganz wichtig! Bevor du an der WordPress-Datenbank rumdokterst – erstelle vorher ein Backup!

Safety first: dry run

Passen alle Felder, dann starte das Tool mit einem Klick auf „dry run“. Es werden noch keine Änderungen geschrieben! Das Tool schaut nur, was es ändern „würde“ und ob es fehlerfrei durchläuft.

Falls ein Popup mit einer Fehlermeldung auftreten sollte, zeige ich dir weiter unten, was du dann tun kannst!

Drücke den roten Knopf!

Lief der „dry-run“ erfolgreich durch, dann kannst du mit einem Klick auf „live run“ das Tool starten und es werden direkt die Änderungen geschrieben.

Fertig? Fast…

Wenn alles beim „live run“ erfolgreich durchgelaufen ist, dann solltest du den Ordner „Search-Replace-DB-master“ löschen! Das ist auch wichtig, denn hier werden deine Zugangsdaten für die Datenbank im Klartext angezeigt!

Wenn du eine Fehlermeldung bekommst…

Das passiert gerne mal, wenn die Datenbank enorm groß ist! Enorm groß kann 600 MB bedeuten. „The script encountered an error while running an AJAX request…“. BTW… Das Problem kann auch auftreten, wenn der PHP-Memory zu klein ist.

Ich empfehle nun die weitere Bearbeitung über das commandline-Interface. Dazu benötigst du einen SSH-/Shell-Zugang zu deinem Webserver, was aber die meisten haben sollten.

Alternativ kannst du, wie in der Fehlermeldung beschrieben, den direkten Zugriff via IP-Adresse deines Webservers probieren. Rein aus Erfahrung wird das aber nicht klappen.

Search-Replace-DB über das CLI steuern

Auf der Github-Seite des Tools (https://github.com/interconnectit/Search-Replace-DB; ext. Link; Link öffnet sich in einem neuen Fenster) ist das recht gut beschrieben. Ein Beispielszenario zeige ich dir hier.

$ php srdb.cli.php -h [host] -n [database_name] -u [user] -p [password] -s [search] -r [replace] [-z]

Alle Optionen sollten soweit klar sein. Die Such- und Ersetzen-Begriffe kannst du in Anführungsstriche schreiben.

Wenn du am Ende ein „-z“ anhängst, dann startest du einen „dry run“ (weiter oben beschrieben). Das solltest du auch zuerst machen, einfach nur um zu schauen, ob alles soweit funktioniert.

Wenn der Server „localhost“ ist, die Datenbank „acmedb“ heißt, der Benutzer „root“ und das Passwort „s3cr3t“ und du einen „dry run“ machen möchtest, dann kann der Aufruf des Skripts wie folgt aussehen:

$ php srdb.cli.php -h localhost -n acmedb -u root -p s3cr3t -s "altedomain.de" -r "neuedomain.de" -z

Neuer Fehler: Fatal error Allowed memory

Jap, das kommt gerne auch mal, wenn deine Datenbank verdammt groß ist.

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /www/htdocs/.../Search-Replace-DB-master/srdb.class.php on line 628

Öffne die Datei „srdb.cli.php“ mit einem Texteditor deiner Wahl und füge direkt unter der Zeile mit „<?php“ (bspw. Zeile 3) folgendes ein:

ini_set('memory_limit', '1024M');

Das erhöht deinen reservierten RAM für das PHP-Skript auf 1 GB.

Error drops again: Segmentation fault

Zwar läuft das Skript jetzt länger, aber es bricht wieder mit einer Fehlermeldung ab. Dafuq! Dieses Mal lautet der Fehler „Segmentation fault„.

Diese Fehlermeldung erscheint, wenn du einfach nicht mehr RAM für das Skript reservieren kannst. Das ist dann echt richtig k4ck3 (Tipp: Leetspeak). Aber was nun? Dir bleibt nur der Umweg über das Bearbeiten einzelner Tabellen. Das ist vorallem lustig, wenn du 116 Tabellen in deiner WordPress-Installation hast…

Du kannst im CLI-Aufruf wenigsten, per Komma separiert, mehrere Tabellen angeben. Das Problem ist hier nur: Was ist mit den Tabellen, die nach dem Abbruch des Skripts noch kommen?

Erster Lösungsansatz #gehtnicht (gerade bei Shared-Hosting-Anbietern mit begrenztem PHP-Memory): Ich habe mir alle Tabellen rausgeschrieben, die eine Änderung im dry-run haben. Diese habe ich dann hinter den „-t“-Parameter gesetzt und das CLI-Tool gestartet. Die Idee dahinter war, dass ich mich so Stück für Stück vorarbeite. Also alle Tabellen ändern bis zum Abbruch, dann erneut das Tool durchlaufen lassen bis zum nächsten Abbruch und wieder die neuen Tabellen aufschreiben usw. Das Problem bleibt aber bestehen. Auch wenn keine Änderungen an einer Tabelle geschrieben werden, dann bricht das Tool immer an der gleichen Stelle ab.

Zweiter Lösungsansatz #hatgeklappt: Ich importiere die Datenbank in meinen lokalen Entwicklungsrechner und führe dort das Skript aus. Hier habe ich immerhin 16 GB RAM 😉 Also XAMPP (ext. Link öffnet sich in einem neuen Fenster) gestartet, die Datenbank lokal per Windows-CMD importiert (wie das geht kannst du hier nachlesen) und das Tool lokal ausgeführt. Nach einem erfolgreichem „live run“ habe ich die Datenbank wieder exportiert (mysqldump -n) und und per FTP auf den Server hochgeladen. Wenn die Datei wieder auf dem Server ist, wird sie per Shell-Befehl wieder importiert und alles ist im Lot! WTF!

• Tipp 1: Die „mysql.exe“ liegt unter Laufwerk:XAMPPmysqlbin
• Tipp 2: wtf ist mein PC langsam beim Import der Datenbank #nossd
• Tipp 3: Das Skript läuft irgendwie nicht mit PHP 7.4, so musste ich noch „kurz“ 7.2 installieren