Grundsätzlich ist es natürlich möglich, eine bestehende WordPress-Installation auf einen anderen Server umzusiedeln, aber das ist nicht unbedingt die empfehlenswerteste Variante, denn WordPress ist nicht wirklich dazu geschaffen umgesiedelt zu werden. Der Grund dafür liegt in der Struktur des CMS-Systems und wie es im Hintergrund aufgebaut ist. Ich versuche es in ganz einfachen Worten zu beschreiben, worin das Hauptprobelm liegt.
Problem beim Umsiedeln von WordPress-Websites
Alle Dateien (Grafiken, Downloads, etc.. ) Ihrer WordPress-Website werden lokal auf der dafür vorgesehenen Datenbank eines Servers gespeichert. Somit vergibt das System für jeden Speicherplatz einen Systempfad. Auch CSS-Dateien (die für das Design, also wie etwas dargestellt wird) werden auf einem fixen Speicherort (mit einem fixen Pfad) in der Datenbank abgelegt. Ein Beispiel dafür ist: /www/htdocs/v763875/musterdomain.at/wp-content/uploads/elementor/css/post-433.css. Dieser Pfad kann sich ändern, wenn 1. die Domain sich ändert: /www/htdocs/v763875/musterdomain.at/wp-content/uploads/elementor/css/post-433.css oder sich die Datenbank ändert: /www/htdocs/v763875/musterdomain.at/wp-content/uploads/elementor/css/post-433.css oder beides: /www/htdocs/v763875/musterdomain.at/wp-content/uploads/elementor/css/post-433.css oder sonst irgendetwas. WordPress schafft es leider nicht „fehlerfrei“ von selbst, diese Systempfade automatisch mitzuverändern, wenn sicher der Speicherort der Dateien verändert. Aus diesem Grund ist es am besten, eine WordPress-Installation für immer am selben Speicherort zu belassen.
Neue Domain für WordPress-Website
Grundsätzlich ist das Umsiedeln von WordPress gar kein Problem, wenn der Provider bestehen bleibt. Dahingehend kann man dann auch nicht von „Umsiedeln“ sprechen. In der Praxis kann das der Fall sein, wenn man die Website mit einer neuen Domain verbinden will. Das bedeutet im Klartext:
- www.altedomain.at (verweist auf Datenbank „xyz123“ bzw. „/“ (root-Verzeichnis), Speicherort der Website)
- www.neuedomain.at (auf selben Speicherort verweisen)
In den meisten Fällen will man, dass die alte Domain dennoch für zB. Bestandskunden, welche alte Visitenkarten haben, bestehen bleibt. In so einem Fall setzt man am besten eine 301-Weiterleitung von www.altedomain.at auf www.neuedomain.at. Somit kann man ganz einfach auch weiterhin über die alte Domain die Website erreichen. Diese Einstellungen nimmt man im Verwaltungssystem des jeweiligen Providers vor.
Im WordPress-Backend selbst muss allerdings auch noch eine wichtige Einstellung vorgenommen werden. Unter https://neuedomain.at/wp-admin/options-general.php geben Sie im Feld „WordPress-Adresse (URL)“ die neue Domain ein, sowie auch gleich im Feld „Website-Adresse (URL)“ darunter. Im Idealfall sind diese beiden Felder mit der gleichen URL ausgestattet. Nun weiß WordPress unter welchem Domainnamen die Website ab jetzt läuft. Ist hier etwas Falsches eingetragen, so wird prompt eine Fehlermeldung ausgegeben. Daher empfehle ich, diesen Vorgang sehr behutsam vorzunehmen.
Grundsätzlich sind das alle erforderlichen Schritte, die für einen einfachen Domain-Wechsel (beim selben Provider) bei WordPress erforderlich sind. Ändert sich auch der Provider, wird die ganze Angelegenheit etwas komplizierter.
Wie geht man vor, wenn ein echtes Umsiedeln von WordPress nicht vermeidbar ist?
In Praxis hat sich herausgestellt, dass ein echtes Umsiedeln einer Website in den meisten Fällen nur im Rahmen eines Provider-Wechsels zustande kommt. In der Regel wechselt man den Provider, wenn man 1. unzufrieden ist oder 2. sich generell eine neue Website anschaffen will. Eine komplett neue Website ist oftmals der leichtere, wenngleich auch kostenintensivere, Weg.
Achtung: PHP-Version beachten beim Umsiedeln von WordPress
In vielen Fällen lässt sich eine komplett neue Website auch nicht mehr verhindern, wie zum Beispiel dann, wenn das Kernsystem so derart veraltet ist, dass 1. lauter Sicherheitslücken vorhanden sind und 2. System-Updates (zB von veralteten Plugins) rein technisch nicht mehr realisierbar sind oder gänzlich eingestellt wurden. Speziell bei alten Kernsystemen, welche nur auf einer veralteten PHP-Version (PHP Version 5.6 – Eol: Jänner 2019) laufen, sind nicht in der Lage auf neuen Servern, die ab dem Jahr 2019 PHP 5.6 nicht mehr unterstützen, zu laufen. Die derzeit aktuellste PHP-Version ist 7.2 (EoL: Jänner 2021), dementsprechend macht es derzeit (Stand per 10.11.2018) keinen Sinn, eine alte WordPress-Installation umzusiedeln. In diesem Fall rate ich zu einer komplett neuen WordPress-Website. Gerne stehe ich zur Verfügung – senden Sie mir eine unverbindliche Anfrage!
Was passiert, wenn man eine neue WordPress-Version (aktuell 4.9.8) auf einem Server mit einer PHP-Version 5.6 umgesiedelt hat?
Die Frage ist bald nicht mehr relevant, dennoch kurz als Beispiel angeführt. In diesem Fall erscheint beim Erstellen oder Ändern eines Blog-Beitrages oder einer Seite nach dem Speichern eine Fehlermeldung. Dies könnte so aussehen:
Warning: file_put_contents(/www/htdocs/v763875/musterdomain.at/wp-content/uploads/elementor/css/post-433.css): failed to open stream: Permission denied in /www/htdocs/v763875/musterdomain.at/wp-content/plugins/elementor/core/files/base.php on line 112
Hier ergeben sich gleich mehrere Probleme, wobei mir hier in diesem Fall das PHP-Problem aktuell am wichtigsten ist. Durch die Inkompatibilität der PHP-Version am Server ergibt sich ein Zugriffsberechtigungsproblem, welches das System daran hindert, den Befehl richtig auszuspielen. Durch das Aktualisieren des Servers auf die neueste PHP-Version wird man ziemlich schnell Herr der Lage.
Gefahren beim „echten“ Umsiedeln von WordPress
Wie bereits Eingangs erwähnt, ist WordPress „out of the box“ nicht dafür geschaffen, umgesiedelt zu werden. Und dennoch gibt es Lösungen für diese Anforderung, wenngleich es mit hohem Aufwand verbunden ist. Nur zur Information: Unlängst habe ich für den kompletten Umzug einer WordPress-Website in etwa 10 Stunden Arbeitszeit in Kauf nehmen müssen.
Einige Beispiele von Problemen die beim Umsiedeln von WordPress entstehen können:
- Einstellungen im Customizer (Design, Widgets, „Read more“-Text, Theme-Farben) werden zurück gesetzt (kann passieren)
- Design-Elemte (zB Grafiken) im Elementor (falls man diesen verwendet) können ausfallen
- Bild-Upload in der Mediathek funktioniert nicht
- Einstellungen von bestehenden PlugIns werden zurück gesetzt (zB SEO-Einstellungen, XML-Sitemap, Open Graph, … müssen komplett neu eingerichtet werden)
Maßnahmen zur Problemlösung bei Konflikten beim Umsiedeln von WordPress
Wie Eingangs erwähnt, sind folgende beide Aspekte für ein erfolgreiches WordPress Umsiedeln essentiell:
- Aktuelle (bzw. korrekte, kompatible) PHP-Version am neuen Server
- Verwendung der korrekten (neuen) Systempfade in der Datenbank
Speziell der Medien-Upload ist bei System-Pfad-Fehlern stark betroffen. Bekommt man dieses Problem nicht in den Griff, ist eine komplett neue Website wahrscheinlich das Beste, was man tun kann. Wobei ich hier eine „relativ“ einfache Lösung bieten kann, die Website zu retten.
Better Search Replace – das Plugin für unendlich viel Zeitersparnis
Sind die System-Pfade nicht mehr korrekt / aktuell, sieht man sich als 0815-Websitebetreiber vor einem riesigen Code-Jungle-Problem sitzen. Denn jetzt ist Programmier-Kenntnis und Server / Datenbank-Erfahrung zwingend erforderlich um Herr der Lage zu werden.
Wo „um Himmels willen“ müssen nun im ganzen Quellcode die Pfade geändert werden, damit das System stabil läuft?
Das WordPress Plugin „Better Search Replace“ hilft dabei ungemein viel. Um dieses Plugin richtig einzusetzen, ist es allerdings notwendig zu wissen, was man in der Datenbank sucht und wie das „Gesuchte“ ersetzt gehört. Hat man die richtigen Einstellungen vorgenommen, ändert das Plugin vollautomatisch alle gefundenen „alten“ Systempfade und ersetzt diese duch die neuen Systempfade.
Aber ACHTUNG: Das Plugin ändert schonungslos ALLES was genau diese Zeichen-Kombination enthält, daher ist hier schon ziemlich gutes Feingefühl und Erfahrung erforderlich um nicht noch mehr Schaden anzurichten. Man kann zwar einen Testlauf machen, dieser ist aber auch keine Garantie für den Erfolg. Zudem gibt es keine Garantie, dass alle Probleme im Rahmen des Umsiedelns damit behoben sind.
Problem mit Better Search Replace bei großen Websites: Limit = 50.000
Das praktische Plugin „Better Search Replace“ ist leider auf maximal 50.000 Einträge limitiert. Zudem kann es bei vielen Einträgen zu Timeout-Verfällen kommen. Aber es gibt eine praktische Lösung in Form eines anderen, dahingehend leistungsfähigeren WordPress-Plugins: Search & Replace. Auch hier kann ein Testlauf durchgeführt werden und die Handhabung ist im Prinzip gleich. Ich habe das Plugin selbst an einem Large Scale-Projekt getestet und durchgeführt. Es sind dabei keine Probleme entstanden. Dies ist aber – wie immer – keine Garantie, dass es überall funktioniert.
Der Hund liegt im Detail begraben und ich stehe gerne hilfreich oder beratend zur Verfügung
Allerdings kann ich keine Garantie auf Erfolg für alle Fälle geben und auch nicht im Vorfeld abschätzen, wie lange die Lösung aller Probleme dauert. Zu individuell und vielseitig können die Probleme sein.
Fragen?
Haftungsausschluss
Grundsätzlich kann ich keine Haftung für bestehende Projekte und dessen Probleme übernehmen, welche ich nicht selbst aufgesetzt habe oder eine dritte Person Veränderungen dazu durchgeführt hat.
