WordPress-Domain und Dateipfade in der Datenbank aktualisieren

Im letzten Blogbeitrag habe ich euch gezeigt, wie ich WordPres Websites auf einen andern Server migriere. In Schritt 7 bin ich auf die Übersetzung der Domain in der Datenbank eingegangen. Dies ist aber nicht die einzige Ersetzung, die man eventuell machen muss. Daher soll es im heutigen Beitrage darum gehen, welche anderen Ersetzungen eventuell noch notwendig sind.

Schauen wir uns also noch einmal die grundlegendste Ersetzung an. Mit diesem Befehl wird die Domain in allen Tabellen ersetzt, die den Präfix der aktuellen WordPress Installation haben:

wp search-replace "https://staging.example.com" "https://example.com" --all-tables-with-prefix

Dieser Befehl ersetzt die Domain in allen Spalten in allen Tabellen einer WordPress-Datenbank, auch wenn diese als serialisiertes PHP-Objekt gespeichert sind.

Zusätzlich sollte auch der Dateipfad auf dem Server ersetzt werden, da dieser von einigen Plugins verwendet wird:

wp search-replace "/home/staging.example.com" "/home/example.com" --all-tables-with-prefix

Weitere alte Domains suchen

Nach der Durchführung dieses Befehls sollten die meisten Domains bereits ersetzt sein. Man kann aber auch sehr einfach prüfen, ob es den alten Wert noch gibt. Auch hierbei hilft uns die WP-CLI:

wp db search "https://staging.example.com"

Weitere Ersetzungen

Leider gibt es sehr viele Plugins, die komplexe Daten in anderen Formaten speichern. Daher ist es empfehlenswert, auch folgende Ersetzungen durchzuführen, sofern die Suche zuvor noch Ergebnisse geliefert hat.

SuchmusterErsetzungBemerkung
http://example.comhttps://example.comNeue Domains ohne SSL
http://staging.example.comhttps://example.comAlte Domains ohne SSL
//staging.example.com//example.comprotokol-relative Pfade
https:\/\/staging.example.comhttps:\/\/example.comJSON-Objekte (ausführen für alle vorherigen Muster)
@staging.example.com@example.comE-Mail-Domains (optional, da nicht immer gewünscht)
staging.example.comexample.comGefährlich!
Ersetzungsmuster bei Domainumstellung

Es sind einige Varianten zu beachten. Für die ersten vier Ersetzungen sollte man zusätzlich alle Slashes “escapen”, falls Objekte als JSON-String gespeichert wurden. Die E-Mail-Adressen sind optional, da auf dem neuen System eventuell keine E-Mails versendet werden sollten (z.B. bei Übertrag von Live zu Staging) oder falls diese im Frontend ausgegeben werden und man nicht möchte, dass hier eine andere Domain zu sehen ist.

Die letzte Ersetzung scheint die beste zu sein, da sie alle vorherigen umfasst. Aber sie kann potentiell auch zu schwierig zu findenden Problemen führen, da der Domainname bespielsweise in Bildnamen vorhanden sein könnte, die dann auf einmal nicht mehr angezeigt werden. Man sollte also am besten niemals nur den Domainnamen ersetzen.

Weitere Maßnahmen

Oft werden in Themes, Plugins oder auf dem Server Caches eingesetzt. Oft haben diese eigene Mechanismen, um diese zu leeren.

Fusion Builder (z.B. Avada Theme)

Unter “Avada/Themename | Theme Options | Performane | Reset Fusion Caches” über den gleichnamigen Button “Reset Fusion Caches” alle Dateien im Cache löschen.

Autoptimize

In der Adminbar findet man einen Eintrag “Autoptimize” und am Ende einen Link “Delete Cache”.

PageSpeed

Den PageSpeed-Cache kann man nur über den Server leeren. Nachdem man sich zu diesem verbunden hat, muss man folgenden Befehl ausführen:

touch /var/cache/pagespeed/cache.flush

Es kann ein paar Sekunden dauern, bis der Cache vollständig geleert ist. Nachdem er leer ist, entfernt man die Datei einfach wieder:

rm /var/cache/mod_pagespeed/cache.flush

Weitere Infrormationen zum partiellen Leeren des Caches findet ihr in der PageSpeed Dokumentation.

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugin, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.