Eine bestehende WordPress-Webseite soll zu Testzwecken auf einen anderen Server umziehen und danach wieder zurück. Die Datenbank wird angepasst, alles funktioniert. Allerdings sind jetzt alle WordPress-Widgets verschwunden und lassen sich nicht mehr finden. Wieso?

 

Wo sind meine WordPress Widgets?

Es gibt verschiedene Szenarien, die eine Änderung der URL einer WordPress-Installation erfordern:

  • WordPress wird auf einem lokalen Rechner (localhost) erstellt und danach auf einen Webserver kopiert
  • Die Webseite wird zu Update-Zwecken oder wegen aufwändiger Anpassungen auf eine Subdomain kopiert
  • Die Webseite soll unter einer neuen URL erreichbar sein.

In allen Fällen muss die Datenbank nach dem Umzug über „Search & Replace“ angepasst werden. Alle bisherigen URLs müssen auf die neue Adresse geändert werden. Also wird z.B.

http://www.meine-seite.de/wp-content/...

zu

http://www.meine-neue-seite.de/wp-content/....

Je nach Größe der Webseite können da schon mal ein paar tausend Links zusammenkommen, da der Link zu jedem Bild, jedem Text, jeder Datei eines Plugins unter der ursprünglich angelegten URL in der Datenbank hinterlegt ist. Das ist das Standard-Verfahren bei jedem Launch, so lange die Webseite nicht unter der Hauptdomain erreichbar ist.

Wenn man dieses „Search & Replace“ gewissenhaft ausführt, gibt es bei der Umstellung der Domain keine Probleme. AUSSER mit den WordPress-Widgets: Sind in einem Text-Widget Links auf die eigene Seite als URL enthalten, kann es vorkommen, dass diese komplett verschwinden und sich nicht ohne weiteres wieder herstellen lassen. Wenn man nur 2-3 Widgets benutzt, ist das kein Drama. Bei größeren Webseiten, die WordPress als CMS benutzen, kommen da gerne ein paar mehr zusammen. Bei einer großen mehrsprachigen Seite z.B. sind 30-40 Widgets keine Seltenheit.

Wann verschwinden die WordPress Widgets?

Wenn die exakte Zeichenzahl der beiden URLs nicht identisch ist, kommt es zu Problemen. Die Gründe hierfür liegen in der Art und Weise, wie WordPress die Widgets in der Datenbank speichert. Nehmen wir an, die alte URL sieht folgendermaßen aus:

http://www.meine-webseite.de/wp-content

Und die neue URL so:

http://localhost:8080/wp-content

Wenn wir jetzt die Zeichenzahl vergleichen sehen wir, dass die 1. URL  39 Zeichen lang ist, die 2. jedoch nur 32 Zeichen hat. Diese Differenz führt offenbar dazu, dass die in der Datenbank hinterlegten Widgets nicht mehr richtig zugeordnet werden können.

Die Lösung

Leland Fiegel hat nach langem Testen herausgefunden, wieso das Problem auftritt. Eine naheliegende Lösung ist, die beiden URLs in der Länge identisch zu setzen. Wenn man z.B. eine Testumgebung unter einer Subdomain einrichtet, die später zur Live-Seite werden soll, bietet es sich an, für die Subdomain statt www z.B. new oder dev zu verwenden. Wichtig ist allein, dass die Zeichenzahl der gesamten URL identisch bleibt.

Wenn man auf localhost entwickelt, fällt das natürlich weg. Hier sollte man die lokale URL in der Zeichenzahl der späteren URL anpassen, indem man einen beliebigen Namen verwendet, der genau so lang ist, wie die Domain, unter der die Webseite nachher im Internet erreichbar sein soll.

Eine weitere Lösung ist der Verzicht auf absolute URLs in einem Widget und stattdessen Shortcodes zu benutzen.

Das alles nützt einem natürlich nichts, wenn das Kind schon in den Brunnen gefallen ist. Allerdings sind die Widgets ja nicht wirklich weg, sie lassen sich in der Datenbank identifizieren. Aber um sich beim nächsten Mal vor unliebsamer Mehrarbeit zu schützen, sollte man die Tipps bei der Wahl der richtigen Development URL beherzigen.