Comment: 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'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! ):

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.

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

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.

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 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.

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.

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.

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.

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$') ;

Deux projets Google Summer of Code ayant un objectif similaire:

• Migration automatique (GSoC 2010)
• WordPress Move ( proposition ) (GSoC 2011)

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.

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.

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

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.

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?

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.

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".

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/

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.

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.

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 ...

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.

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

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.

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.

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

À 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.