@ 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:
- 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,
- télécharge ensuite la base de données de développement MySQL sur le serveur de test dans son intégralité et enfin
- 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.php
que la normale en commentant les quatre (4) définit DB_NAME
, DB_USER
, DB_PASSWORD
et DB_HOST
au 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.php
pourrait 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 .dev
domaines 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.php
appel.
Une fois que vous avez mis à jour votre, wp-config.php
vous pouvez simplement utiliser le raccourci d'URL wp-migrate-webhosts
pour 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! ):

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_webhosts
action 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
, domain
etc. Un exemple parfait peut - être googlemaps_apikey
où 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_webhosts
crochet 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.