WordPress – „Dev/Staging to Live“

Vor einiger Zeit hatten wir hier im Blog eine so elegante wie einfache Lösung vorgestellt, um WordPress-Installationen umzuziehen, etwa bei einem Hoster- oder generellen Serverwechsel.

Bei der Neuerstellung einer Website oder auch bei einem Relaunch kann jedoch durchaus die Situation entstehen, dass die (neu) entwickelte WordPress-Seite gar nicht mehr den Server wechseln, sondern lediglich „live“ geschaltet werden muss. Unterschiedliche Szenarien sind hierfür als Ursache denkbar. Die neue Website könnte etwa bereits auf dem finalen Zielserver entwickelt werden, während die Domain auf eine Landingpage verweist, die über den Seitenaufbau oder Relaunch informiert (und, sofern vorhanden, auf die bisherige Website verlinkt). Denkbar ist jedoch auch, dass in einer Struktur von Development- & Stagingumgebungen beim finalen Golive die letzte Instanz freigeschaltet werden soll.

Wir zeigen heute, wie für eine solche bereits auf dem Live-Server bestehende WordPress-Installation (beispielsweise unter der Subdomain http://dev.domain.ch) der Golive zur allgemeinen Zugänglichkeit via www.domain.ch vollzogen werden kann.
Vorausgesetzt sei hier lediglich, dass für diesen letzten Schritt die Installation an sich inklusive Datenbank nicht mehr umzieht, sondern an Ort und Stelle verbleibt und nur die entsprechenden (Domain-) Einstellungen vorgenommen werden müssen. Ob im Vorfeld bei der Entwicklung separate Development- und Staging-Server eingesetzt wurden, ist in diesem Falle unerheblich.*
Soll also die WordPress-Website, die während der Entwicklung und Fertigstellung unter dev.domain.ch zu erreichen war, nun in den Livebetrieb wechseln und unter www.domain.ch zugänglich gemacht werden, gilt es einige Konfigurationen vorzunehmen. Gewiss liesse sich bei einer solchen Umstellung auch gleich der generelle Wechsel hin zu https vornehmen, wie wir ihn hier bereits beschrieben haben, allerdings macht dies unter WordPress noch einige weitere Konfiguration erforderlich, auf die wir an dieser Stelle nicht weiter eingehen wollen (dies aber möglicherweise in einem separaten Blog-Beitrag nachholen).

Ohne Berücksichtigung einer zeitgleichen Umstellung auf https nun eine kurze Anleitung & Checkliste:

1. Domain neu konfigurieren:

  • Die Hauptdomain darf nicht mehr auf das bisherige Verzeichnis zielen, sondern muss auf das der neuen WordPress-Instanz gerichtet werden.

2. Umstellen von Website- und WordPress-URLs:

  • im WP-Dashboard unter Einstellungen > Allgemein finden sich zwei URLs, die auf die Hauptdomain umgestellt werden müssen; aus dev.domain.ch würde etwa jeweils www.domain.ch
    Wordpress URLs
  • Bestimmte Konfigurationen während der Installation führen jedoch dazu, dass diese Felder im Dashboard nicht editierbar sind. In diesem Falle müssen die beiden URLs manuell in der Datenbank angepasst werden, meist über phpMyAdmin. Ein Vorgehen indes, das generell empfehlenswert ist, da hierbei sichergestellt und überprüft werden kann, dass keine Rest der alten Domain mehr in der Datenbank verbleiben und später zu Fehlern führen.
    In der entsprechenden WordPress-Datenbank finden sich die beiden anzupassenden Domains in der Tabelle wp-options:
    Wordpress wp_options url
  • im Beispiel hiesse dies, anders als der Screenshot andeutet:
    UPDATE wp_posts SET guid = replace(guid, ‚http://dev.domain.ch‘, ‚http://www.domain.ch‘);

    UPDATE wp_posts SET post_content = replace(post_content, ‚http://dev.domain.ch‘, ‚http://www.domain.ch‘);
  • Doch auch in der Tabelle wp_posts findet sich die alte URL, die hier aber nicht händisch geändert werden muss. Stattdessen geschieht dies über einen SQL-Befehl (im Reiter SQL in phpMyAdmin):
    Wordpress phpmyadmin url wp_posts

    Wordpress phpmyadmin sql wp_posts
  • Die SQL-Abfrage lässt sich wie im Screenshot zunächst simulieren; dass hier jeweils 0 Treffer vorliegen, liegt freilich daran, dass die URL in der Abfrage dem Beispiel angepasst, diese aber in einer anderen WP-Datenbank simuliert wurde.
  • Vergleichbares Vorgehen könnte auch noch in der Tabelle wp_postmeta und eventuell weiteren vonnöten sein, wie eine Suche in der gesamten Datenbank aufzuzeigen vermag:
    Wordpress SQL DB-Suche url
  • Dabei ist zu beachten, dass die SQL-Abfragen unterschiedlich formuliert werden müssen (für wp_postmeta bspw. UPDATE wp_postmeta SET meta_value = replace(meta_value, ‚http://dev.domain.ch‘, ‚http://www.domain.ch‘);
    Deshalb ist es ratsam, gerade in Tabellen behutsam und manuell vorzugehen, in denen nur vereinzelt noch die alte Domain auftaucht.

3. Permalinks, RewriteRules & htaccess:

  • Wurden sinnvollerweise lese- und SEO-freundliche Permalinks eingerichtet, damit etwa die Kontaktseite via www.domain.ch/kontakt erreichbar ist anstatt lediglich unter www.domain.ch/?p=059 oder ähnlich, muss nun auch die htaccess-Datei bearbeitet werden. Hier gilt es, die RewriteBase und die RewriteRule entsprechend anzupassen. Das gilt freilich auch für alle anderen Redirects, welche die unterschiedlichen Installationen und (Sub-) Domains während der Entwicklungsphase unter Umständen betrafen.
  • Grundsätzlich müsste nun die WordPress-Seite bereits unter der Hauptdomain erreichbar sein. Ist dies der Fall, könnte dennoch der Quelltext der bereits angezeigten Website nach der alten Domain durchsucht werden, um sicherzustellen, dass diese nicht mehr auftaucht. Grundsätzlich ist dies nach den bisherigen Schritten dennoch nicht absolut auszuschliessen; es ist durchaus möglich, dass beispielsweise ein Plugin noch für einen oder mehrere hardcoded Links sorgt, die dann manuell berichtigt werden müssen.
  • Im Quelltext kann bei dieser Gelegenheit zudem geprüft werden, dass Parameter wie „noindex“ und „nofollow“, die auf der Entwicklungsseite nötig waren, um die Seite vor dem Crawling durch Suchmaschinen-Bots zu bewahren, nicht mehr aktiv sind. So nützlich manche SEO-Plugins für WordPress auch sein mögen, können diese gerade bei Umstellungen wie den hier beschriebenen mitunter für Verwirrung oder gar Probleme sorgen. Es lohnt sich auf jeden Fall, deren Einstellungen nach der Umschaltung oder auch nach einem Umzug detailliert zu überprüfen.
  • Ebenfalls im Quelltext sollte der Trackingcode für Google Analytics beziehungsweise dessen Implementierung ersichtlich sein, sofern Analytics auf der Seite genutzt wird. Um Performance und Visits der neuen mit der alten Seite vergleichen zu können, empfiehlt es sich, den gleichen Trackingcode zu verwenden, anstatt zum Relaunch auch eine neue Property anzulegen.

4. Letzte Domainkonfigurationen:

  • Zu guter Letzt empfiehlt es sich, noch grundsätzliche Einstellungen zu überprüfen, die zwar für die Erreichbarkeit der neuen Seite nicht mehr zwingend erforderlich, aber dennoch ratsam sind:
    • Sollte die neue Website über mehrere Domains erreichbar sein, z.B. via domain.ch, domain.de und domain.com, so sollten all jene mittels eines 301-Redirects auf den Content der Hauptseite leiten, um den Eindruck von Duplicate Content gar nicht erst aufkommen zu lassen.
    • Waren für die bisher genutzte Subdomain separate DNS-Einträge nötig, können diese nun entfernt werden, wenn die Subdomain nicht mehr benötigt wird.

War diese Anleitung hilfreich für Sie? Haben Sie Ergänzungen oder weitere Anregungen zum Thema? Stehen Sie vor einem ähnlichen Problem, können dies aber nicht lösen? Zögern Sie nicht, mit uns Kontakt aufzunehmen!


*  Eine Entwicklungsumgebung mit „echten“ Development- und Staging-Instanzen ist mit WordPress und manchen anderen CMS gar nicht leicht zu realisieren. Stattdessen bleiben nur diverse Workarounds oder die Nutzung von Git, wie speziell für WordPress in einem (externen) Artikel auf t3n.de beschrieben wurde.

Schreiben Sie einen Kommentar

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