Was schiefgeht, wenn Sie eine WordPress-Site von lokal auf live verschieben

Die Seite ist auf Ihrem Laptop perfekt. Jede Seite lädt, jedes Bild ist scharf und der Checkout funktioniert. Dann schieben Sie sie auf den Live-Server, öffnen sie in einem Browser und etwas ist nicht in Ordnung.

Lokale und Live-Umgebungen sind unterschiedlicher, als sie scheinen. Diese Lücke ist die Ursache für die meisten Probleme.

Duplicator ist ein WordPress-Backup- und Migrations-Plugin, das auf über 1,5 Millionen Websites läuft. Ein erheblicher Teil der Websites, auf denen Duplicator Pro läuft, sind lokale oder Entwicklungsumgebungen, fast 1 von 10. Das sind viele Leute, die auf einem Laptop entwickeln und auf einen Live-Server pushen.

Wir haben uns die Support-Tickets von Leuten angesehen, die Websites von lokalen auf Live-Server verschieben. Die Fehler sind konsistent, und einer davon tritt hier weitaus häufiger auf als anderswo in unseren Daten.

Diese Zahlen spiegeln das Volumen der Support-Tickets und anonymisierte Installationsdaten wider, nicht die Anzahl der Kunden oder Verkäufe.

Inhaltsverzeichnis

Wichtigste Erkenntnisse

Hier steht in den Tickets, wie eine WordPress-Website von der lokalen Entwicklung auf einen Live-Server verschoben wird. Jede Zahl stammt aus den eigenen Aufzeichnungen von Duplicator.

• Fast 1 von 10 Websites, auf denen Duplicator Pro läuft, sind lokale oder Entwicklungsumgebungen. Die lokale Entwicklung zuerst ist gängige Praxis, kein Ausnahmefall.
• Lokale-zu-Live-Probleme machen etwa 1 von 8 aller Migrations-Support-Tickets aus. Für ein einzelnes Szenario ist das ein großer Anteil.
• SSL ist der charakteristische Fehler bei dieser Übergabe. Er tritt in etwa 1 von 5 lokalen-zu-Live-Tickets auf, etwa fünfzehnmal häufiger als in Migrations-Tickets im Allgemeinen.
• PHP-Versionskonflikte treten hier etwa dreimal häufiger auf als bei anderen Migrationen, da lokale Tools moderne PHP-Versionen mitbringen und viele Live-Hosts hinterherhinken.
• Das häufigste Einzelproblem ist ein Host-Limit, das die Installation stoppt, nicht ein Fehler bei der Verschiebung selbst.
• Fast jeder Fehler lässt sich auf einen Unterschied zwischen den beiden Umgebungen zurückführen, nicht auf die Übertragung.

Kurz gesagt: Ihr Laptop und Ihr Live-Server unterscheiden sich normalerweise in vier Punkten: PHP-Version, SSL, Dateiberechtigungen und die Domain der Website. Klären Sie diese vor der Verschiebung, und die Übergabe verläuft reibungslos.

Eine Einschränkung, die die Interpretation beeinflusst. Dies sind Support-Tickets, daher zeigen sie, wo die lokale-zu-Live-Übergabe fehlschlägt, nicht wie oft sie fehlschlägt.

Viele dieser Verschiebungen verlaufen problemlos und erzeugen nie ein Ticket. Und die 1-zu-10-Zahl beschreibt Websites, auf denen Duplicator Pro läuft, nicht WordPress als Ganzes.

Warum Lokal und Live weiter auseinander liegen, als sie scheinen

Eine lokale WordPress-Umgebung wird für private Tests erstellt. Ein Live-Server ist für das öffentliche Internet gedacht. Das sind unterschiedliche Aufgaben, und die Setups spiegeln dies wider.

Vier Unterschiede verursachen fast alles in diesem Bericht:

• PHP-Version. Lokale Tools und Live-Webhosts verwenden möglicherweise unterschiedliche Standard-PHP-Versionen.
• SSL. Lokal läuft mit einfachem http:// oder einem selbstsignierten Zertifikat. Live erwartet ein echtes.
• Dateiberechtigungen. Lokal ist permissiv, da Sie der einzige Benutzer sind. Live ist stärker eingeschränkt.
• Die Domain. Ihre Website kennt sich selbst als etwas wie meine-seite.local. Nach der Verschiebung existiert dieser Name nicht mehr.

Ob Sie Local, MAMP, XAMPP, Docker oder ein einfaches localhost-Setup verwenden, die Fehlerarten sind die gleichen, da die Lücke zwischen den Umgebungen und nicht zwischen den Tools liegt.

Das SSL-Problem, vor dem niemand Sie warnt

Die Website erscheint auf dem Live-Server, und das Vorhängeschloss fehlt. Oder das Layout ist kaputt, weil die Hälfte der Stylesheets nicht geladen wurde. Oder der Browser zeigt eine Warnung zu gemischten Inhalten an, und Sie haben keine Ahnung, worauf sie sich bezieht.

Dies ist das auffälligste Problem im gesamten Datensatz. SSL-Probleme treten bei etwa 1 von 5 lokalen zu Live-Tickets auf, verglichen mit etwa 1 von 70 bei Migrations-Tickets im Allgemeinen. Das ist etwa die fünfzehnfache Rate, und der Grund liegt eher am Timing als an der Verschiebung selbst.

Ein Migrationstool schreibt die Domain Ihrer Website während der Installation neu. mysite.local wird zu yoursite.com in der gesamten Datenbank, auch innerhalb serialisierter Daten. Dieser Teil ist erledigt.

Das Protokoll ist eine separate Frage. Wenn SSL auf Ihrem Live-Host zum Zeitpunkt der Migration nicht aktiv ist, dann ist http://yoursite.com die korrekte Adresse der Website zu diesem Zeitpunkt. Das ist also das, was in die Datenbank geschrieben wird.

Schalten Sie das Zertifikat danach ein, und Ihre Website wird jetzt über HTTPS ausgeliefert, während ihre eigene Datenbank immer noch http:// angibt. Jede während der lokalen Entwicklung gespeicherte Ressource erbt dasselbe Problem, da keine davon jemals HTTPS benötigte.

Nichts ist fehlgeschlagen. Die Website wurde unter der Adresse verschoben, die sie zu diesem Zeitpunkt hatte.

Die Behebung besteht hauptsächlich darin, die Dinge in der richtigen Reihenfolge zu tun:

• Schalten Sie SSL auf dem Live-Host ein, bevor Sie migrieren. Die meisten Hoster stellen ein kostenloses Zertifikat aus, normalerweise unter einem Abschnitt namens SSL, SSL/TLS oder Sicherheit im Hosting-Kontrollpanel. Machen Sie dies zuerst, und die Installation schreibt von Anfang an https://.
• Wenn Sie bereits umgezogen sind, aktualisieren Sie die Website-URLs. Sie finden diese unter Einstellungen » Allgemein im WordPress-Dashboard, in den Feldern WordPress-Adresse und Website-Adresse.
• Führen Sie eine Suche und Ersetzung durch für http://-Referenzen, die aus der lokalen Entwicklung übrig geblieben sind, damit alte Asset-Links dem neuen Protokoll entsprechen.
• Prüfen Sie auf gemischten Inhalt. Laden Sie die Live-Website, öffnen Sie die Entwicklerkonsole Ihres Browsers und suchen Sie nach Warnungen bezüglich unsicherer Ressourcen. Dort werden die genauen Dateien genannt, die immer noch über http:// geladen werden.

Erledigen Sie SSL vor dem Umzug, und eine überraschende Anzahl von Problemen tritt nie auf.

Was bei Migrationen von Lokal zu Live schiefgeht

SSL ist der Hauptgrund, warum lokale zu Live-Migrationen fehlschlagen, aber es ist nicht der einzige. Hier sind andere Fehler, ihre Ursachen und wie Sie sie beheben können.

Was schief geht	Ungefähre Häufigkeit	Was steckt dahinter	Wie es gelöst wird
Ein Host-Limit stoppt die Installation	Am häufigsten	Das PHP-Timeout oder das Speicherlimit des Live-Servers schneidet die Extraktion ab, was Ihr Laptop nie erzwungen hat	Erhöhen Sie max_execution_time und memory_limit auf dem Host
Die Website ist nach dem Umzug nicht sicher	Etwa 1 von 5	SSL war zum Zeitpunkt des Umzugs nicht auf dem Host aktiv, daher ist die gespeicherte Adresse immer noch http://	Schalten Sie SSL auf dem Host vor der Migration ein und bestätigen Sie dann, dass die Website-URLs https:// verwenden
Der Datenbankimport schlägt fehl	Etwa 1 von 7	Die Live-Datenbankanmeldeinformationen stimmen nicht mit denen überein, die der Host erstellt hat	Geben Sie während der Installation den korrekten Datenbanknamen, Benutzernamen und das Passwort ein
Dateiberechtigungen blockieren den Schreibvorgang	Etwa 1 von 8	Lokal ist permissiv, Live nicht, daher sind Besitzverhältnisse und Schreibzugriff plötzlich wichtig	Setzen Sie Ordner auf 755 und Dateien auf 644 am Zielort
Sie können sich nicht einloggen, sobald es live ist	Etwa 1 von 9	Die gespeicherte Website-URL stimmt nicht mit der Live-Adresse überein, was zu einer Weiterleitungsschleife führt	Korrigieren Sie die WordPress-Adresse und die Website-Adresse und leeren Sie dann die Cookies
PHP-Fehler erscheinen auf der Live-Website	Etwa 1 von 11	Das lokale Tool verwendet neueres PHP als der Host, sodass Funktionen veraltet oder nicht vorhanden sind	Stellen Sie sicher, dass die PHP-Versionen auf beiden Seiten übereinstimmen, bevor Sie umziehen
Einige lokale Referenzen bleiben bestehen	Etwa 1 von 16	URLs, die fest in Theme-Dateien, benutzerdefiniertem Code, Caches oder Diensten von Drittanbietern außerhalb der Datenbank codiert sind	Durchsuchen Sie das Theme und den benutzerdefinierten Code nach der lokalen Domain und leeren Sie dann alle Caches

Lesen Sie die dritte Spalte durch, und das Muster ist kaum zu übersehen. Fast nichts hier wird durch die Übertragung verursacht. Es wird dadurch verursacht, dass der Live-Server anders konfiguriert ist als Ihr Laptop.

Wenn ein Host-Limit die Installation stoppt

Sie starten die Installation auf dem Live-Server, sie läuft eine Weile, dann stoppt sie.

Dies ist das häufigste Einzelproblem bei Tickets von lokal zu live und es ist ein Host-Limit und kein fehlerhafter Umzug. Das PHP-Timeout oder das Speicherlimit des Servers unterbricht den Prozess während der Extraktion, was der aufwendigste Schritt ist. Lokale Maschinen haben keine solche Obergrenze, sodass ein Build, der auf Ihrem Laptop einwandfrei lief, auf Shared Hosting an seine Grenzen stoßen kann.

Erhöhen Sie max_execution_time und memory_limit auf dem Zielserver. Diese befinden sich im Control Panel Ihres Hosts, oft unter PHP-Optionen oder MultiPHP INI Editor, und der Support Ihres Hosts kann sie schnell erhöhen, wenn Sie sie nicht finden können.

Hier macht auch das von Ihnen verwendete Tool einen Unterschied.

Ein Standard-Zip-Archiv muss in einem durchgehenden Lauf entpackt werden. Auf einem Server mit einer kurzen Ausführungsgrenze ist das ein Problem.

Wenn das Entpacken länger dauert als vom Host erlaubt, wird der Prozess mitten im Vorgang abgebrochen, und Sie bleiben mit einer halb entpackten Website und keiner klaren Fehlermeldung zurück.

DupArchive ist das benutzerdefinierte Backup-Archivformat von Duplicator, das so konzipiert ist, dass es stattdessen in kleineren Stücken entpackt werden kann. Es arbeitet sich Stück für Stück durch die Website, sodass kein einzelner Lauf über das Limit des Hosts hinausgehen muss.

Das ermöglicht es Duplicator, große Websites zu verwalten, einschließlich echter Migrationen von 400 GB, auf Servern, die bei einem herkömmlichen Archiv zusammenbrechen würden.

Der eigenständige Installer löst ein verwandtes Problem am anderen Ende. Er benötigt keine bereits vorhandene WordPress-Installation am Zielort, sodass Sie einen lokalen Build auf einen komplett leeren Server verschieben können, ohne vorher etwas einrichten zu müssen.

PHP ist auf Ihrem Laptop neuer als auf Ihrem Host

Lokal funktioniert alles, dann wirft die Live-Website Fehler auf Seiten, die spezifische Plugin- oder Theme-Funktionen verwenden.

Dies tritt bei lokalen zu Live-Umzügen etwa dreimal häufiger auf als bei anderen Migrationen, und es liegt daran, wie die Tools verpackt sind.

Lokale Entwicklungsumgebungen werden mit einer aktuellen PHP-Version ausgeliefert. Viele Live-Hosts verwenden standardmäßig immer noch etwas Älteres, sodass Funktionen, die auf Ihrem Laptop funktionierten, auf dem Server veraltet oder nicht vorhanden sind.

Überprüfen Sie beides, bevor Sie umziehen. In Ihrem lokalen Tool wird die PHP-Version normalerweise im Einstellungsbereich der Website angezeigt.

Auf dem Host, schauen Sie unter PHP-Version, PHP-Version auswählen oder MultiPHP-Manager nach. Gleichen Sie diese ab und erstellen Sie sie basierend auf der Version, die Sie tatsächlich bereitstellen werden.

Der Datenbankimport schlägt fehl

Die Live-Website lädt einen Fehler beim Aufbau einer Datenbankverbindung oder die Installation stoppt beim Datenbank-Schritt.

Nach einem Umzug handelt es sich fast immer um ein Anmeldeinformationsproblem und nicht um eine defekte Datenbank. Der Name, Benutzer oder das Passwort stimmt nicht mit dem überein, was der Live-Host erstellt hat.

Holen Sie sich den Datenbanknamen, Benutzernamen, das Passwort und den Host-Wert von Ihrem Live-Hosting-Konto und geben Sie sie während des Installationsschritts sorgfältig ein. Wenn die Website bereits läuft und fehlschlägt, befinden sich diese Werte in wp-config.php im Stammverzeichnis Ihrer Website, erreichbar über den Dateimanager Ihres Hosts oder einen FTP-Client.

Dateiberechtigungen werden nicht übernommen

Die Installation stoppt mit einem Fehler, der besagt, dass keine Datei geschrieben oder kein Ordner erstellt werden kann.

Lokale Umgebungen sind permissiv, da Sie die einzige Person sind, die sie verwendet. Live-Server sind strenger. Eigentümerschaft und Schreibzugriff, die auf Ihrem Laptop nie wichtig waren, werden hier wichtig.

Setzen Sie Ordner auf 755 und Dateien auf 644 am Zielort. Sie können Dateiberechtigungen ändern über einen FTP-Client oder den Dateimanager Ihres Hosts, die beide eine Berechtigungs- oder CHMOD-Option anzeigen, wenn Sie mit der rechten Maustaste auf einen Ordner klicken. Die Dokumentation Ihres Hosts bestätigt den richtigen Webserver-Benutzer, falls Sie unsicher sind.

Sie können sich nach der Veröffentlichung nicht mehr anmelden

Der Umzug ist abgeschlossen, Sie versuchen sich anzumelden, und die Anmeldeseite wirft Sie zurück oder schleift Sie im Kreis.

Dies verursacht mehr Panik als es verdient. Es bedeutet fast nie, dass der Umzug fehlgeschlagen ist. Die in der Datenbank gespeicherte Website-URL stimmt nicht mit dem überein, wo sich die Website jetzt befindet, daher leitet WordPress Sie immer wieder zu einer Adresse weiter, die nicht mehr existiert.

Korrigieren Sie die Felder WordPress-Adresse und Website-Adresse unter Einstellungen » Allgemein und leeren Sie dann Ihre Cookies.

Wenn Sie das Dashboard überhaupt nicht erreichen können, können Sie beide Werte vorübergehend in wp-config.php festlegen.

Einige lokale Referenzen überleben den Umzug

Die meisten Links funktionieren, aber etwas verweist immer noch auf mysite.local.

Die Datenbankreferenzen werden während der Installation neu geschrieben. Was übrig bleibt, ist alles, was außerhalb der Datenbank liegt: eine URL, die fest in eine Theme- oder Child-Theme-Datei einprogrammiert ist, ein Pfad, der in benutzerdefinierten Code geschrieben wurde, eine gecachte Seite oder ein Drittanbieterdienst, der immer noch auf Ihre Entwicklungsadresse verweist.

Durchsuchen Sie Ihr Theme und Ihren benutzerdefinierten Code nach der lokalen Domain, leeren Sie alle Caching-Plugins und den Server-Cache Ihres Hosts und laden Sie dann neu. Wenn ein Dienst wie ein CDN oder ein externes Formular beteiligt ist, aktualisieren Sie auch die Website-Adresse in diesem Dienst.

Ein Pre-Flight-Check, bevor Sie Lokal nach Live pushen

Sie können die meisten lokalen zu Live-WordPress-Fehler mit etwa fünf Minuten Vorbereitung vermeiden.

• Aktivieren Sie SSL auf dem Live-Host. Dies ist der wichtigste Punkt auf der Liste, und wenn Sie ihn zuerst tun, funktioniert er.
• Vergleichen Sie die PHP-Versionen auf Ihrem lokalen Werkzeug und Ihrem Live-Host und gleichen Sie sie ab.
• Halten Sie Ihre Live-Datenbank-Zugangsdaten bereit, bevor Sie mit der Installation beginnen.
• Kennen Sie die Live-URL und erwarten Sie, dass sich die Adressen der Website mit ihr ändern.
• Halten Sie Ihre Admin-Anmeldung bereit, damit eine Weiterleitungsschleife Sie nicht von Ihrer eigenen Website aussperrt.

Wenn Sie die vollständige Schritt-für-Schritt-Anleitung für den Umzug selbst wünschen, führt Sie unser Leitfaden zur Migration einer lokalen WordPress-Website auf einen Live-Server durch den Prozess. In diesem Bericht geht es um die Unterschiede zwischen den beiden Umgebungen und wie Sie diese im Voraus beheben können.

Duplicator Pro hilft am meisten bei den Teilen, die hier kaputt gehen. Der eigenständige Installer verschiebt eine Website auf einen leeren Server, auch auf einen ohne installierte WordPress-Installation, und DupArchive bewältigt große lokale Builds, ohne beim Entpacken zu überlasten.

Häufig gestellte Fragen (FAQs)

Die Lücke zwischen Ihrem Laptop und Ihrem Server

Jedes Problem in diesem Bericht stammt aus derselben Quelle. Ihre lokale Umgebung und Ihr Live-Server stimmen bei PHP, SSL, Berechtigungen oder dem Namen der Website nicht überein. Der Umzug ist der Zeitpunkt, an dem diese Unstimmigkeiten auf einmal auftreten.

Das ist es wert, klar wiederholt zu werden, da es die Art und Weise ändert, wie Sie sich vorbereiten. Die Migration ist nicht der riskante Teil. Die Nichtübereinstimmung ist es.

Bevor Sie die lokale Website erstellen, überprüfen Sie die PHP-Version des Live-Hosts und aktivieren Sie dessen SSL-Zertifikat. Entwickeln Sie gegen die Umgebung, in die Sie bereitstellen werden, und die meisten Teile dieses Berichts sind für Sie nie relevant.

Bevor Sie das nächste Mal starten, haben Sie einen Weg zurück

Eine Website, die an ihrem ersten Tag live abstürzt, ist ein schlechter Nachmittag. Eine Website, die abstürzt und keine saubere Kopie zum Zurückfallen hat, ist viel schlimmer.

Duplicator Pro wird von mehr als 1,5 Millionen WordPress-Profis verwendet, um ihre Websites zu sichern, zu migrieren und wiederherzustellen. Sein eigenständiger Installer verschiebt einen lokalen Build auf einen leeren Server, und seine Wiederherstellungstools bringen Sie wieder herein, wenn ein Start schiefgeht.

Während Sie hier sind, sind diese anderen WordPress-Ressourcen einen Blick wert:

• Was 8.000+ Support-Tickets über die Gründe für den Abbruch von WordPress-Migrationen verraten
• Was WordPress-Backups zum Scheitern bringt: Lektionen aus über 1.400 Support-Tickets
• Ihre vollständige WordPress-Migration Checkliste (Start bis Ende)
• So verschieben Sie eine WordPress-Website zu einem neuen Hoster
• Wie man eine WordPress-Website aus einem Backup wiederherstellt