Migration der WordPress-Datenbank

Lesezeit: 9 Minuten

Ich habe mich in den WordPress-Foren darüber umgesehen und nichts gefunden, also dachte ich, ich könnte es hier versuchen.

Wenn Sie ein Staging-/Entwicklungs-Wordpress-Setup haben, das zum Testen neuer Plug-ins und dergleichen verwendet wird, wie gehen Sie vor, um die Daten in der Staging-Datenbank zurück in die Produktionsdatenbank zu migrieren? Gibt es dafür eine „Wordpress Best Practices“-Methode oder muss ich Tabellen manuell von einer Datenbank in die andere migrieren?

Ich habe ein Skript, das eine Kopie meiner Produktions-Wordpress-DB mysqldumpt, sie über meine Test-Wordpress-Installation wiederherstellt und dann alle “Produktions” -Einstellungen und -URLs in der Test-DB korrigiert.

Sowohl meine Produktions- als auch meine Testdatenbanken befinden sich auf demselben Server, aber Sie könnten die mysqldump-Einstellungen so ändern, dass sie ganz einfach von einem Remote-Mysql-Server ausgegeben und auf einem lokalen Server wiederhergestellt werden.

Hier sind meine Skripte:

overwrite_test.coach_db_with_coache_db.sh

#!/bin/bash 
dbUser="co*******"
dbPassword="*****"
dbSource="coach_production"
dbDest="coach_test"
tmpDumpFile="/tmp/$dbSource.sql"

mysqldump --add-drop-table --extended-insert --user=$dbUser --password=$dbPassword --routines --result-file=$tmpDumpFile $dbSource
mysql --user=$dbUser --password=$dbPassword $dbDest < $tmpDumpFile
mysql --user=$dbUser --password=$dbPassword $dbDest < /AdminScripts/change_coach_to_test.coach.sql

change_coach_to_test.coach.sql

-- Change all db references from @oldDomain to @newDomain

SET @oldDomain = 'coach.co.za';
SET @newDomain = 'test.coach.co.za';
SET @testUsersPassword = 'password';

UPDATE `wp_1_options` SET `option_value` = REPLACE(`option_value`,@oldDomain,@newDomain) WHERE `option_name` IN ('siteurl','home','fileupload_url');
UPDATE `wp_1_posts` SET `post_content` = REPLACE(`post_content`,@oldDomain,@newDomain);
UPDATE `wp_1_posts` SET `guid` = REPLACE(`guid`,@oldDomain,@newDomain);
UPDATE `wp_blogs` SET `domain` = @newDomain WHERE `domain` = @oldDomain;
UPDATE `wp_users` SET `user_pass` = MD5( @testUsersPassword );

-- Only valid for main wpmu site
UPDATE `wp_site` SET `domain` = @newDomain WHERE `domain` = @oldDomain;

Vielleicht suchst du einfach nur das Falsche. Würde ein Backup-Plugin dies nicht problemlos handhaben? Ich weiß, dass es sie für alle großen CMS-Pakete gibt …

Die beiden Methoden wären die Verwendung der Export-/Importfunktion unter Tools oder das Kopieren der Datenbank. Ich sende mir wöchentlich eine Kopie meiner Produktionsdatenbank per E-Mail mit dem WordPress-Datenbank-Backup-Plugin.

Die Importfunktion kann beim Verschieben eines WordPress-Blogs problematisch sein, da Sie Ihre php.ini-Datei häufig konfigurieren müssen, da der Standardwert von Dateien, die Sie auf eine gehostete PHP-Implementierung hochladen können, standardmäßig zu klein ist.

Benutzer-Avatar
ungerade

Ich wollte die Datenbank von meiner Produktions-WordPress-Website in eine Offline-Entwicklungskopie davon auf meinem Desktop-Rechner ziehen, damit ich die Website ändern und mit einem vollständigen Satz bestehender Blog-Inhalte und -Historien testen konnte.

Dies erwies sich als problematisch, da ein einfaches Offline-Backup der Datenbank und das Einspielen in die lokale Entwicklungsdatenbank nicht funktionierte.

Die Überwindung dieser Probleme beim Verschieben von Daten aus der Produktions- in die Entwicklungsdatenbank kann wahrscheinlich auch für den umgekehrten Weg verwendet werden – also denke ich, dass Sie diese Richtlinien auch für das verwenden können, was Sie tun möchten – beginnen Sie einfach mit den Entwicklungsdaten und verschieben Sie sie es zu prod.

Die Probleme hier waren:

  1. Die Permalink-Bezeichnungen für die Blog-Posts sind alle in der Datenbank gespeichert, wie sie es für die Online-Version wären, aber meine Offline-Kopie befindet sich nicht unter der Domain-Adresse, sondern im localhost-Verzeichnis. Wenn ich also die Website lokal starte, werden die eigentlichen Blog-Beiträge nicht angezeigt, obwohl die CSS-Formatierung und Bilder vorhanden sind (die Bildlinks sind relativ).
  2. Viele der Links auf der gesamten Website führen zurück zum Internet. Wenn Sie also versuchen, zu Archiven, Kommentaren, Kategorien oder den Hauptbeiträgen zu navigieren, werden Sie zurück ins Internet geschickt, anstatt in der Datenbank zu bleiben lokale Maschine.

Um sicherzustellen, dass ich das richtig mache, habe ich die WordPress-Installation, die ich auf meinem lokalen Computer hatte, weggeblasen und von Grund auf neu gestartet.

Sobald ich eine saubere, neue WordPress-Installation und eine brandneue, frisch erstellte lokale Standarddatenbank dafür hatte, öffnete ich die Datenbank in phpMyAdmin und warf einen Blick auf die wp_posts

Tisch. Darin enthält jeder Datensatz (mit anderen Worten jeder Beitrag) eine Spalte mit dem Titel “guid”, die den Speicherort dieses Beitrags anzeigt. Zum Beispiel der erste in einem frischen Standard

install enthält diesen „guid“-Wert:

http://localhost/wordpress/?p=1

Wenn Sie in der wp_posts-Tabelle Ihrer Online-Version nachsehen, sehen Sie stattdessen an dieser Stelle die URL zu Ihrer Website online.

Sie können die Tabellen nicht einfach vollständig in Ihre lokale Installation importieren, da Sie all diese externen Referenzen importieren werden. Es wird Ihre lokale Version unmöglich machen, lokal zu navigieren.

Also habe ich eine Sicherungskopie der Datenbank meiner Online-Site erstellt und sie lokal als .sql-Datei gespeichert. Ich habe diese Datei dann in einem Texteditor geöffnet (ich habe Notepad ++ verwendet, eine großartige kostenlose Software, aber Sie können jeden Texteditor verwenden). Dinge, auf die ich achten musste:

  • Aus welchen Gründen auch immer, die Tabellen auf meiner Online-Site sind nicht nur zum Beispiel “wp_posts” – sie sind “wp_something_posts” … da sind einige zusätzliche Buchstaben in den Tabellennamen drin.
  • Alle Verweise auf http://…, die meine Online-URL anstelle von localhost/wordpress enthalten

Um es einfach zu halten, machen wir einfach nur die Posts. Suchen Sie in der Sicherungskopie der .sql-Datei, die Sie von Ihrer Online-Datenbank erstellt haben, den Anfang der wp_posts-Tabelle. Es wird in etwa so aussehen:

--

-- Table structure for table `wp_posts`

--



DROP TABLE IF EXISTS `wp_posts`;

CREATE TABLE `wp_posts` (

…usw. Markieren Sie alles darüber bis knapp unterhalb des Kommentars, der den Anfang der Datenbank am Anfang der Datei markiert (es heißt — Database: ‘Ihr Datenbankname’) und löschen Sie ihn. Gehen Sie dann zum Ende Ihrer wp_posts-Tabelle und löschen Sie alles nach dem Ende bis zum Ende der Datei. Jetzt enthält Ihre Datei nur noch Ihre Beiträge und sonst nichts.

Speichern Sie dies als separates Dokument. Nennen posts.sql oder sowas ähnliches.

Nun, in diesem posts.sql Datei müssen Sie zwei Suchen/Ersetzen-Aktionen ausführen.

  1. Finde jede Instanz des Namens der Tabelle wp_something_posts und ersetze ihn durch wp_posts. Sie müssen dies nur tun, wenn Ihre Sicherungskopie Ihrer Online-Datenbank nicht mit Ihrer sauberen lokalen Installation übereinstimmt, was die Tabellennamen betrifft. Sie möchten, dass der Tabellenname in dieser Datei mit dem übereinstimmt, was Ihre lokal installierte WordPress-Datenbank als diesen Tabellennamen hat. Wenn Sie diese Namen nicht übereinstimmen lassen, werden Sie die Posts am Ende nur in eine neue, anders benannte Tabelle importieren, was für Sie überhaupt keinen Nutzen hat.
  2. Suchen Sie jede Instanz von http://… (ersetzen Sie die Auslassungspunkte durch Ihre URL) und ersetzen Sie sie durch
    http://localhost/wordpress (oder was auch immer die lokale URL zu Ihrer Entwicklerversion der Seite ist)

Speichern Sie diese Datei jetzt erneut, um sicherzustellen, dass Sie diese Änderungen übernommen haben.

Nachdem Sie dies getan haben, verwenden Sie phpMyAdmin, um in die WordPress-Datenbank auf Ihrem lokalen Computer zu gelangen, wählen Sie die Registerkarte „Import“ und navigieren Sie mit dem Selektor zu der posts.sql Datei, die Sie gerade erstellt haben, und importieren Sie sie dann. Dadurch werden alle Daten in dieser Datei in Ihre lokale wp_posts-Tabelle gezogen.

Wenn dies abgeschlossen ist, durchsuchen Sie Ihre lokale WordPress-Site. Dort sehen Sie jetzt alle Ihre Beiträge. Hurra!

Möglicherweise müssen Sie für einige andere Tabellen etwas Ähnliches tun, wenn Sie Ihre Kommentare, Tags, Kategorien und statischen Seiten, die Sie erstellt haben, usw. einbringen möchten.

Mir ist klar, dass dies ein komplizierter Prozess ist. Es gibt wahrscheinlich irgendwo ein Tool, das diese Aktivität erleichtert, und wenn jemand eines kennt, würde ich es gerne herausfinden. Wenn jemand einen besseren Weg kennt, dies manuell zu tun als das, was ich beschrieben habe, würde ich das auch gerne wissen!

Bis dahin habe ich mir das so überlegt. Hoffentlich hilft es Ihnen, in die richtige Richtung zu gehen.

Benutzer-Avatar
Peter Saia

Sie müssen die serialisierten Objekte behandeln. Hier ist ein clientseitiges HTML5-Dienstprogramm damit umzugehen. Da alles Javascript ist, ist es ziemlich schnell.

Die Alternative wäre, ein Bash-Skript in Ihre Bereitstellung einzubinden. Sobald die Site bereitgestellt ist, wird die Datenbank gesichert und mit der neuen Domäne deserialisiert.

Benutzer-Avatar
markratleiste

Dies fasst die Probleme mit der WordPress-Kernarchitektur zusammen … aber ich habe ein Plugin geschrieben, das die Probleme mit Domainnamen und absoluten URLs löst, die in der Datenbank gespeichert werden:

http://wordpress.org/extend/plugins/root-relative-urls/

Dadurch werden die von @oddbill beschriebenen Probleme gelöst. Machen Sie sich jedoch keine allzu großen Sorgen darüber, dass die URL in der GUID-Spalte enthalten ist, da dieses Feld niemals für die Linkgenerierung verwendet wird.

@markratledge bietet ein paar Links zu einigen langen Dokumenten, die im Wesentlichen Folgendes sagen:

//Export

mysqldump -u[username] -p[password] [database] > backup.sql

//importieren

mysql -u[username] -p[password] [database] < backup.sql

Sie sollten die comments/comments_meta-Tabellen ausschließen, wenn Sie vom Staging zur Produktion wechseln, damit Sie nicht alle Ihre Kommentare und Trackbacks verlieren (@DavidLaings Ansatz wird diese löschen.) Und dies setzt voraus, dass Sie nur Inhaltsänderungen in Ihrer vornehmen Inszenierungsumgebung. Wenn Sie Änderungen in der Produktion und Ihrer Staging-Umgebung vornehmen möchten, müssen Sie Skripte schreiben, die die Daten synchronisieren, anstatt sie vollständig zu überschreiben … Viel Glück bei dieser Aufgabe, darf ich vorschlagen, Spalten zum Erstellen und Ändern von Zeitstempeln hinzuzufügen, bevor Sie investieren zu viel Zeit mit dem aktuellen Schema.

Und schließlich ist der Ansatz von @RussellStuever in den meisten Fällen geeignet, stellen Sie nur sicher, dass Sie wissen, wann Sie Ihre vom Host zugeordnete Site im Vergleich zu Ihrer Produktionssite durchsuchen. Und seien Sie sich dessen wirklich sicher, da einige Browser DNS-Lookups tagelang zwischenspeichern, bis Sie sie physisch schließen und einen neuen Prozess starten. An diesem Punkt kann das Wechseln des Hosts einige Zeit dauern, und häufiges Wechseln kann frustrierend werden. Und wenn Sie mit einem iPhone testen müssen, müssen Sie die Website zuerst live veröffentlichen oder einen guten Router verwenden, der ausgehende Internetanforderungen lokalen Servern zuordnen kann, da Sie Hostdateien auf den meisten Mobilgeräten nicht ändern können.

Mein Plugin lässt Sie entwickeln und testen http://localhost/ oder http://staging.server.local/ oder http://www.produktion.com ohne die üblichen Fallstricke. Und um dann Daten zu migrieren, ist es so einfach wie das Exportieren und Importieren der Daten, kein Such- und Ersetzungsschritt oder Anpassungen der Datenbankeinstellungen erforderlich.

Und verlassen Sie sich nicht auf das Import/Export-Tool, es erfasst nicht alles in typischen WordPress-Installationen und erfordert immer noch einen unnötigen Such- und Ersetzungsschritt.

1353990cookie-checkMigration der WordPress-Datenbank

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy