Comment: déplacer facilement une installation WordPress du développement à la production?

199

Je développe sur une boîte et utilise une seconde pour la production. À l’heure actuelle, je vole la base de données, puis je cherche à remplacer les modifications d’URL; Copiez ensuite les fichiers et importez le nouveau code SQL.

Y a-t-il de meilleures façons de le faire?

Ryan Gibbons
la source
2
Pour les nouveaux venus à la qeustion. Un an plus tard, j'utilise toujours le plugin @MikeSchinkel. Il a un 0.7 sur lequel j'ai déplacé quelques installations à sans problèmes. mikeschinkel.com/downloads/wp-migrate-webhosts-0.7.zip
Ryan Gibbons
Voici un script sans plug-in que j'ai publié qui a énormément aidé mon processus. philipdowner.com/2012/01/…
Philip Downer
6
Aujourd'hui, il existe un plugin appelé Duplicator: wordpress.org/extend/plugins/duplicator Il s'agit littéralement d'un processus en trois étapes et fonctionne à merveille. Déjà utilisé cela à plusieurs reprises pour déployer un site Web d'un environnement de test vers un site actif.
Matthias

Réponses:

122

@ Insanity5902 : Le déploiement d'un site WordPress d'un boîtier à un autre est un PITA depuis le premier jour où j'ai commencé à travailler avec WordPress. (À vrai dire, c’était un PITA avec Drupal depuis 2 ans avant de commencer avec WordPress, le problème n’est certainement pas exclusivement lié à WordPress.)

Cela me dérangeait que chaque fois que je devais déplacer un site, je devais dépenser tant d'efforts en double, ce qui m'empêchait de me déployer à des tests aussi souvent que je l'aurais souhaité. Donc, il y a environ 4 à 6 mois, j'ai commencé à travailler sur un plugin pour résoudre le problème de migration hébergé sur le Web et j'ai mentionné mes idées sur le forum WP Tavern .

Eh bien, avancez rapidement à ce jour et j’ai pratiquement réussi à le faire et je l’appelle commodément « WP Migrate Webhosts ». Même si le plugin est encore très bêta (probablement même alpha) étant donné votre question, je pense que je suis prêt à laisser les gens commencer à taper dessus.

Le cas d'utilisation envisagé est le suivant:

  1. le développeur gère d'abord le téléchargement de tous les fichiers de thème et de plug-in modifiés via FTP,
  2. télécharge ensuite la base de données de développement MySQL sur le serveur de test dans son intégralité et enfin
  3. exécute ensuite le plug-in pour migrer les références du domaine précédent vers le nouveau. (Mon plug - in ne pas tenter de résoudre la fusion des nouveaux champs de base de données ou des tables avec des données en temps réel, QUE est un problème beaucoup plus que je ne suis pas sûr de savoir comment résoudre.)

Vous pouvez télécharger le plugin sur mon site web et décompresser dans votre répertoire plugins (si vous ne savez pas comment faire cela, alors ce plugin n'est pas pour vous car il nécessite une personne sachant ce qu'elle fait pour l'utiliser.) gardez ce plugin en ligne jusqu'à ce que je le publie sur WordPress.org, après quoi vous devriez le chercher.

Pour l' utiliser , vous prenez une approche différente dans votre wp-config.phpque la normale en commentant les quatre (4) définit DB_NAME, DB_USER, DB_PASSWORDet DB_HOSTau lieu enregistrer les valeurs par défaut pour webhosts et enregistrer des informations sur chaque hébergeur lui - même. Voici à quoi ce segment wp-config.phppourrait ressembler (notez que la première section est le code inutile commenté et que je configure également mon fichier hosts sur ma machine locale avec des .devdomaines de premier niveau non routables pour faciliter le développement quotidien. Sur Mac, VirtualHostX simplifie grandement la tâche :

// ** 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');

J'espère que c'est (principalement) explicite. J'ai essayé de rendre le code aussi propre que possible mais, malheureusement, il faut ces deux require_once()lignes cryptées avant et après le bloc de code d'enregistrement d'hébergeur Web, car je n'avais aucun moyen de " raccrocher " WordPress avant l' wp-config.phpappel.

Une fois que vous avez mis à jour votre, wp-config.phpvous pouvez simplement utiliser le raccourci d'URL wp-migrate-webhostspour accéder à l'écran d'administration de la manière suivante:

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

Ce qui précède vous mènera à un écran d’administrateur comme celui-ci, qui contient un peu de texte de description et vous permet de migrer DE L’ un des autres domaines d’hébergeur Web en un seul clic après avoir sélectionné les domaines à migrer ( REMARQUE : cet exemple montre BAS de test / stade / serveurs en direct au développement local , mais rassurez - vous , il peut migrer à tous les domaines où il se trouve être situé. Cela signifie également le plug - in sera idéal pour prendre un site en direct existant et obtenir rapidement un environnement de développement local de travail! ):

entrez la description de l'image ici

Si ce n'est pas clair, " migration " dans ce contexte signifie mettre à jour toutes les références de la base de données actuelle pour qu'elles soient adaptées à l'hébergeur Web actuellement défini (et " actuel " est détecté par inspection $_SERVER['SERVER_NAME']).

Ce qui est génial avec ce plugin, c'est qu'il implémente des migrations de base, mais tout le monde peut l'accrocher et effectuer ses propres migrations . Par exemple, si vous ajoutez un plug-in de galerie stockant des chemins d'accès complets aux images de la base de données, vous pouvez accrocher l' migrate_webhostsaction qui sera transmise à l' hôte Web " de " et à l' hôte Web à un tableau de métadonnées, ce qui vous permettra de pour effectuer tout ce que vous devez faire dans la base de données à l'aide de SQL ou de toute fonction API WordPress applicable pour effectuer la migration. Oui, aucun de nous ne pourrait le faire sans le plugin, mais sans le plugin, j’ai trouvé qu’écrire tout le code nécessaire demandait plus d’effort qu’il ne valait la peine. Avec le plugin, il est simplement plus facile d'écrire ces petits crochets et d'en finir.

Vous pouvez également constater que mes migrations échouent dans des cas critiques que je n'ai pas encore testés et peut-être pouvez-vous m'aider à améliorer le plug-in? Tous ceux qui le souhaitent peuvent m'envoyer un e-mail via mon compte gmail (mon alias est "mikeschinkel").

En outre, le plug - in a été conçu pour accepter l' utilisateur de définir les métadonnées de webhost en plus de ceux qu'il reconnaît comme database, user, password, host, domainetc. Un exemple parfait peut - être googlemaps_apikeyoù vous pouvez stocker les différentes clés de l' API pour chaque domaine que les besoins du plugin de votre Google Map pour fonctionner correctement (qui parmi vous qui a utilisé un plugin Google Maps n'a pas déployé d'application sur un serveur live et a oublié de changer le code pour la clé API correcte? Allez, soyez honnête ... :) Avec ce plugin, un googlemaps_apikeyélément de votre tableau register_webhost () et un petit migrate_webhostscrochet personnalisé vous permettront de l'éliminer efficacement!

Eh bien c'est à peu près tout. Je lance ce plugin ici sur Exchange WordPress Answer car la question de @ Insanity5902 l'a déclenchée. Faites-moi savoir si c'est utile, ici si approprié ou par email si non.

PS Si vous décidez de l'utiliser, rappelez-vous qu'il s'agit d'alpha / bêta et que cela signifie qu'il va changer. Soyez prêt à subir une petite intervention chirurgicale si vous souhaitez l'utiliser maintenant et utilisez la version publiée une fois qu'elle a été battue par de nombreuses mains.

PPS Quels sont mes objectifs avec cela? J'adore voir cette migration migrer vers le noyau WordPress afin que tout le monde y ait accès. Mais avant que cela puisse même être considéré, de nombreuses personnes doivent être intéressées par son utilisation pour s’assurer qu’il résout réellement plus de problèmes qu’il pourrait potentiellement en créer. Donc, si vous aimez cette idée, alors je vous en prie, utilisez-la et aidez-moi à prendre de l'élan pour l'inclusion éventuelle d'espoir dans le noyau de WordPress.

Mike Schinkel
la source
Des solutions intéressantes J'ai quelques questions à vous poser 1) Avez-vous encore besoin de définir WP_SITEURL pour accéder à la zone d'administration? 2) Est-ce que l'outil affiché ne s'affiche que pour les utilisateurs administrateurs? (pas sûr que la section Outil apparaisse pour les non-administrateurs)
Ryan Gibbons Le
Bonjour @ Insanity5902: 1) Pas besoin de définir WP_SITEURL, le plugin le fait pour vous. En fait, vous le configurez lorsque vous "enregistrez" un "domaine" et un "sitepath" pour un hébergeur. Dans une opération WordPress normale, WP_SITEURL doit être défini dans le code ou dans la base de données pour garantir que personne ne usurpe l'adresse URL et ne fasse des choses néfastes, car une valeur inattendue dans $ _SERVER ['SERVER_NAME']. Le plug-in WP Migrate Websites définit WP_SITEURL indirectement en fonction de $ _SERVER ['SERVER_NAME'], mais UNIQUEMENT si le domaine actuel correspond à l'un des domaines que vous avez défini dans votre fichier wp-config.php, rien d'autre.
MikeSchinkel
2.) Le raccourci d'URL que j'ai mentionné effectue une redirection vers la console d'administration, il est donc réservé aux personnes connectées à l'administrateur. Cependant, je n'ai pas encore de vérifications spécifiques pour les administrateurs. Je n'ai jamais ajouté de fonctionnalités à un plugin, mais je devrai étudier de manière approfondie comment, au cours des prochaines semaines, pouvoir y travailler le mois prochain. Cependant, le plugin n'est pas destructeur; il peut SEULEMENT migrer vers le domaine actuel et le processus est reproductible. Ainsi, même si un non-administrateur arrivait, il ne risquait rien de mal à le faire, du moins pas que je puisse imaginer.
MikeSchinkel
1
/ wp-migrate-webhosts génère un 404 et / wp-admin génère une "erreur lors de l'établissement d'une connexion à une base de données"
Steve
5
Alors, quel est l'état des lieux pour ce plugin? Cela a l'air très attrayant mais j'aimerais quelque chose de mature et bien vérifié. Cet article est la seule information que je peux trouver dessus.
Kevin C.
35

Si possible, je mets WP_HOMEet WP_SITEURLdans wp-config.php. Ceci, combiné à un dump et à une importation de base de données, est la plus simple de toutes les solutions que je connaisse.

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

Annika Backstrom
la source
1
Quand ne serait-il pas possible de les définir? Cela semble un peu plus simple que de changer des choses dans la base de données.
Jfklein
2
@jfklein Je travaille presque toujours avec un réseau WordPress, incompatible avec ces constantes.
Annika Backstrom
1
Faire la même chose. Malheureusement, tous les thèmes ne l’honorent pas. c'est-à-dire 'Thème Repsonsive' de ThemeID. Rechercher dans le dump / toutes les tables pour ' localhost ' (ou le nom local que vous ayez choisi), en particulier wp_options, et effectuer des recherches et remplacer est souvent inévitable.
Frank Nocke
@FranKee J'ai créé un plugin wordpress.org/plugins/pitta-migration qui utilise les constantes pour mettre à jour la table wp_options qui devrait couvrir la plupart des thèmes et des plugins
icc97
@ icc97: charmant. Va le regarder. PS: Belle image d'en-tête, décrit la situation.
Frank Nocke
27

Mon hack préféré; ajoutez un paramètre à votre /etc/hostspour que le domaine de production pointe vers votre zone de développement, uniquement sur votre ordinateur. Pour déployer en production, vous devez synchroniser tous les fichiers et transférer la base de données.

Les risques de cette stratégie sont clairs; vous pouvez confondre votre environnement de développement avec votre environnement de production.

C'est quand même une solution facile.

Wietse Venema
la source
5
Oui! Je suis tellement content que je n'étais pas le seul à y avoir pensé! toute différence entre dev et prod est mauvaise. Supprimer cette différence est bien mieux que d’essayer de la contourner. Et cette configuration ne nécessite aucun travail. On peut même faire des tests sur une machine virtuelle avec un fichier modded hosts si nécessaire.
Alexander Bird
2
J'aime beaucoup cette méthode, mais comment gérez-vous la base de données push / pull?
Nenotlep
En ce qui concerne le risque de confusion entre dev et prod, j’utilise un plugin Chrome qui affiche l’adresse IP de la page Web. Vous saurez que vous êtes sur place quand il sera 127.0.0.1
kosinix
9

Je voulais quelque chose de similaire quand j'ai migré vers WP il y a quelques mois. J'ai donc écrit un script shell assez simple qui utilise rsync et mysqldump sur ssh:

http://snarfed.org/sync_wordpress

Ce n'est pas sophistiqué ou basé sur le Web, mais j'en suis heureux.

Ryan
la source
8

WP Engine est un nouveau service qui offre une "mise en place en un clic":

WPEngine a une fonctionnalité exclusive appelée «staging». Voici comment cela fonctionne: Avant de modifier votre blog de façon effrayante, cliquez sur le bouton «Instantané». Nous faisons une copie complète de votre blog et l'installons dans une zone séparée et sécurisée. Vous pouvez jouer avec tout ce que vous voulez. rien n'est en direct. Lorsque vous êtes prêt à le faire vivre, vous touchez votre site principal.

Cela semble être un moyen très facile de passer rapidement du développement à la production, en particulier avec un site déjà actif.

Travis Northcutt
la source
3
C'est une très bonne option et conviendra à beaucoup de gens! Bien sûr, cela ne fonctionne pas pour les URL incorporées, ni pour les personnes développant localement, leur permettant d'utiliser un IDE avec un débogueur. Maintenant, si WPEngine peut créer une interaction qui fusionne également un déploiement local, ce sera vraiment quelque chose (Technosailor, vous écoutez?)
MikeSchinkel
D'accord, ce serait un ajout fantastique.
Travis Northcutt
La fonction d’instantané ne copie que de la production à la mise en scène, et non l’inverse. C'est bien pour tester les changements, mais cela ne va pas aider pour le déploiement en production.
Sam
2
@sam en fait, ils ont récemment commencé à déployer la possibilité de copier de la mise en scène à la production. wpengine.com/2013/04/user-portal-v2-and-staging-to-production
Travis Northcutt
7

Duplicator Plugin: Voici un plugin sur lequel j'ai travaillé. Il est actuellement en version bêta, mais cela fonctionne pour la plupart des sites. Pour le moment, il est destiné aux installations WordPress plus petites. http://wordpress.org/extend/plugins/duplicator/

Ressources: des ressources supplémentaires pour le plugin peuvent être trouvées ici: http://lifeinthegrid.com/duplicator/

Communauté: Veuillez nous informer de vos succès ou de tout problème que vous pourriez rencontrer! Afin de gérer plus facilement les différentes discussions, veuillez publier des numéros sur les forums du plugin WordPress.org. Veuillez ne publier aucune donnée d'enregistrement du plug-in dans les forums en ligne. Les données de journalisation peuvent être soumises à notre site de support.

Cory
la source
6

Vous pouvez jeter un oeil à un produit de iThemes, appelé BackUpBuddy . Je ne l'ai utilisé que deux fois, à chaque fois avec un accroc ou deux, mais dans l'ensemble, cela semble prometteur.

MikeK
la source
5

Je m'occupe personnellement de cette question avec mon projet sur Github, appelé Autopress . Je n'ai pas encore de solution parfaite, mais je me rapproche, en particulier avec le plugin wpstage des gens de wpengine.

Vid Luther
la source
Vient de vérifier votre script. Agréable. Si j'ai bien compris, il installe un nouveau WP sur le serveur. La question ici est de savoir comment passer du développement à la production. Est-ce que ça peut aider avec ça?
Sruly
17
Est-ce ceci? github.com/vluther/Autopress Je suggère de créer des liens dans vos réponses pour que les gens puissent cliquer!
artlung
4
@ Mike Lee: Oui, vous pouvez voter en amont des commentaires. Voir, j'ai voté le commentaire d'artlung. Recherchez le uparrow en vol stationnaire à gauche du commentaire.
MikeSchinkel
Je travaille sur un moyen de tout garder dans le contrôle de version, puis de passer du développement à la production. J'ai pu le faire sans problème pour quelques sites déjà, mais il reste quelques modifications à régler.
Vid Luther
1
Vous ne savez pas vraiment si c'est le cas, mais un plugin WP Engine est utilisé pour la migration de sites entre hôtes. C'est ce qu'on appelle Snapshot ( lien direct ).
joelhaus
5

Cela semble prometteur. Nous travaillons sur des scripts pour gérer la migration de certaines données, wp-options par exemple, la modification des chemins dans la base de données, la copie sur un support.

Le problème que j’ai, c’est que le site actif continue de croître pendant que l’autre est en développement. Un site sur lequel nous travaillons compte 20 publications par jour et plus de 3 000 commentaires par jour. C'est trop de données à déplacer avec phpmyadmin ou via la ligne de commande. De plus, le déplacement des données provoque toujours des problèmes UTF pour une raison quelconque.

De plus, maintenant qu'il semble que les options de menu soient stockées dans la base de données, j'en ai encore plus à traiter.

Je vérifie tout mon code dans SVN et le déploie via FTP depuis le serveur (Beanstalk). Cela ne modifie cependant pas pour moi la base de données et n'active pas de nouveaux plugins.

Mon plan actuel est de créer un fichier manifeste pendant que je développe toutes mes modifications sur le site actif.

Par exemple, le fichier aurait des lignes lisibles par l'homme

Cela inclurait les plugins à activer, les options-wp à déplacer, les images à déplacer, les pages à déplacer. Ensuite, mon plug-in détecterait le fichier manifeste et apporterait toutes les modifications au site intermédiaire.

Une fois que j'ai testé cela et que j'étais certain d'avoir tout, je pouvais être sûr que cela fonctionnerait en production.

Ce plugin n’est encore qu’une idée, mais j’ai du code écrit pour ça.

En outre, si vous souhaitez modifier uniquement l'URL de votre base de données, vous pouvez utiliser le code SQL suivant.

il suffit de remplacer $old$par l'ancien domaine et $new$par le nouveau

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$') ;
Andrew
la source
2
Juste une note, mon appel SQL peut vous casser des données sérialisées. s: 14: blogs.prod.com a la longueur codée 14. Après avoir exécuté le code, nous avons maintenant s: 14: dev.prod.com qui est corrompu. Devrait être s: 12: dev.prod.com utiliser avec prudence.
Andrew
4

Deux projets Google Summer of Code ayant un objectif similaire:

Jan Fabry
la source
Il ne semble pas que l'un ou l'autre de ces projets ait démarré?
icc97
3

J'utilise la commande d'exportation de subversion pour installer les fichiers WordPress (http://core.svn.wordpress.org/tags//), ainsi que tous les plugins du référentiel (http://plugins.svn.wordpress.org//tags //), puis zippez le thème et les plugins personnalisés et installez-les normalement. Une fois que tout est opérationnel et sans contenu, j'exporte la base de données de test et effectue une recherche / remplacement pour l'URL ET le chemin de fichier (stocké pour le support) et l'importe dans une base de données vide, puis modifie simplement les informations de la base de données dans wp-config. .php. Cela me prend généralement environ 10 à 20 minutes.

John P Bloch
la source
3

Normalement, je me connecte à phpMyadmin pour télécharger la base de données et éditer le contenu de wp_options> siteurl et wp_options> home dans le domaine attendu. Si vous devez mettre à jour les URL dans le contenu de vos publications et de vos pages, vous pouvez rechercher / remplacer l’URL et le chemin des supports / téléchargements dans le fichier .SQL avant le téléchargement. C'est un travail rapide.

Alex Costa
la source
3

Bien que les bonnes solutions ne manquent pas, dans l’esprit de partage, j’ai pensé ajouter mon script bash deploy à la pile: https://github.com/jplew/SyncDB

SyncDB est un script de déploiement bash destiné à simplifier la synchronisation des versions locales et distantes d'un site Wordpress. Il permet aux développeurs travaillant dans un environnement local (par exemple, MAMP) d’appliquer ou d’extraire rapidement les modifications apportées à leur serveur de production avec une seule commande de terminal.

Ce script fonctionne bien avec le squelette WP-Skeleton de Mark Jaquith, et exploite mysqldump, gitet rsyncpour synchroniser votre site entier (base de données, code et média) en deux étapes faciles:

./syncdb
git push hub master
JP Lew
la source
3

J'utilise http://wordpress.org/plugins/wp-clone-by-wp-academy/ . Ça marche bien!

Seulement 3 étapes:

  1. Installez le plugin sur les deux sites.
  2. Utilisez le plug-in pour générer une sauvegarde sur l'ancien site.
  3. Prenez l'URL de sauvegarde qu'il vous donne et insérez-le dans la page du plugin du nouveau site. Cliquez sur Go. La migration est terminée en quelques secondes!

Il ajuste automatiquement toutes les URL - y compris les remplacements de chaînes sérialisés - pour éviter tout risque de perte de configuration de widget, etc.

Les seuls problèmes que j'ai rencontrés concernent certains sites Web dotés de bases de données plus volumineuses (~ 300 Mo), ce qui a provoqué des délais d’exécution des scripts PHP lors de l’importation de la sauvegarde du site.

jmotes
la source
3

Depuis 2017, voici les deux meilleurs moyens que j'ai trouvés pour gérer le transfert d'une base de données WordPress du développement à la production.

WP Migration de la base de données DB Pro / WP Sync

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

Ces plugins WordPress vous permettent de pousser, extraire et synchroniser des tables de base de données entre des installations WordPress. C'est beaucoup mieux qu'une recherche / remplacement pour de nombreuses raisons, car:

  • Exporte votre base de données sous forme de vidage de données MySQL (un peu comme phpMyAdmin)
  • Est-ce qu'une recherche et remplacement sur les URL et les chemins de fichiers
  • Traite les données sérialisées
  • Vous permet de l'enregistrer sur votre ordinateur en tant que fichier SQL

Je suis fan d’être payé pour le travail que je fais, je vous recommande donc de soutenir M. Brad Touesnard et d’acheter une copie de la licence avec les vraies choses. WP Sync DB est une réplique et son support est toujours en retard. Avec ce plugin, le processus est extrêmement simple:

  1. Installez / activez le plugin sur votre environnement de production et localhost
  2. Configurez un transfert push de votre serveur localhost / development vers votre production
  3. Renseignez les règles pour les tables à transférer et définissez les règles de recherche et de remplacement à exécuter
  4. C'est ça!

Recherche et remplacement de base de données pour les bases de données WordPress par InterconnectIT

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

Cet outil gratuit n’est pas un plugin, mais il est installé dans votre répertoire racine de votre installation de production WordPress. Cela n’est pas aussi bon que WP Migrate DB Pro car cela nécessite quelques étapes manuelles, mais c’est quand même une excellente option qui fonctionne de manière constante. Lorsque vous utilisez cette approche, le processus ressemble à ceci:

  1. Sauvegardez votre base de données locale, c'est absolument nécessaire car nous allons la réimporter bientôt
  2. Ajoutez le script à un dossier du répertoire racine de vos installations
  3. Exécuter la recherche et remplacer sur votre base de données
  4. Exportez votre base de données et enregistrez-la pour votre environnement de production
  5. Réimportez votre sauvegarde à partir de l'étape 1 pour restaurer votre localhost
  6. Connectez-vous à votre base de données de production et sauvegardez-la (comme vous le devriez toujours avant de faire ces choses)
  7. Importer l'exportation que nous avons effectuée APRÈS avoir exécuté la routine de recherche / remplacement à partir de l'étape 4

Vous pouvez utiliser une approche plus rapide, mais cela implique des temps d'arrêt pour votre site de production, ce qui est à mon avis inacceptable. C'est pourquoi nous appelons cela la production, non?

Kevin Leary
la source
1

Depuis que je fais tourner mes sites dans IIS (je lance aussi asp.net, donc j'ai besoin de Windows), j'utilise WebPI de Msft pour installer une nouvelle instance, puis je copie le modèle et utilise l'import / export pour transférer les données.

Ce n'est pas parfait, mais le tout prend moins d'une heure.

Évidemment, il serait bien d’avoir une solution en un clic, mais c’est ce que j’ai trouvé le plus facile pour moi.

Sruly
la source
1

Autre solution payante: le framework de thèmes Xtreme One a publié la version 1.2 avec Xtreme Backup qui vous permet "d'exporter ou d'importer les paramètres de vos Childthemes, Layouts ou Widgets avec tous leurs paramètres / contenu sous forme de fichier XML".

Jan Fabry
la source
1

Un collègue a trouvé ceci. Concept intéressant, bien que cela ne fonctionne pas, cela ressemble à un serveur. Je suis toujours en train de l'explorer, mais il semble que cela pourrait fonctionner très bien pour une instance intermédiaire.

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

Ryan Gibbons
la source
Il y a quatre mois, je ne pouvais pas faire fonctionner ce plugin ... Et il est toujours à la version 0.1 de code.google
brasofilo
1

Cela n'était peut-être pas le cas lorsque vous avez posé la question, mais j'utilise un service appelé Blogvault depuis quelques mois et cela s'est parfaitement déroulé. J'ai probablement effectué plus de 50 migrations (traversée de domaines, sous-domaines et hôtes Web), pas un accroc et cela ne prend pas de temps du tout.

C'est un service payant (par domaine / mois), mais pas tant que ça.

Larry
la source
1

RAMP est un nouveau plugin de déploiement de contenu de Crowd Favorite, et il a l'air vraiment lisse. C'est 250 $, cependant, donc je ne l'ai pas encore essayé. Pourriez-vous simplement vous payer le temps gagné, cependant, alors je l’envisage.

Le gros avantage qu'il présente par rapport à la plupart des autres méthodes citées est qu’il peut fusionner intelligemment les publications, les commentaires, etc. Il n’est pas seulement important d’importer un mysqldump, c’est plus un contrôle de source pour la base de données. Par exemple, lors du déploiement d'une publication, les balises de cette publication seront également déployées, si elles n'existent pas déjà en production.

Ian Dunn
la source
RAMP est destiné au déploiement de contenu , par opposition au déploiement de code , mais je conviens qu'il est superbe. Ils ont maintenant une démo de RAMP configurée pour vous permettre d’essayer les fonctionnalités.
Emzo
La question concernait le déploiement de contenu , pas le déploiement de code, et j'ai commencé ma réponse en disant "RAMP est un nouveau plugin de déploiement de contenu ..."
Ian Dunn,
1

Laissez-moi vous donner un de mes favoris :-)

// 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 -------------------
{

... et puis vous travaillez votre chemin à partir de là. DB_NAME, DB_USER ... préfixe de table. Personnellement , j’allume ALTERNATE_WP_CRON sur local (pour éviter certains avertissements gênants ), WP_DEBUG sur les deux (si vous n’êtes pas développeur) ou sur le live uniquement (si vous êtes), un autre ini_set('display_errors', '0');pour le live pourrait aussi faire du bien, enfin, comme mentionné ci-dessus: WP_HOME et WP_SITEURL à l'URL locale / réelle respective.

C'est à peu près tout, il ne reste rien au-dessus du classique WordPress "C'est tout, arrêtez de modifier!" ligne...

Le 192.168. partie vous permet de faire des tests locaux (à partir de pads ou de téléphones) sur votre réseau local)

$ GLOBALS ['is_local'] peut aussi être utile dans le développement de votre thème, pour une sortie de débogage supplémentaire, etc ...

Frank Nocke
la source
1
Vous pouvez utiliser WordPress Skeleton wp-config.php qui définit une WP_LOCAL_DEVconstante pour obtenir quelque chose de similaire
icc97
1

J'utilise le plugin backupbuddy depuis un moment maintenant. Il vous permet de faire une sauvegarde de la base de données et de tous les fichiers, de la télécharger au format zip ou de l’envoyer directement à un autre serveur via FTP. Il fait également l'URL trouver et remplacer pour vous. Il me faut généralement environ 5 minutes pour suivre tout le processus. Et comme tous les fichiers sont compressés, le processus de téléchargement est beaucoup plus rapide. Et non, je ne travaille pas pour eux, mais ce plugin a vraiment rendu ce processus beaucoup plus facile.

Gdaniel
la source
1

Un autre outil utile pour gérer les migrations de serveurs de sites est la CLI de WordPress. Cet article donne une bonne vue d'ensemble de ce qu'il peut faire, mais plus précisément, la section "Rechercher et remplacer" est utile pour trouver toutes les références à l'ancienne URL du site / dev. :

Gestion avancée de WordPress avec WP-CLI

Rick Curran
la source
0

Si vous essayez de réaliser une synchronisation continue, je suggère d'utiliser rsync avec un travail cron personnalisé pour réécrire toute donnée spécifique à une URL ou à un site.

utilisateur92899
la source
0

Après avoir suivi cette réponse pendant un moment, j'ai créé mon propre petit plugin - Pitta Migration . Les raisons étant:

  1. De toutes les idées essayées ici - la plus simple est la WP_HOMEet WP_SITEURLoptions
  2. Je les utilise ensuite pour définir les deux wp_optionsURL correspondantes , ce qui couvre les cas où les plugins / thèmes les ignorent.
  3. Cela me donne 100% confiance dans ce qui change dans ma base de données
  4. Cela fonctionne aussi sur plusieurs plates-formes (tous ces scripts bash ne fonctionnent pas bien sous Windows)
  5. Il est facile de comprendre ce que fait le plugin
  6. Il n'y a pas de configuration au-delà des deux constantes - faites un mysqldump et un import mysql dans votre base de données locale et le plugin verra que la constante et le tableau diffèrent et les met à jour pour les faire correspondre
  7. Aucune recherche et remplacement de texte
  8. Aucune chance de casser votre base de données - J'utilise l'objet WordPress Database Object pour effectuer deux mises à jour et rien de plus
  9. Il joue bien avec des choses comme WordPress Skeleton où vous pouvez tout avoir dans le contrôle de source et définir une configuration locale.
  10. Je l'ai mis dans le répertoire des plugins WordPress et sur Github pour qu'il soit gratuit, entièrement opensource, facile à utiliser et facile à installer.
  11. Une fois installé, vous pouvez l’oublier et cela devrait fonctionner, cela vous donne un petit préavis pour vous informer que la base de données a été modifiée.
  12. Cela devrait fonctionner avec n'importe quel processus de sauvegarde / FTP / restauration
icc97
la source
0

À mon avis, la méthode la plus simple que je suis est le transfert manuel. Copiez simplement le dossier wp-content et le fichier wp-config.php sur le nouvel hôte. Exportez la base de données de l'ancien hôte et importez-la dans une nouvelle base de données du nouvel hôte.

Dans la nouvelle base de données d'hôte, accédez à la table wp-option et modifiez l'URL du site et l'URL du blog en nouvelle adresse d'hôte à partir de l'ancien hôte. comme de http: // localhost / wp à http://example.com

Maintenant, dans le fichier wp-config, il suffit de modifier les informations de la base de données et de l'utilisateur avec les nouvelles informations d'hôte.

Maintenant, connectez-vous à la nouvelle administration wp, accédez aux paramètres et enregistrez le lien permanent.

Vous avez terminé. Je pense que c'est simple sans utiliser de plugins.

J'ai essayé différents types de plugins et tous ont de nombreux problèmes.

Je préfère donc ce simple transfert manuel qui me semble plus facile.

Md. Amanur Rahman
la source