WordPress Multisite Migration

Lange habe ich gezögert, aber nun hab ich mir endlich die Zeit genommen und mein WordPress  Blog von Multisite – Subfolder auf Multisite – Subdomain zu migrieren.

So etwa sollte man natürlich möglichst vermeiden, da es Auswirkungen auf das Page Ranking in der Google Suche hat, und es auch unschön für die Benutzer der Seite ist, die ggf. die Seitenadressen irgendwo notiert haben.

Aber wenn es denn sein muss, dann sollte man es richtig machen, um mögliche negative Auswirkungen zu minimieren.

Ich habe damals bei meiner Erstinstallation (https://uwesprenger.de/wordpress-installation/) eine Multi-Site Installation gemacht (was ja durchaus sinnvoll ist, wenn man beabsichtigt ggf. mehrere Seiten zu betreiben), mich dabei aber für die SUBDIRECTORY Variante entschieden, und nicht für die SUBDOMAIN-Variante.

Das führte dann dazu, dass meine Links etwa wie folgt aussahen:

http:// uwespr.pf-control.de/BLOG1/permalink

Der String “/BLOG1” hat mich schon immer gestört, und wollte ihn eliminieren, so dass am Ende der Aktion ein Link auf meine Seiten entsteht, der im Idealzustand wie folgt aussieht:

Das hat mehrere Vorteile hinsichtlich SEO:

  • Die Domain „pf-control.de“ ist eine Domain meines Hosters, und wird von sehr vielen anderen genutzt.
    uwespr ist nur eine Subdomain darunter, das wirkt sich nicht positiv auf das Google-Ranking aus.
  • Je kürzer ein Link ist, desto einprägsamer ist er, und „/BLOG1“ ist absolut aussagelos und damit überflüssig.

Wie aber macht man eine solche Umstellung jetzt richtig?

Zur Vorbereitung muss das Plugin „WP Migrate DB“ (https://de.wordpress.org/plugins/wp-migrate-db/)  installiert werden. Dieses Plugin hatte sehr viele positive Beurteilungen und wurde in ebensovielen Beispielmigrationen verwendet. Es wird auch in meinen weiteren Weihnachtsaktionen  immer wieder mal benötigt.

Zudem habe ich mich entschieden, die Aktion in mehreren Steps durchzuführen, um ggf. eine Fehleranalyse  nicht durch zu viele zeitgleiche Änderungen zu erschweren. Das ist immer eine gute Strategie.

Funktionell ist nun folgendes zu tun:

(I) Als allererstes ist eine Datensicherung angesagt:

Die Datenbank, die WP_CONFIG.php sowie die .htaccess Files auf der Root-Ebene und auf der Ebene /BLOG1 sollten gesichert werden. Und wichtig: man sollte auch in der Lage sein, das zurückladen zu können. Einfach mal ausprobieren.

(II) File Copy

Meine WordPress Dateien befanden sich im Verzeichnis /BLOG1 unterhalb des Dokumenten Root Verzeichnisses (htdocs bei Apache Servern). Damit ist ein physikalischer COPY der Daten von /htdocs/BLOG1 nach /htdocs nötig.(Anmerkung: ich kopiere bei solchen Aktionen immer, damit mir ein problemloser Rückweg offen bleibt, das Löschen der Alt-Daten erfolgt später, wenn alles getestet und funktionsfähig ist).

(III) Datenbankänderungen

In allen Datenbanktabellen muss nun der String /BLOG1/ in „/“ geändert werden, und zwar nicht nur in den Klartext-Feldern, sondern auch in den sogenannten serialisierten Daten. (Dort sind mehrere Datenfelder oder ganze Tabellen Inhalt eines einzigen Datenbankfeldes). Das macht das Plugin „WP Migrate DB“ ganz ausgezeichnet. Es gibt auch andere Tools, die das können, aber einige versagen genau bei den serialisierten Daten.

Da man alle Schreibvarianten berücksichtigen muss, habe ich folgende 4 Austäusche vorgenommen: (Einstellungen des Plugins DB Migrate finden sich bei Multisite Installationen auf der Netzwerkebene)

/BLOG1/blog/        ==>                         /
/BLOG1/                  ==>                        /
/BLOG1                    ==>
BLOG1/                    ==>

Ersterer ist eigentlich nicht nötig, ich hatte aber in meiner Datenbank gesehen, dass dort noch ein paar Altlasten mit noch schlimmeren Links enthalten waren.

Multisite Migration mit DB Migrate

Schreenshot von DB Migrate

Das Änderungsprofil sollte man speichern, alleine aus dem Grund, dass man später noch mal nachsehen kann, was man eigentlich änderte.

Schwierig wird es, wenn der Kernbegriff, den man ändert, berechtigt auch noch an der ein- oder anderen Stelle erhalten bleiben soll. Hätte ich beispielsweise diesen Text vorher geschrieben, wäre er durch die DB Migration sicherlich verfälscht worden. In diesen Fällen muss man also ggf. manuell nacharbeiten.

 

 

(VI) Änderungen in der WP-Config.php:

Dort muss die Domain nach wie vor lauten:

define(‚DOMAIN_CURRENT_SITE‘, uwespr.pf-control.de);

Aber der Path muss geändert werden:

// define(‚PATH_CURRENT_SITE‘, ‚/BLOG1/‘);
define(‚PATH_CURRENT_SITE‘, ‚/ ‚);

Falls sich noch Definitionen zur Site-Url oder Home-Url sollten diese gelöscht oder auskommentiert werden,  die Änderungen wurden in der Datenbank gemacht, diese Einträge werden in der wp-config.php nur nötig, um in Fehlerfällen ggf. die Datenbankinhalte zu übersteuern.

(V) In der htaccess sind nun 2 Aktionen nötig:

Zum einen habe ich de facto meine Multisite-Subdirectoy Installation in eine Multisite-Subdomain Installation umgewandelt. Dadurch ändern sich auch die notwendigen STD WordPress Einträge.

Details siehe hier: https://codex.wordpress.org/htaccess

Die relevanten Auszüge habe ich euch hier hinterlegt:

RewriteEngine On
RewriteBase /BLOG1/
RewriteRule ^index\.php$ – [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ $wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

Und nun müssen die alten Adressen …/BLOG1/…. umgeleitet werden, das bekommt man hin durch
eine einfache Rule:

RewriteRule ^BLOG1/(.*)$ /$1 [R=301,NC,L]

Ein genereller Hinweis noch: arbeitet man mit den Umleitungen, so sollte man zunächst den Code  302 verwenden, bis man sicher ist, dass alles richtig ist. 302 ist die temporäre Umleitung und wird von den Browsern nicht gespeichert. 301 ist eine endgültige Umleitung, die von Browsern gespeichert wird und ggf. auch zu Updates von Lesezeichen. Damit hat man dann ggf. Probleme beim Testen oder muss ständig die Browserdaten löschen.

Erst ganz am Ende der Aktionen ändert man dann alle 302 Umleitungen auf 301 um. Diese registrieren die Browser und nehmen auch die Suchmaschinen zur Kenntnis.

(Vb) Wenn die htaccess mal nicht so will wie sie soll !

Tippfehler sind schnell gemacht, die RegEx Syntax nicht so unmittelbar zu durchschauen, wenn man es nicht täglich macht. Dann aber ist es schwierig, das Problem einfach so zu erkennen. Was funktioniert nicht mehr richtig? Wieso zu viele Umleitungen?

Bei 500er Fehlern ist es recht einfach: Im Apache Error Log findet man Details dazu, bei Syntaxfehlern unmittelbar die fehlerhafte Stelle.

Schwieriger wird es bei Rewrite Fehlern. In meinem Fall hatte ich mir einen Fehler eingebaut, der dazu führte, dass die Seite nicht mehr auf „/index.php“ defaultmässig zugriff. Mit dem Nebeneffekt: „Too many Redirects“, wenn man keine Seite explizit angab. Und ein nicht mehr funktionsfähiger WordPress-Customizer (der lädt nämlich genau die Startseite des Blogs im Frame).

Wenn man also auf solche Probleme stößt ist ein wenig Debugging nötig. Dabei bin ich auf ein nettes, kleines Helferlein gestossen:

https://htaccess.madewithlove.be/

Auf dieser Seite gibt man die Aufruf-URL an, und füllt den Inhalt der htaccess ebenfalls ein (cut & paste). Danach kann man genau verfolgen welche Regeln greifen und wo ggf. ein Zirkelschluss entsteht. Hat mir sehr geholfen.

Darüber hinaus gibt es hier noch ein paar Tipps:

https://stackoverflow.com/questions/9234289/how-to-debug-htaccess-rewriterule-not-working/16378968

Dort werden zum Beispiel folgende Statements angeraten, die in die htaccess eingebaut werden können, um nähere Informationen zu den ankommenden Parametern zu erhalten.

ErrorDocument 200 „Request: %{THE_REQUEST} Referrer: %{HTTP_REFERER} Host: %{HTTP_HOST}“
RewriteRule ^ – [L,R=200]

<If „%{REQUEST_URI} =~ /word$/“>
ErrorDocument 200 „Your expression is priceless!“
RewriteRule ^ – [L,R=200]
</If>

(VI) Abschlusstest

Zum Abschluss bitte nun nicht mehr benötigte BLOG1 Verzeichnis umbenenne und die Seitenaufrufe werden ausgiebig getestet. Nachdem alles OK ist, kann man es dann weglöschen.

Bookmark the permalink.

About Uwe Sprenger

Uwe Sprenger ist ein IT Generalist, der in seiner Freizeit immer gerne neue Möglichkeiten ausprobiert. Und so ist hier dieses Blog zu Wordpress im entstehen. Beruflich bin ich (zur Zeit) intensiv im Lizenz Management unterwegs.  

One Response to WordPress Multisite Migration

  1. Pingback: UweS Blog - HTTPS Umstellung des Blogs

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

12 + 19 =