Gewusst wie: Einfaches Verschieben einer WordPress-Installation von der Entwicklung in die Produktion?

Ich entwickle auf einer Box und verwende eine zweite für die Produktion. Im Moment lösche ich einfach die Datenbank und suche einen Ersatz für die URL-Änderungen. Kopieren Sie dann die Dateien und importieren Sie das neue SQL.

Gibt es dafür bessere Möglichkeiten?

@ Insanity5902 : Die Bereitstellung einer WordPress-Site von einer Box zu einer anderen ist seit dem ersten Tag, an dem ich mit WordPress arbeite, ein PITA. (Um ehrlich zu sein, es war 2 Jahre lang eine PITA mit Drupal, bevor ich mit WordPress angefangen habe, also liegt das Problem sicherlich nicht ausschließlich bei WordPress.)

Es störte mich, dass ich jedes Mal, wenn ich eine Site verschieben musste, so viel doppelte Mühe aufwenden musste, und es verhinderte, dass ich so oft Tests durchführte, wie ich es mir gewünscht hätte. Vor ungefähr 4-6 Monaten habe ich angefangen, an einem Plugin zu arbeiten, um das Webhost-Migrationsproblem zu lösen, und ich habe meine Ideen im WP Tavern-Forum erwähnt .

Nun, schnell vorwärts bis heute und ich habe es so ziemlich zum Laufen gebracht und ich nenne es bequemerweise " WP Migrate Webhosts ". Obwohl das Plugin immer noch sehr viel Beta (wahrscheinlich sogar Alpha) ist, denke ich, dass ich bereit bin, die Leute anfangen zu lassen, damit zu bumsen.

Der vorgesehene Anwendungsfall ist:

1. Zunächst übernimmt der Entwickler das Hochladen aller geänderten Theme- und Plugin-Dateien über FTP.
2. Anschließend wird die Entwicklungs-MySQL-Datenbank vollständig und endgültig auf den Testserver hochgeladen
3. Anschließend wird das Plugin ausgeführt, um alle Verweise von der vorherigen Domäne auf die neue zu migrieren. (Mein Plugin versucht nicht , das Zusammenführen neuer Datenbankfelder oder Tabellen mit Live-Daten zu lösen. Dies ist ein viel größeres Problem, dessen Lösung ich nicht genau weiß .)

Sie können das Plugin von meiner Website herunterladen und in Ihr Plugin-Verzeichnis entpacken (wenn Sie nicht wissen, wie das geht, ist dieses Plugin nichts für Sie, da es jemanden erfordert, der weiß, was er tut, um es zu verwenden.) Ich werde Bewahre dieses Plugin online auf, bis ich es auf WordPress.org veröffentliche. Danach solltest du dort danach suchen.

Um es zu nutzen nehmen Sie einen anderen Ansatz in Ihrem wp-config.phpdiesem normalen durch die vier (4) definiert Auskommen DB_NAME, DB_USER, DB_PASSWORDund DB_HOSTund stattdessen Registrierung die Standardeinstellungen für Webhoster und dann über die einzelnen Webhost Registrierung info selbst. So wp-config.phpkönnte dieses Segment aussehen (beachten Sie, dass im ersten Abschnitt der nicht benötigte Code auskommentiert ist und dass ich meine Hosts-Datei auf meinem lokalen Computer mit nicht routbaren .devTop-Level-Domains eingerichtet habe, um die tägliche Entwicklung zu vereinfachen. Auf dem Mac macht VirtualHostX dies zu einem Kinderspiel):

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');

/** MySQL database username */
//define('DB_USER', 'wp30_anon');

/** MySQL database password */
//define('DB_PASSWORD', '12345');

/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');

require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
 'database'  => 'example_db',
 'user'      => 'example_user',
 'password'  => '12345',
 'host'      => 'localhost',
 'sitepath'  => '',        // '' if WordPress is installed in the root
));
register_webhost('dev',array(
 'name'      => 'Example Local Development',
 'host'      => '127.0.0.1:3306',
 'domain'    => 'example.dev',
 'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
 'name'      => 'Example Test Server',
 'rootdir'   => '/home/example/public_html/test',
 'domain'    => 'test.example.com',
));
register_webhost('stage',array(
 'name'      => 'Example Staging Server',
 'rootdir'   => '/home/example/public_html/stage',
 'domain'    => 'stage.example.com',
));
register_webhost('live',array(
 'name'      => 'Example Live Site',
 'rootdir'   => '/home/example/public_html/',
 'password'  => '%asd59kar12*fr',
 'domain'    => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');

Hoffentlich ist dies (meistens) selbsterklärend. Ich habe versucht , den Code so sauber , wie ich konnte zu machen , aber leider bedarf es diese beide kryptischen require_once()Zeilen vor und nach dem Block des Registrierungscode Webhost , da es keine Möglichkeit gab , für mich „an Haken “ Wordpress vor wp-config.phpgenannt wird.

Sobald Sie Ihr Konto aktualisiert haben, können wp-config.phpSie einfach die URL-Verknüpfung verwenden wp-migrate-webhosts, um wie folgt zum Administratorbildschirm zu gelangen:

http://example.com/wp-migrate-webhosts

Die oben werden Sie zu einem Admin - Bildschirm wie die folgenden nehmen , die ein gutes Stück von Beschreibungstext hat und ermöglicht es Ihnen , die Migration aus einer der anderen Webhost - Domains mit einem einzigen Klick nach den Domänen der Auswahl von (zu migrieren HINWEIS : Dieses Beispiel zeigt , geht aB von Test / Bühne / Live - Server für die lokale Entwicklung , aber seien sie versichert , es wandern kann TO jeder Domäne , in der es zu lokalisierenden passiert. das bedeutet auch das Plugin groß sein wird eine bestehende Live - Website für die Aufnahme und schnell eine lokale Entwicklungsumgebung arbeitet immer! ):

Wenn es nicht klar , „ Migration “ in diesem Zusammenhang alle Verweise in der aktuellen Datenbank zu aktualisieren bedeutet für die aktuell definierten Webhost angemessen zu sein (und „ Strom “ wird schnupperte durch Inspektion $_SERVER['SERVER_NAME'].)

Das Coole an dem Plugin ist, dass es einige grundlegende Migrationen implementiert, aber jeder kann es einbinden und seine eigenen Migrationen durchführen . Wenn Sie beispielsweise ein Galerie-Plugin hinzufügen, das vollständige Pfade zu Bildern in der Datenbank gespeichert hat, können Sie die migrate_webhostsAktion, die vom Webhost und vom Webhost zum Webhost gesendet wird, als Array von Metadaten einbinden Ausführen aller erforderlichen Schritte in der Datenbank mithilfe von SQL oder anderen für die Migration relevanten WordPress-API-Funktionen. Ja, jeder von uns könnte dies ohne das Plugin tun, aber ohne das Plugin stellte ich fest, dass das Schreiben des gesamten benötigten Codes mehr Aufwand war, als es wert war. Mit dem Plugin ist es einfach einfacher, diese winzigen Hooks zu schreiben und hinter sich zu bringen.

Sie können auch feststellen, dass meine Migrationen in Randfällen fehlschlagen, die ich nicht getestet habe, und Sie können mir möglicherweise dabei helfen, das Plugin zu verbessern. Jeder, der möchte, kann mir eine E-Mail über mein Google Mail-Konto senden (mein Alias ​​ist "mikeschinkel").

Außerdem wurde das Plugin entwickelt , benutzer definieren Webhost Metadaten zusätzlich zu denen , zu akzeptieren , sie erkennt , wie database, user, password, host, domainetc. Ein perfektes Beispiel könnte sein , googlemaps_apikeywo Sie eine der verschiedenen API - Schlüssel für jede Domain , die Ihre Google Map Plugin - Anforderungen speichern um korrekt zu funktionieren (wer unter Ihnen, der ein Google Maps-Plugin verwendet hat, hat noch keine App auf einem Live-Server bereitgestellt und hat vergessen, den Code in den richtigen API-Schlüssel zu ändern? Komm schon, sei ehrlich ... :) Mit diesem Plugin Ein googlemaps_apikeyElement in Ihrem register_webhost () -Array und ein kleiner benutzerdefinierter migrate_webhostsHook können Sie effektiv beseitigen!

Nun, das war es auch schon. Ich starte dieses Plugin hier in WordPress Answer's Exchange, weil die Frage von @ Insanity5902 es ausgelöst hat. Lassen Sie mich wissen, ob es hilfreich ist, hier gegebenenfalls oder per E-Mail, wenn nicht.

PS: Wenn Sie sich für diese Option entscheiden, denken Sie daran, dass es sich um eine Alpha / Beta-Version handelt. Dies bedeutet, dass Sie sich auf kleinere Operationen einstellen müssen, wenn Sie sie ab und zu verwenden möchten.

PPS Was sind meine Ziele dabei? Ich liebe es zu sehen, wie dies in den WordPress-Kern migriert wird, damit jeder Zugriff darauf hat. Aber bevor das überhaupt in Betracht gezogen werden kann, müssen viele Menschen daran interessiert sein, es zu verwenden, um sicherzustellen, dass es tatsächlich mehr Probleme löst, als es möglicherweise verursachen könnte. Wenn Ihnen die Idee gefällt, können Sie sie auf jeden Fall nutzen und mir dabei helfen, Schwung für eine mögliche hoffnungsvolle Aufnahme in den WordPress-Kern zu gewinnen.

Wenn möglich, setze ich WP_HOMEund WP_SITEURLin wp-config.php. In Kombination mit einem Datenbank-Dump und -Import ist dies die einfachste aller mir bekannten Lösungen.

http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php

Mein Lieblingshack; Fügen Sie eine Einstellung zu Ihrer hinzu /etc/hosts, damit die Produktionsdomäne nur auf Ihrem Computer auf Ihre Entwicklungsbox verweist. Zur Bereitstellung in der Produktion synchronisieren Sie alle Dateien und verschieben die Datenbank.

Die Risiken dieser Strategie liegen auf der Hand. Sie könnten Ihre Entwicklungsumgebung mit Ihrer Produktionsumgebung verwechseln.

Es ist immer noch eine einfache Lösung.

Ich wollte etwas Ähnliches, als ich vor ein paar Monaten auf WP umgestiegen bin, also habe ich ein ziemlich einfaches Shell-Skript geschrieben, das rsync und mysqldump über ssh verwendet:

http://snarfed.org/sync_wordpress

Es ist nicht anspruchsvoll oder webbasiert, aber ich bin zufrieden damit.

WP Engine ist ein neuer Dienst, der "One-Click-Staging" bietet:

WPEngine hat eine exklusive Funktion namens "Staging". So funktioniert es: Bevor Sie eine beängstigende Änderung an Ihrem Blog vornehmen, klicken Sie auf die Schaltfläche "Snapshot". Wir erstellen eine vollständige Kopie Ihres Blogs und richten sie in einem separaten, sicheren Bereich ein. Sie können mit allem spielen, was Sie wollen. nichts lebt. Erst wenn Sie bereit sind, es in Betrieb zu nehmen, berühren Sie Ihre Hauptwebsite.

Sieht nach einer sehr einfachen Möglichkeit aus, schnell von der Entwicklung zur Produktion zu wechseln, insbesondere bei einer bereits aktiven Site.

Duplicator Plugin: Hier ist ein Plugin, an dem ich gearbeitet habe. Es befindet sich derzeit in der Beta-Phase, erledigt aber für die meisten Websites die Arbeit. Im Moment ist es auf kleinere WordPress-Installationen ausgerichtet. http://wordpress.org/extend/plugins/duplicator/

Ressourcen: Weitere Ressourcen für das Plugin finden Sie hier: http://lifeinthegrid.com/duplicator/

Community: Bitte teilen Sie uns Ihre Erfolge oder Probleme mit! Um die verschiedenen Threads einfacher verwalten zu können, posten Sie Probleme in den WordPress.org-Plugin-Foren. Bitte posten Sie keine Protokolldaten aus dem Plugin in den Online-Foren. Protokolldaten können an unsere Support-Site gesendet werden.

Vielleicht sehen Sie sich ein Produkt von iThemes mit dem Namen BackUpBuddy an . Ich habe es nur zweimal benutzt, hatte jedes Mal ein oder zwei Probleme, aber insgesamt sieht es vielversprechend aus.

Ich persönlich spreche dieses Problem mit meinem Projekt auf Github namens Autopress an . Ich habe noch keine perfekte Lösung, aber ich komme näher, besonders mit dem wpstage-Plugin von den wpengine-Leuten.

Das sieht vielversprechend aus. Wir arbeiten an einigen Skripten, um einige der Daten zu migrieren, wp-Optionen zum Beispiel, Pfade in der Datenbank ändern, ein Kopieren über Medien.

Das Problem, das ich habe, ist, dass die Live-Site weiter wächst, während sich die andere in der Entwicklung befindet. Eine Site, an der wir arbeiten, hat 20 Posts pro Tag und über 3.000 Kommentare pro Tag. Das sind zu viele Daten, um sie mit phpmyadmin oder über die Befehlszeile zu übertragen. Das Verschieben der Daten verursacht aus irgendeinem Grund immer UTF-Probleme.

Auch jetzt, wo es so aussieht, als wären Menüoptionen in der DB gespeichert, habe ich noch mehr zu tun.

Ich checke meinen gesamten Code in SVN ein und stelle den Code per FTP vom Server (Beanstalk) bereit. Dadurch werden jedoch keine Änderungen an der DB vorgenommen oder neue Plugins aktiviert.

Im Moment habe ich vor, eine Manifestdatei zu erstellen, während ich mich entwickle, um alle meine Änderungen an der Live-Site vorzunehmen.

Zum Beispiel würde die Datei lesbare Zeilen haben

Es würde Plugins zum Aktivieren, wp-Optionen zum Bewegen, Bilder zum Bewegen, Seiten zum Bewegen enthalten. Dann würde mein Plugin die Manifest-Datei erkennen und alle Änderungen an der Staging-Site vornehmen.

Sobald ich das getestet hatte und sicher war, dass ich alles bekommen hatte, konnte ich sicher sein, dass es in der Produktion funktionieren würde.

Dieses Plugin ist immer noch eine Idee, aber ich habe einen Code dafür geschrieben.

Wenn Sie nur die URL in Ihrer Datenbank ändern möchten, können Sie auch die folgende SQL verwenden.

Ersetzen Sie einfach $old$mit der alten Domain und $new$mit der neuen

update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;

Zwei Google Summer of Code-Projekte mit einem ähnlichen Ziel:

• Automatische Migration (GSoC 2010)
• WordPress Move ( Vorschlag ) (GSoC 2011)

Ich verwende den Export-Befehl von Subversion, um die WordPress-Dateien (http://core.svn.wordpress.org/tags//) sowie alle Plugins im Repository (http://plugins.svn.wordpress.org//tags) zu installieren //), dann packen Sie einfach das Theme und die benutzerdefinierten Plugins und installieren Sie sie normal. Sobald dies alles ohne Inhalt funktioniert, exportiere ich die Test-DB und suche / ersetze nach der URL UND dem Dateipfad (der für Medien gespeichert ist) und importiere sie in eine leere Datenbank. Dann schalte ich einfach die Datenbankinformationen in wp-config um .php. Im Allgemeinen dauert es ungefähr 10 - 20 Minuten.

Normalerweise logge ich mich bei phpMyadmin ein, lade die Datenbank hoch und bearbeite den Inhalt von wp_options> siteurl und wp_options> home in der erwarteten Domain. Wenn Sie URLs in Ihren Posts und Seiteninhalten aktualisieren müssen, können Sie vor dem Hochladen nach der URL und dem Medien- / Upload-Pfad in der .SQL-Datei suchen / diese ersetzen. Es ist ein schneller Job.

Obwohl es hier nicht an guten Lösungen mangelt, dachte ich im Sinne des Teilens, ich würde mein Bash-Deploy-Skript zum Stapel hinzufügen: https://github.com/jplew/SyncDB

SyncDB ist ein Bash-Bereitstellungsskript, mit dem sich die lokalen und Remote-Versionen einer Wordpress-Site mühelos synchronisieren lassen. Entwickler, die in einer lokalen Umgebung (z. B. MAMP) arbeiten, können Änderungen mit einem einzigen Terminalbefehl schnell auf oder von ihrem Produktionsserver "pushen" oder "ziehen".

Dieses Skript funktioniert gut mit Mark Jaquith der WP-Skelett, und Geschirre mysqldump, gitund rsyncIhre gesamte Website-Datenbank, Code und medien in zwei einfachen Schritten zu synchronisieren:

./syncdb
git push hub master

Ich habe http://wordpress.org/plugins/wp-clone-by-wp-academy/ verwendet . Es funktioniert gut!

Nur 3 Schritte:

1. Installieren Sie das Plugin auf beiden Sites.
2. Verwenden Sie das Plugin, um ein Backup auf der alten Site zu erstellen.
3. Nehmen Sie die Backup-URL, die Sie erhalten, und fügen Sie sie in die Plugin-Seite der neuen Site ein. Dann können Sie loslegen und Ihre Migration ist in wenigen Sekunden abgeschlossen!

Alle URLs werden automatisch angepasst - einschließlich serialisierter Ersetzungen von Zeichenfolgen -, sodass kein Risiko besteht, Widget-Konfigurationen usw. zu verlieren.

Die einzigen Probleme, die ich hatte, waren bei einigen Websites mit größeren Datenbanken (~ 300 MB), die zu Zeitüberschreitungen bei der Ausführung von PHP-Skripten während des Imports der Site-Sicherung führten.

Ab 2017 habe ich zwei Möglichkeiten gefunden, um die Übertragung einer WordPress-Datenbank von der Entwicklung in die Produktion zu bewältigen.

WP Migrate DB Pro / WP Sync DB

https://wordpress.org/plugins/wp-migrate-db/

Mit diesen WordPress-Plugins können Sie Datenbanktabellen zwischen WordPress-Installationen verschieben, abrufen und synchronisieren. Dies ist aus vielen Gründen viel besser als ein Suchen / Ersetzen, weil es:

• Exportiert Ihre Datenbank als MySQL-Daten-Dump (ähnlich wie phpMyAdmin)
• Findet und ersetzt URLs und Dateipfade
• Verarbeitet serialisierte Daten
• Ermöglicht das Speichern auf Ihrem Computer als SQL-Datei

Ich bin ein Fan davon, für meine Arbeit bezahlt zu werden. Ich empfehle Ihnen, Herrn Brad Touesnard zu unterstützen und eine Lizenzkopie des Originals zu kaufen. WP Sync DB ist ein Replikat und bleibt daher immer hinter dem Support zurück. Mit diesem Plugin ist der Prozess denkbar einfach:

1. Installieren / aktivieren Sie das Plugin auf Ihrem lokalen Host und Ihrer Produktionsumgebung
2. Konfigurieren Sie einen Push-Transfer von Ihrem lokalen Host / Entwicklungsserver zu Ihrer Produktion
3. Geben Sie Regeln für die zu übertragenden Tabellen ein und definieren Sie die durchzuführenden Regeln zum Suchen und Ersetzen
4. Das ist es!

Suchen und Ersetzen von Datenbanken für WordPress-Datenbanken mit InterconnectIT

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Dieses kostenlose Tool ist kein Plugin, sondern wird in Ihrem Stammverzeichnis Ihrer WordPress-Produktionsinstallation installiert. Dies ist nicht so gut wie bei WP Migrate DB Pro, da einige manuelle Schritte erforderlich sind, es ist jedoch eine großartige Option, die konsistent funktioniert. Wenn Sie diesen Ansatz verwenden, sieht der Prozess folgendermaßen aus:

1. Sichern Sie Ihre lokale Datenbank. Dies ist unbedingt erforderlich, da wir sie bald wieder importieren werden
2. Fügen Sie das Skript einem Ordner in Ihrem Installationsstammverzeichnis hinzu
3. Führen Sie das Suchen und Ersetzen in Ihrer Datenbank aus
4. Exportieren Sie Ihre Datenbank und speichern Sie sie für Ihre Produktionsumgebung
5. Importieren Sie Ihr Backup erneut aus Schritt 1, um Ihren lokalen Host wiederherzustellen
6. Stellen Sie eine Verbindung zu Ihrer Produktionsdatenbank her und sichern Sie diese (wie immer, bevor Sie diese Dinge tun).
7. Importieren Sie den Export, den wir NACH dem Ausführen der Such- / Ersetzungsroutine aus Schritt 4 durchgeführt haben

Sie können schneller vorgehen, es entstehen jedoch Ausfallzeiten für Ihren Produktionsstandort, die meiner Meinung nach inakzeptabel sind. Deshalb nennen wir es Produktion, oder?

Da ich meine Websites in IIS verwende (ich verwende auch asp.net, daher benötige ich Windows), verwende ich WebPI von MSFT, um eine neue Instanz zu installieren. Anschließend kopiere ich die Vorlage und verwende den Import / Export, um die Daten zu übertragen.

Es ist nicht perfekt, aber das Ganze dauert weniger als eine Stunde.

Natürlich wäre es schön, eine Ein-Klick-Lösung zu haben, aber das fand ich am einfachsten für mich.

Eine weitere kostenpflichtige Lösung: Das Xtreme One- Themenframework hat Version 1.2 mit Xtreme Backup veröffentlicht , mit der Sie "die Einstellungen Ihrer Childthemes, Layouts oder Widgets mit all ihren Einstellungen / Inhalten als XML-Datei exportieren oder importieren können".

Ein Mitarbeiter hat das gefunden. Interessantes Konzept, obwohl es nicht serverübergreifend funktioniert, sieht es so aus. Ich erkunde es immer noch, aber es sieht so aus, als könnte es für eine Inszenierungsinstanz großartig funktionieren

http://code.google.com/p/deploymint/

Dies war möglicherweise nicht der Fall, als Sie die Frage stellten, aber ich habe ein paar Monate lang einen Dienst namens Blogvault verwendet, und dies ist einwandfrei gelungen. Ich habe wahrscheinlich über 50 Migrationen durchgeführt (Domains, Sub-Domains und Web-Hosts überkreuzen), kein Problem und brauche überhaupt keine Zeit.

Es ist ein kostenpflichtiger Dienst (pro Domain / Monat), aber nicht so viel.

RAMP ist ein neues Plugin zur Bereitstellung von Inhalten von Crowd Favourite und sieht wirklich gut aus. Es sind allerdings 250 Dollar, also habe ich es noch nicht ausprobiert. Könnte sich aber in der eingesparten Zeit auszahlen, also überlege ich es mir.

Der große Vorteil, den es gegenüber den meisten anderen erwähnten Methoden hat, ist, dass es Beiträge, Kommentare usw. intelligent zusammenführen kann. Wenn Sie beispielsweise einen Beitrag bereitstellen, werden auch die Tags für diesen Beitrag bereitgestellt, sofern sie noch nicht in der Produktion vorhanden sind.

Lass mich einen meiner Favoriten verraten :-)

// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =  
    in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
              $_SERVER['HTTP_HOST'] == 'local.workblog'          || // call by local name (adjust)
       substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.';           // (mobile) device in local network

$table_prefix  = NULL; // ensure scope

if ( $GLOBALS['is_local'] )  // LOCAL fork ------------------------
{
        ....
}
else  // STAGE/LIVE fork -------------------
{

... und dann arbeiten Sie sich von dort aus vor. DB_NAME, DB_USER ... table_prefix. Persönlich schalte ich ALTERNATE_WP_CRON auf local (um nervige Warnungen zu vermeiden ), WP_DEBUG auf both (wenn Sie kein Entwickler sind) oder auf live-only (wenn Sie es sind), ein anderes ini_set('display_errors', '0');für live könnte auch gut tun, und zuletzt wie oben erwähnt: WP_HOME und WP_SITEURL zur jeweiligen lokalen / aktuellen URL.

Das so ziemlich alles, nichts über den klassischen Wordpress links ‚Das ist alles, Bearbeitung stoppen!‘ Linie...

Der 192.168. Teil können Sie einige lokale Tests (dh von Pads oder Handys) in Ihrem lokalen Netzwerk durchführen)

$ GLOBALS ['is_local'] kann sich auch für die Theme-Entwicklung als nützlich erweisen, um zusätzliche Debug-Ausgaben usw. zu erhalten.

Ich benutze das backupbuddy Plugin jetzt schon eine Weile. Sie können eine Sicherungskopie der Datenbank und aller Dateien erstellen, diese als Zip herunterladen oder direkt per FTP an einen anderen Server senden. Es findet und ersetzt auch die URL für Sie. Normalerweise brauche ich ungefähr 5 Minuten, um den gesamten Prozess durchzuarbeiten. Und da alle Dateien komprimiert sind, ist der Upload- / Download-Vorgang viel schneller. Und nein, ich arbeite nicht für sie, aber dieses Plugin hat diesen ganzen Prozess sehr viel einfacher gemacht.

Ein weiteres nützliches Tool für die Verwaltung von Servermigrationen für Websites ist die WordPress-CLI. Dieser Artikel bietet einen guten Überblick über die Funktionen. Insbesondere der Abschnitt "Suchen und Ersetzen" ist jedoch hilfreich, um alle Verweise auf die alte / dev-Website-URL zu finden :

Erweitertes WordPress-Management mit WP-CLI

Dies ist der einfachste Weg aller Zeiten: https://themes.artbees.net/docs/website-migration/
Es sind nur zwei Klicks erforderlich. Einer zum Exportieren, einer zum Importieren.

Dies ist mit dem All-in-One-WP-Migrations-Plugin möglich. Der obige Link zeigt, wie man es benutzt.

Wenn Sie versuchen, eine kontinuierliche Synchronisierung zu erreichen, empfehle ich, rsync zusammen mit einem benutzerdefinierten Cron-Job zu verwenden, um URLs oder standortspezifische Daten neu zu schreiben.

Nachdem ich diese Antwort eine Weile verfolgt habe, habe ich mein eigenes kleines Plugin erstellt - Pitta Migration . Die Gründe dafür sind:

1. Von allen hier ausprobierten Ideen ist die WP_HOMEund WP_SITEURL-Option die einfachste
2. Ich benutze diese dann, um die zwei übereinstimmenden wp_optionsURLs zu setzen - das deckt ab, wenn Plugins / Themes diese ignorieren
3. Dies gibt mir 100% iges Vertrauen in das, was in meiner Datenbank geändert wird
4. Dies funktioniert auch plattformübergreifend (all diese Bash-Skripte funktionieren unter Windows nicht gut)
5. Es ist leicht zu verstehen, was das Plugin macht
6. Über die beiden Konstanten hinaus gibt es keine Konfiguration. Führen Sie einen mysqldump- und einen mysql-Import in Ihre lokale Datenbank durch, und das Plug-in erkennt, dass sich die Konstante und die Tabelle unterscheiden, und aktualisiert sie entsprechend
7. Kein Suchen und Ersetzen von Text
8. Keine Chance, Ihre Datenbank zu knacken - ich verwende das WordPress-Datenbankobjekt, um zwei Aktualisierungen durchzuführen und nichts weiter
9. Es spielt sich gut mit Dingen wie WordPress Skeleton, wo Sie alles in der Quellcodeverwaltung haben und eine lokale Konfiguration festlegen können
10. Ich habe es in das WordPress-Plugins-Verzeichnis und auf Github gestellt, damit es kostenlos, vollständig OpenSource, einfach zu verteilen und einfach zu installieren ist
11. Sobald es installiert ist, können Sie es vergessen und es sollte 'einfach funktionieren' - es gibt Ihnen einen kleinen Hinweis darauf, dass die Datenbank geändert wurde
12. Es sollte mit jedem Backup / FTP / Restore-Prozess funktionieren

Der einfachste Weg ist meiner Meinung nach die manuelle Übertragung. Kopieren Sie einfach den Ordner wp-content und die Datei wp-config.php auf den neuen Host. Exportieren Sie die Datenbank vom alten Host und importieren Sie sie in eine neue Datenbank des neuen Hosts.

Wechseln Sie in der neuen Host-Datenbank zur wp-Optionstabelle und ändern Sie dort die Site-URL und die Blog-URL in Neue Host-Adresse vom alten Host. wie von http: // localhost / wp zu http://example.com

Jetzt in der wp-config-Datei ändern Sie einfach die Informationen von Datenbank und Benutzer mit neuen Host-Informationen.

Loggen Sie sich jetzt in den neuen wp-admin ein und gehen Sie zu den Einstellungen und speichern Sie den Permalink.

Du bist fertig. Ich denke, das ist einfach, ohne Plugins zu verwenden.

Ich habe verschiedene Arten von Plugins ausprobiert und alle haben viele Arten von Problemen.

Ich bevorzuge diese einfache manuelle Übertragung, die meiner Meinung nach einfacher ist.