Commentaire: déplacer facilement une installation WordPress du développement à la production?
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?
@ Insanity5902: Le déploiement d'un site WordPress d'une boîte à une 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 pour effectuer des tests aussi souvent que je l'aurais souhaité. Il y a environ 4 à 6 mois, j'ai donc commencé à travailler sur un plug-in pour résoudre le problème de migration hébergé sur le Web et j'ai mentionné mes idées sur le WP forum 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,
- puis télécharge la base de données de développement MySQL sur le serveur de test dans son intégralité et enfin
- then exécute le plug-in pour migrer les références du domaine précédent vers le nouveau. (Mon plugin tente pas de tenter de résoudre la fusion de nouveaux champs ou tables de base de données avec des données actives; QUE est un problème bien plus important que je ne sais pas comment résoudre. )
Vous pouvez télécharger le plugin à partir de mon site Web et décompresser dans votre répertoire de plugins (si vous ne savez pas comment faire cela, ce plugin n'est pas pour vous car il nécessite une personne qui sait ce qu'ils font pour l'utiliser. ) Je garderai ce plugin en ligne jusqu’à ce que je le publie sur WordPress.org, après quoi vous devriez le chercher là-bas.
Pour l'utiliser, vous adoptez une approche différente dans votre wp-config.php que normale en commentant les quatre (4) définitions DB_NAME, DB_USER, DB_PASSWORD et DB_Host et à la place enregistrement les valeurs par défaut pour les hôtes Web, puis en enregistrant des informations sur chaque hôte Web. . Voici à quoi ce segment de 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 domaines de premier niveau non routables .dev afin de réaliser un développement quotidien Sur le Mac VirtualHostX en fait un jeu d'enfant):
// ** 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 nécessite ces deux lignes require_once() cryptiques avant et après le bloc de code d'enregistrement d'hébergeur Web car il n'y avait aucun moyen pour moi de "accrocher" WordPress avant le 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:
Ce qui précède vous mènera à un écran d'administration comme celui-ci, qui contient un texte descriptif et vous permettra de migrer DE l'un des autres domaines d'hébergement Web en un seul clic après avoir sélectionné les domaines à migrer. from (NOTE: cet exemple montre comment passer de DOWN de serveurs de test/stage/live au développement local, mais soyez assuré qu'il peut migrer À Cela signifie également que le plugin conviendra parfaitement à un site existant et au fonctionnement rapide d'un environnement de développement local!):
S'il n'est pas clair, "migration}" dans ce contexte signifie mettre à jour toutes les références de la base de données actuelle afin qu'elles soient appropriées pour l'hôte Web actuellement défini (et "actuel" est capturé) en inspectant $_SERVER['SERVER_NAME'].)
Ce qui est bien avec ce plugin, c’est qu’il implémente certaines migrations de base mais que tout le monde peut le raccrocher 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 associer l'action migrate_webhosts à laquelle sera transmis l'hôte Web "de" et "à". hébergez chacun un tableau de métadonnées et vous autoriserez 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 Edge 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 les métadonnées d'hôte Web définies par l'utilisateur en plus de celles qu'il reconnaît, telles que database, user, password, Host, domain, etc. Ce qui pourrait être parfait: googlemaps_apikey où vous pouvez stocker les différentes clés d'API pour chaque domaine. que le plug-in de Google Map doit fonctionner correctement (celui d'entre vous qui a utilisé un plug-in Google Maps n'a pas déployé d'application sur un serveur actif et a oublié de modifier le code pour la clé d'API correcte? Allez, soyez honnête ... :) Avec ce plugin, un élément googlemaps_apikey dans votre tableau register_webhost () et un petit crochet personnalisé migrate_webhosts vous permettent effectivement d'éliminer ce problème!
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.
P.S. Si vous décidez de l'utiliser, rappelez-vous qu'il s'agit d'alpha/bêta et que cela signifie qu'il changera. 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.
P.P.S. Quels sont mes objectifs avec cela? J'adore voir cette migration migrer vers le noyau de 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.
Si possible, je mets WP_HOME et WP_SITEURL dans 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
Mon hack préféré; ajoutez un paramètre à votre /etc/hosts pour faire pointer le domaine de production 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.
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.
WP Engine est un nouveau service proposant un "stockage intermédiaire en un clic":
WPEngine possède une fonctionnalité exclusive appelée "mise en scène". 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 ne vit. 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.
Plugin de duplication: 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é: Faites-nous part de vos succès ou de tout autre 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.
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.
Cela semble prometteur. Nous travaillons sur certains 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 en direct 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.
remplacez simplement $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$') ;
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.
Deux projets Google Summer of Code ayant un objectif similaire:
- Migration automatique (GSoC 2010)
- WordPress Move ( proposition ) (GSoC 2011)
Depuis 2017, voici les deux meilleures méthodes que j'ai trouvées pour gérer le transfert d'une base de données WordPress du développement à la production.
WP Migrer la base de données Pro/WP Base de données 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 La base de données Sync est une réplique et son support est toujours en retard. Avec ce plugin, le processus est extrêmement simple:
- Installez/activez le plugin sur votre environnement de production et localhost
- Configurez un transfert Push de votre serveur localhost/development vers votre production
- Renseignez les règles pour les tables à transférer et définissez les règles de recherche et de remplacement à exécuter
- C'est tout!
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. Ce n'est pas aussi bon que WP Migrate DB Pro, car il nécessite quelques étapes manuelles, mais il s'agit néanmoins d'une excellente option qui fonctionne de manière cohérente. Lorsque vous utilisez cette approche, le processus ressemble à ceci:
- Sauvegardez votre base de données locale, c'est absolument nécessaire car nous allons la réimporter bientôt
- Ajoutez le script à un dossier du répertoire racine de vos installations
- Exécuter la recherche et remplacer sur votre base de données
- Exportez votre base de données et enregistrez-la pour votre environnement de production
- Réimportez votre sauvegarde à partir de l'étape 1 pour restaurer votre localhost
- Connectez-vous à votre base de données de production et sauvegardez-la (comme vous le devriez toujours avant de faire ces choses)
- 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?
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) de "pousser" ou de "retirer" rapidement les modifications apportées à leur serveur de production avec une seule commande de terminal.
Ce script fonctionne bien avec WP-Skeleton de Mark Jaquith et exploite mysqldump, git et rsync pour synchroniser l'ensemble de votre site - base de données, code et média - en deux étapes simples:
./syncdb
git Push hub master
J'ai utilisé http://wordpress.org/plugins/wp-clone-by-wp-academy/ . Ça marche bien!
Seulement 3 étapes:
- Installez le plugin sur les deux sites.
- Utilisez le plug-in pour générer une sauvegarde sur l'ancien site.
- Prenez l'URL de sauvegarde qu'il vous donne et insérez-le dans la page du plug-in 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é PHP expiration du délai d'exécution du script lors de l'importation de la sauvegarde du site.
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 //), il suffit ensuite de compresser le thème et les plugins personnalisés et de les installer 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 change simplement les informations de la base de données dans wp-config .php. Cela me prend généralement environ 10 à 20 minutes.
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.
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.
Une autre solution payante: le cadre thématique Xtreme One version 1.2 with Xtreme Backup qui vous permet "exportez ou importez les paramètres de vos Childthemes, Layouts ou Widgets avec tous leurs paramètres/contenu Fichier XML. "
depuis que je lance mes sites dans IIS (je lance aussi asp.net, il me faut donc Windows) J'utilise WebPI de Msft pour installer une nouvelle instance, puis je copie le modèle et utilise l'importation/exportation pour le 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.
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 code 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.
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.
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.
C'est le moyen le plus simple à ce jour: https://themes.artbees.net/docs/website-migration/
Cela ne prend que deux clics. Un pour exporter, un pour importer.
C'est possible en utilisant le plug-in Tout en un WP Migration. Le lien ci-dessus montre comment l'utiliser.
Un autre outil utile pour gérer les migrations de serveurs de sites est la CLI de WordPress. Cet article donne une bonne idée de ce qu’il peut faire, mais la section "Rechercher et remplacer" est particulièrement utile pour trouver toutes les références à l’ancien URL de site/dev. :
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 quelques avertissements gênants ), WP_DEBUG sur les deux (si vous n’êtes pas développeur) ou sur le mode live uniquement (si vous êtes), un autre ini_set('display_errors', '0'); pour live pourrait également le faire. bon, enfin, comme mentionné ci-dessus: WP_HOME et WP_SITEURL à l’URL locale/actuelle respective.
C'est à peu près tout, il ne reste rien au-dessus du classique WordPress "C'est tout, arrêtez de monter!" 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 ...
Après avoir suivi cette réponse pendant un moment, j'ai créé mon propre petit plugin - Pitta Migration . Les raisons étant:
- De toutes les idées essayées ici - la plus simple est les options
WP_HOMEetWP_SITEURL - J'utilise ensuite ceux-ci pour définir les deux URL
wp_optionscorrespondantes - qui couvrent les cas où les plugins/thèmes ignorent ces - Cela me donne 100% confiance dans ce qui change dans ma base de données
- Cela fonctionne aussi sur plusieurs plates-formes (tous ces scripts bash ne fonctionnent pas bien sous Windows)
- Il est facile de comprendre ce que fait le plugin
- 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
- Aucune recherche et remplacement de texte
- 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
- Il joue bien avec des choses comme WordPress Skeleton où vous pouvez tout avoir dans le contrôle de code source et définir une configuration locale.
- Je l'ai mis dans le répertoire des plugins WordPress et sur Github pour que ce soit gratuit, entièrement opensource, facile à utiliser et facile à installer.
- 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.
- Cela devrait fonctionner avec n'importe quel processus de sauvegarde/FTP/restauration
Si vous essayez de réaliser une synchronisation continue, je suggère d'utiliser rsync avec un travail cron personnalisé pour réécrire toutes les données d'URL ou spécifiques à un site.
À 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 remplacez l'URL du site et l'URL du blog par l'adresse du nouvel hôte à partir de l'ancien hôte. comme depuis http: // localhost/wp to 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.