WordPress speichert absolute URLs in Dutzenden von Datenbanktabellen, sodass ein Domainwechsel oder eine Umstellung auf SSL alte Adressen verstreut in Beiträgen, Optionen und Plugin-Einstellungen hinterlässt: Mit Suchen und Ersetzen bereinigen Sie diese sicher. Diese Anleitung behandelt die zwei unterstützten Wege dafür in KPanel, warum eine verbreitete dritte Methode Daten beschädigt und wie Sie das Ergebnis überprüfen.
Wann Sie es brauchen
- Beim Wechsel von
http://zuhttps://nach dem Aktivieren von SSL. - Bei einem Domainwechsel, zum Beispiel von
old-brand.co.nzzunew-brand.co.nz. - Nachdem Staging in die Produktion übertragen wurde, wenn der Staging-Hostname noch fest in der Datenbank steht.
- Beim Stilllegen eines alten Asset-Hosts, um jede Bild-URL auf einmal umzustellen.
- Zum Beheben eines Tippfehlers in vielen Beiträgen, etwa einer alten Telefonnummer oder eines nicht mehr geführten Produktnamens.
Suchen und Ersetzen schreibt Zeilen in allen Tabellen auf einmal um, und es gibt kein Rückgängigmachen pro Zeile. Erstellen Sie vor dem Start jedes Mal ein Backup, auch bei einer Änderung, die trivial aussieht. KPanel erstellt automatisch eines, wenn Sie die unten beschriebenen integrierten Werkzeuge verwenden, aber wenn Sie den Befehl selbst ausführen, sind Sie dafür verantwortlich. Siehe Ein Backup erstellen.
Warum Sie nicht einfach ein SQL-REPLACE ausführen können
Dies ist der folgenschwerste Fehler bei der Arbeit mit WordPress-Datenbanken, daher lohnt es sich, ihn zu verstehen, bevor Sie eine Methode wählen.
WordPress speichert Plugin-Einstellungen, Theme-Optionen und Widget-Daten als serialisierte PHP-Strings. Ein serialisierter String speichert die Länge jedes darin enthaltenen Werts, etwa so:
a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}
Das s:26 besagt, dass die URL 26 Zeichen lang ist. Ersetzen Sie http:// durch https:// mit einem einfachen SQL-REPLACE(), wird der Text 27 Zeichen lang, während die gespeicherte Länge weiterhin 26 angibt. PHP weigert sich dann, die gesamte Option zu deserialisieren, und die Einstellung fällt stillschweigend auf leer zurück. Einstellungen des Theme-Customizers verschwinden, Slider verlieren ihre Slides, Plugin-Lizenzen melden sich selbst ab.
Das WP-CLI-Suchen-und-Ersetzen, das KPanel ausführt, deserialisiert jeden Wert, ersetzt darin und serialisiert ihn mit korrigierten Längen erneut. Deshalb ist es die einzige hier dokumentierte Methode.
Führen Sie niemals UPDATE wp_options SET option_value = REPLACE(...) oder das Gleiche in phpMyAdmin auf einer WordPress-Datenbank aus. Es sieht aus, als hätte es funktioniert, es meldet betroffene Zeilen, und es zerstört stillschweigend jede serialisierte Einstellung, die es berührt hat. Eine Reparatur ist nur durch das Wiederherstellen eines Backups möglich.
Methode 1: Die Karte Suchen & Ersetzen
Das ist für fast alle die richtige Wahl. Sie ist in jedem WordPress-Plan verfügbar.
- Melden Sie sich bei KPanel an und klicken Sie in der linken Seitenleiste auf Websites.
- Klicken Sie auf die Website.
- Öffnen Sie den Tab WordPress und dann den Bereich Schnellaktionen.
- Suchen Sie die Karte Suchen & Ersetzen und klicken Sie auf Konfigurieren.
- Geben Sie den vorhandenen Text in Suchen (alter Wert) ein.
- Geben Sie den neuen Text in Ersetzen durch ein.
- Lassen Sie Testlauf (nur Vorschau, keine Änderungen) angehakt und klicken Sie auf Vorschau.
Der Testlauf meldet, wie viele Ersetzungen vorgenommen würden, und schlüsselt die Anzahl nach Tabelle und Spalte auf, sodass Sie genau sehen, wo die Änderung greifen würde, bevor Sie sie ausführen.
Wenn die Vorschau stimmt:
- Entfernen Sie den Haken bei Testlauf.
- Klicken Sie auf Ausführen.
- Bestätigen Sie den Dialog.
Vor Beginn der Ersetzung wird automatisch ein vollständiges Backup erstellt, und der Lauf umfasst alle Tabellen, einschließlich der von Plugins angelegten.
Suchen Sie nach dem spezifischsten String, der möglich ist. Wenn Sie old-domain.co.nz ersetzen, werden auch mail.old-domain.co.nz und staging.old-domain.co.nz umgeschrieben, was selten gewünscht ist. Wenn Sie das Schema einbeziehen, wie in https://old-domain.co.nz, bleibt der Treffer eng gefasst.
Methode 2: WP-CLI über die Konsole
Die Konsole bietet Ihnen dieselbe Engine mit mehr Kontrolle über die Optionen. Sie ist einer der Bereiche, die in verwalteten Plänen erscheinen; in anderen Plänen zeigt die Tab-Leiste stattdessen einen Link +8 bei Managed.
Öffnen Sie die Website, dann WordPress, dann Konsole. Die Eingabeaufforderung beginnt bereits mit wp, geben Sie also nur den Rest des Befehls ein.
Zuerst die Vorschau:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run
Dann die echte Ausführung:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables
Die Konsole erstellt kein Backup für Sie. Das automatische Backup vor dem Lauf gibt es nur, wenn Sie die Karte Suchen & Ersetzen aus Methode 1 verwenden. Wenn Sie den Befehl hier ausführen, erstellen Sie zuerst selbst ein Backup über die Seite Sicherungen der Website.
Nützliche Optionen:
| Option | Was sie bewirkt |
|---|---|
--all-tables | Bezieht von Plugins angelegte benutzerdefinierte Tabellen ein, nicht nur die WordPress-Kerntabellen |
--dry-run | Meldet, was sich ändern würde, und schreibt nichts |
--precise | Verwendet für die Ersetzung PHP statt SQL. Langsamer, kommt aber mit schwierigen serialisierten Strukturen zurecht |
--skip-columns=guid | Lässt die GUIDs der Beiträge unverändert (siehe unten) |
--report-changed-only | Beschränkt die Ausgabe auf Tabellen, die sich tatsächlich geändert haben |
Ein Hinweis zu GUIDs
Jeder WordPress-Beitrag hat eine Spalte guid. Obwohl sie wie eine URL aussieht, ist sie eine Kennung und kein Link, und Feedreader erkennen daran, ob sie einen Eintrag bereits gesehen haben. Wenn Sie sie umschreiben, kann jeder Beitrag in Ihrem Feed wieder als neu erscheinen.
Schreiben Sie GUIDs um, wenn Sie die Domain dauerhaft wechseln und neu beginnen. Überspringen Sie sie mit --skip-columns=guid, wenn Sie nur auf derselben Domain von HTTP zu HTTPS wechseln.
Domainwechsel: Verwenden Sie stattdessen die Karte für die Website-URL
Wenn es darum geht, die Website auf eine neue Domain umzuziehen, beginnen Sie nicht mit Suchen und Ersetzen. Die Karte Website-URL ändern im selben Bereich Schnellaktionen aktualisiert die Optionen siteurl und home und führt die Ersetzung in allen Tabellen in einem einzigen Vorgang in der richtigen Reihenfolge aus. Andersherum vorzugehen kann dazu führen, dass WordPress seinen eigenen Admin-Bereich nicht mehr laden kann.
Nach der Ersetzung
Gehen Sie diese Liste durch, bevor Sie die Arbeit als erledigt betrachten.
- Leeren Sie den Cache. Führen Sie im Bereich Schnellaktionen die Aktion Cache leeren aus. Wenn die Website den Full-Page-Cache verwendet, leeren Sie ihn unter WordPress und dann Caching.
- Leeren Sie die Rewrite-Regeln. Führen Sie im selben Bereich Rewrites leeren aus, oder öffnen Sie in wp-admin Einstellungen und dann Permalinks und klicken Sie auf Änderungen speichern, ohne etwas zu ändern.
- Leeren Sie das CDN, falls die Website es nutzt, unter Leistung und dann Kapsule CDN. Siehe Den Kapsule CDN-Cache leeren.
- Laden Sie die Website in einem privaten Fenster, damit Ihr Browser-Cache Sie nicht in die Irre führen kann.
- Prüfen Sie das Schloss-Symbol. Ein fehlendes Schloss oder eines mit Warnung nach einer SSL-Umstellung bedeutet, dass URLs übrig geblieben sind: Behebung von Warnungen zu gemischten Inhalten.
- Klicken Sie sich durch die heiklen Seiten. Slider auf der Startseite, das Logo im Header, jede mit einem Page Builder erstellte Seite und bei einem Shop den Checkout. Diese enthalten die URLs, die in serialisierten Optionen gespeichert sind.
- Leeren Sie jedes Caching-Plugin über dessen eigene Einstellungsseite.
Fehlerbehebung
Der Testlauf meldet null Ersetzungen. Der String steht nicht in genau dieser Form in der Datenbank. Prüfen Sie auf einen abschließenden Schrägstrich, ein www.-Präfix oder das Schema. Suchen Sie zunächst nur nach dem reinen Hostnamen, um zu bestätigen, dass er überhaupt vorhanden ist.
Nach einem Domainwechsel sind Bilder defekt. Medien-URLs stehen in wp_posts und wp_postmeta und werden von --all-tables erfasst, aber ein CDN oder ein Plugin zur Bildoptimierung speichert möglicherweise eigene umgeschriebene Kopien im Cache. Leeren Sie das CDN und den Cache des Plugins und laden Sie die Seite dann neu.
Nach der Ersetzung sind Einstellungen verschwunden. Das ist das Serialisierungsproblem, und es bedeutet, dass die Änderung mit reinem SQL statt mit den hier beschriebenen Werkzeugen vorgenommen wurde. Stellen Sie das vor dem Lauf erstellte Backup wieder her: Wiederherstellen aus einem Backup.
Staging-URLs tauchen immer wieder auf. Etwas füllt sie erneut ein, meist eine geplante Übertragung oder eine zwischengespeicherte Option. Prüfen Sie den Ablauf unter Der WordPress-Staging-Workflow und stellen Sie sicher, dass URLs umschreiben beim Übertragen angehakt ist.