WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

Suche und Ersetze in Ihrer WordPress-Datenbank durchführen

WordPress speichert absolute URLs in Dutzenden von Datenbanktabellen, daher hinterlässt ein Domänenwechsel oder ein SSL-Umzug alte Adressen in Posts, Optionen und Plugin-Einstellungen: Eine Suche und Ersetze ist die sichere Methode, um diese zu bereinigen. Dieses Handbuch behandelt die zwei unterstützten Möglichkeiten in KPanel, warum eine häufige dritte Methode Daten beschädigt, und wie Sie das Ergebnis überprüfen.

Wann Sie eine benötigen

Umzug von http:// zu https:// nach Aktivierung von SSL.
Domänenwechsel, beispielsweise von old-brand.co.nz zu new-brand.co.nz.
Nach dem Verschieben von Staging in die Produktion, wenn der Staging-Hostname noch in der Datenbank verankert ist.
Stillegung eines alten Asset-Hosts und Umleitung aller Bild-URLs auf einmal.
Behebung eines Tippfehlers im großen Stil über viele Posts hinweg, wie eine alte Telefonnummer oder einen eingestellten Produktnamen.

Eine Suche und Ersetze schreibt Zeilen in jeder Tabelle auf einmal neu und es gibt keine Rückgängigmachung pro Zeile. Erstellen Sie vor dem Start eine Sicherung, immer, auch für eine Änderung, die trivial aussieht. KPanel erstellt automatisch eine, wenn Sie die unten beschriebenen integrierten Tools verwenden, aber wenn Sie den Befehl selbst ausführen, sind Sie dafür verantwortlich. Siehe Sicherung erstellen.

Warum Sie nicht einfach einen SQL REPLACE ausführen können

Dies ist der Einzelfehler mit dem größten Schadensausmaß in WordPress-Datenbankarbeit, daher lohnt es sich, ihn zu verstehen, bevor Sie eine Methode auswählen.

WordPress speichert Plugin-Einstellungen, Theme-Optionen und Widget-Daten als PHP-serialisierte Strings. Ein serialisierter String speichert die Länge jedes Werts darin, wie folgt:

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

Dieses s:26 besagt, dass die URL 26 Zeichen lang ist. Ersetzen Sie http:// mit https:// mit einem einfachen SQL REPLACE(), und der Text wird 27 Zeichen lang, während die gespeicherte Länge immer noch 26 behauptet. PHP weigert sich dann, die gesamte Option zu deserialisieren, und die Einstellung wird stillschweigend auf leer zurückgesetzt. Theme-Customizer-Einstellungen verschwinden, Schieberegler verlieren ihre Folien, Plugin-Lizenzen melden sich ab.

Das WP-CLI-Such-und-Ersetze, das KPanel ausführt, deserialisiert jeden Wert, ersetzt ihn darin und serialisiert ihn mit korrigierten Längen erneut. Das ist der Grund, warum es die einzige hier dokumentierte Methode ist.

Führen Sie niemals UPDATE wp_options SET option_value = REPLACE(...) oder das Äquivalent in phpMyAdmin gegen eine WordPress-Datenbank aus. Es sieht aus, als würde es funktionieren, es meldet betroffene Zeilen, und es zerstört stillschweigend jede serialisierte Einstellung, die es berührt hat. Es gibt keine Reparatur außer der Wiederherstellung einer Sicherung.

Methode 1: Die Karte „Suche und Ersetze"

Dies ist die richtige Wahl für fast jeden. Sie ist bei 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 die Registerkarte WordPress, dann den Abschnitt Quick Actions.
Suchen Sie die Karte Search & Replace und klicken Sie auf Configure.
Geben Sie den vorhandenen Text in Find (old value) ein.
Geben Sie den neuen Text in Replace with ein.
Lassen Sie Dry run (preview only, no changes) aktiviert und klicken Sie auf Preview.

Der Testlauf meldet, wie viele Ersetzungen vorgenommen würden, und schlüsselt die Anzahl nach Tabelle und Spalte auf, damit Sie genau sehen können, wo die Änderung landen würde, bevor Sie sich verpflichten.

Wenn die Vorschau korrekt aussieht:

Deaktivieren Sie Dry run.
Klicken Sie auf Run.
Bestätigen Sie das Dialogfeld.

Eine vollständige Sicherung wird automatisch vor Beginn der Ersetzung erstellt, und der Lauf umfasst alle Tabellen, einschließlich der von Plugins erstellten.

Suchen Sie nach dem spezifischsten String, den Sie können. Das Ersetzen von old-domain.co.nz schreibt auch mail.old-domain.co.nz und staging.old-domain.co.nz um, was selten das ist, was Sie möchten. Das Einschließen des Schemas, wie in https://old-domain.co.nz, hält die Übereinstimmung eng.

Methode 2: WP-CLI über die Konsole

Die Konsole bietet Ihnen die gleiche Engine mit mehr Kontrolle über Flags. Sie ist einer der Abschnitte, die bei verwalteten Plänen angezeigt werden; bei anderen Plänen zeigt die Registerkartenliste stattdessen einen Link +8 on Managed.

Öffnen Sie die Website, dann WordPress, dann Console. Die Eingabeaufforderung beginnt bereits mit wp, geben Sie also nur den Rest des Befehls ein.

Zunächst eine Vorschau:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

Führen Sie es dann richtig aus:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

Die Konsole erstellt für Sie keine Sicherung. Die automatische Sicherung vor der Ausführung erfolgt nur, wenn Sie die Karte „Search & Replace" in Methode 1 verwenden. Wenn Sie den Befehl hier ausführen, erstellen Sie zunächst selbst eine Sicherung auf der Registerkarte Backups der Website.

Nützliche Flags:

Flag	Aktion
`--all-tables`	Bezieht benutzerdefinierte Tabellen ein, die von Plugins erstellt wurden, nicht nur die WordPress-Kerntabellen
`--dry-run`	Meldet, was sich ändern würde, und schreibt nichts
`--precise`	Verwendet PHP anstelle von SQL für die Ersetzung. Langsamer, aber verarbeitet schwierige serialisierte Strukturen
`--skip-columns=guid`	Lässt Post-GUIDs in Ruhe (siehe unten)
`--report-changed-only`	Trimmt die Ausgabe auf Tabellen, die sich tatsächlich geändert haben

Hinweis zu GUIDs

Jeder WordPress-Post hat eine guid-Spalte. Obwohl es wie eine URL aussieht, ist es eine Kennung, keine Verknüpfung, und Feed-Reader verwenden sie, um festzustellen, ob sie ein Element bereits gesehen haben. Das Umschreiben kann bewirken, dass jeder Post in Ihrem Feed als neu angezeigt wird.

Schreiben Sie GUIDs um, wenn Sie die Domäne dauerhaft wechseln und neu beginnen. Überspringen Sie sie mit --skip-columns=guid, wenn Sie nur von HTTP zu HTTPS auf der gleichen Domäne wechseln.

Domänenwechsel: Verwenden Sie stattdessen die Karte „Change Site URL"

Wenn es nur darum geht, die Website auf eine neue Domäne zu verschieben, beginnen Sie nicht mit Suche und Ersetze. Die Karte Change Site URL, auf dem gleichen Abschnitt Quick Actions, aktualisiert die Optionen siteurl und home und führt die Ersetzung über alle Tabellen in der richtigen Reihenfolge durch. Die umgekehrte Vorgehensweise kann dazu führen, dass WordPress sein eigenes Admin nicht laden kann.

Nach der Ersetzung

Arbeiten Sie diese Liste durch, bevor Sie es für beendet erklären.

Cache leeren. Führen Sie im Abschnitt Quick Actions Flush Cache aus. Wenn die Website den Full-Page-Cache verwendet, löschen Sie ihn von WordPress, dann Caching.
Rewrite-Regeln leeren. Führen Sie Flush Rewrites auf dem gleichen Abschnitt aus, oder öffnen Sie Settings, dann Permalinks in wp-admin und klicken Sie auf Save Changes, ohne etwas zu ändern.
CDN löschen, wenn sich die Website auf der Website befindet, von Performance, dann Kapsule CDN. Siehe Purging the CDN Cache.
Laden Sie die Website in einem privaten Fenster, damit Ihr Browser-Cache Sie nicht täuschen kann.
Überprüfen Sie das Schloss. Ein fehlendes oder warnendes Schloss nach einem SSL-Umzug bedeutet, dass URLs hinterlassen wurden: Fixing Mixed Content Warnings.
Klicken Sie auf die kniffligen Seiten. Homepage-Schieberegler, das Header-Logo, jede Seite, die mit einem Page Builder erstellt wurde, und der Checkout in einem Shop. Diese enthalten die URLs, die in serialisierten Optionen leben.
Löschen Sie alle Caching-Plugins von seinem eigenen Einstellungsbildschirm.

Problembehandlung

Der Testlauf meldet null Ersetzungen. Der String ist nicht in exakt dieser Form in der Datenbank vorhanden. Überprüfen Sie auf einen nachgestellten Schrägstrich, ein www.-Präfix oder das Schema. Versuchen Sie zunächst, nur den reinen Hostnamen zu suchen, um zu bestätigen, dass er überhaupt vorhanden ist.

Bilder sind nach einem Domänenwechsel kaputt. Medien-URLs befinden sich in wp_posts und wp_postmeta und werden von --all-tables aufgegriffen, aber ein CDN oder Image-Optimierungs-Plugin kann seine eigenen umgeschriebenen Kopien zwischenspeichern. Leeren Sie das CDN und den Plugin-Cache, dann laden Sie neu.

Einstellungen sind nach der Ersetzung verschwunden. Das ist das Serialisierungsproblem, und es bedeutet, dass die Änderung mit Raw SQL anstelle der hier beschriebenen Tools vorgenommen wurde. Stellen Sie die vor der Ausführung erstellte Sicherung wieder her: Restoring From a Backup.

Staging-URLs tauchen immer wieder auf. Etwas füllt sie erneut auf, normalerweise ein geplanter Push oder eine zwischengespeicherte Option. Überprüfen Sie den Workflow in Using Staging: Pushing and Pulling und stellen Sie sicher, dass Rewrite URLs aktiviert ist, wenn Sie Push verwenden.

Suchanfragen und Austausch in Ihrer WordPress-Datenbank durchführen