Pour chacun des sites WordPress que je développe, j'ai une installation en local sur mon ordinateur.
Cela me permet de développer chaque site directement sur mon Mac, et de ne mettre le site en ligne que lorsque tout est fin prêt.
Quand j'ai une modification à faire (un debug CSS, un ajout de plugin, etc.), je la fais toujours en local d'abord. Ce n'est que lorsque je me suis assurée que cela n'avait eu aucun impact sur le reste du site, que je mets à jour mes fichiers en prod.
Ne jamais modifier les fichiers d'un site directement en production devrait être le deuxième commandement de tout développeur (le premier étant bien sûr : ne jamais faire une mise en prod le vendredi !).
Sur mon Mac, j'ai donc plusieurs sites WordPress installés localement avec MAMP.
J'ai détaillé l'installation d'un WordPress en local dans un billet passé ; aujourd'hui ce qui m'intéresse, c'est de vous expliquer comment restaurer un WordPress en local.
Comment restaurer un WordPress en local ?
Il y a quelques jours, j'ai eu la mauvaise surprise de voir que plusieurs de mes bases de données avaient tout simplement disparu de mon Mac. :roll:
Je ne sais pas qui est le coupable – MAMP ou autre – mais bon, ça ne change rien au problème : les données de mes sites avaient disparu, et je devais les restaurer fissa.
Réinstaller un site WordPress en local depuis un site existant n'est pas difficile : voici les deux méthodes que j'ai déjà eu l'occasion d'utiliser.
Méthode 1 : tout à la mano – plus long, plus sûr
La première méthode consiste à tout sauvegarder et à importer manuellement :
- Copier/coller les fichiers FTP depuis la prod vers votre localhost ;
- Modifier la configuration de WordPress dans le fichier
wp-config.php; - Exporter votre base de données de prod puis l'importer en local ;
- Remplacer toutes les occurrences de l'URL de votre site en prod par l'URL de votre site en local.
C'est manuel donc c'est forcément un tantinet plus long ; néanmoins, c'est aussi plus sûr. Rien ne peut passer aux oubliettes, puisqu'on est en mode « copie conforme ».
Mais WordPress propose déjà, en interne, un outil pour faire la même chose, a priori de façon automatisée et plus rapide.
Méthode 2 : l'export/import de WordPress
La deuxième méthode est donc fournie par WordPress lui-même, et c'est celle-ci que j'ai utilisée pour une fois, pensant que ça irait plus vite.
Dans le tableau de bord de votre site WordPress, sous l'item « Outils » se trouve l'outil « Exporter », qui va générer un fichier XML contenant tout votre site (billets, commentaires, utilisateurs, etc.)
Cela équivaut à peu près au point 3. de la méthode 1, c'est à dire à la sauvegarde de votre base de données. (Sauf qu'en fait, ce type d'export est très souvent incomplet – c'est la raison pour laquelle, en général, j'utilise plutôt la méthode 1, mais je reviendrai là-dessus dans un instant.)
Ensuite, en local, soit vous récupérez les fichiers d'un WordPress tout neuf, soit vous rétablissez les fichiers sauvegardés de votre site en ligne.
Dans les deux cas, installez WordPress comme d'habitude : veillez juste à utiliser le même identifiant de login pour le premier utilisateur que celui de votre site en prod (ça peut se changer ensuite par SQL, mais bon, autant utiliser le bon tout de suite).
À ce stade, vous n'avez en théorie plus qu'à importer l'export XML de prod vers votre site local.
Précautions à prendre avant d'importer un export XML dans WordPress
Avant d'importer votre fichier XML de prod dans votre site local, assurez-vous bien d'avoir pris les précautions suivantes :
- Récupérez tous les plugins actifs sur votre site en prod, et activez-les sur votre site en local ;
- Récupérez les fichiers du thème actif sur votre site en prod (et son éventuel thème parent) et activez-le sur votre site en local ;
- Sur votre site en local, dans le tableau de bord de WordPress, allez dans « Réglages » > « Médias » et copiez les mêmes réglages de médias que ceux de votre site en prod. Il faut absolument le faire avant d'importer votre fichier XML pour que WordPress ne foire pas l'import de vos médias de prod vers votre site local.
Une fois que ces trois étapes sont OK, allez dans « Outils » > « Importer », et importez le fichier XML que vous avez généré plus tôt.
Mappez les utilisateurs de prod sur les utilisateurs en local si besoin ; et surtout, cochez bien la case qui permet de télécharger et d'importer les médias de prod sur votre ordinateur, en local. C'est nécessaire pour que la base de données soit bien à jour avec tous vos médias.
Là, soyez sage et laissez tourner votre bécane tranquillement : en fonction de l'âge de votre site, il se peut qu'il y ait plusieurs années de médias à télécharger. C'est souvent long, donc patientez et faites autre chose en attendant.
Si ça foire, il faudra tout recommencer : méthode radicale certes, mais qui permet d'éviter les doublons et autres ratés !
Une fois que l'import s'est bien déroulé, il vous reste une dernière étape : modifier, dans votre base de données locale, toutes les occurrences de l'URL de prod par l'URL locale.
Sinon, votre WordPress local appellera vos médias depuis la prod, ce qui n'est pas pratique (vous dépendrez d'une connexion Internet pour que votre site s'affiche correctement en local : la plaie, donc).
Moi je me sers toujours des 5 premières requêtes SQL indiquées dans l'article 13 Useful WordPress SQL Queries You Wish You Knew Earlier, à savoir :
- Change siteurl & homeurl
- Change guid
- Change url in content
- Change image path only
- Update post meta
L'export/import de WordPress : une fausse copie conforme
Une fois que tout ça est fait, normalement votre WordPress local est censé être la copie conforme de votre WordPress en prod.
Sauf que ce n'est pas le cas :
- J'ai constaté à plusieurs reprises que les menus configurés dans « Apparence » > « Menus » ne sont pas repris tels quels. Leur contenu est certes bien copié en local, en revanche ils ne sont pas réaffectés aux emplacements du thème. Il faut donc le refaire à la main. :shock:
- Les ID des items de menu ne sont plus forcément les mêmes que ceux de votre site en prod. Cela peut avoir un impact sur l'intégration de votre thème : pour éviter ça, éviter de cibler en CSS les éléments avec des classes comme
.menu-item-1733, mais utilisez plutôt une classe que vous aurez renseigné à la main lors de la configuration de vos menus WordPress. - Les meta propres aux utilisateurs de votre site WordPress de prod ne sont pas forcément repris sur votre WordPress en local. Là encore, vous allez sans doute devoir copier/coller des contenus dans les profils de vos utilisateurs, ou bien, carrément, refaire un export/import des tables
wp_usersetwp_usermetasi quelque chose s'est mal passé.
Bref. Tout cela ne résout pas en soi la disparition de mes bases de données dans MAMP, aussi, avant cette longue restauration WordPress, je me suis aussi payé le luxe de désinstaller MAMP et d'installer la nouvelle version qui, j'espère, sera plus stable ! :idea:
En informatique, shit happens all the time, donc à vous d'être au taquet sur les sauvegardes et sur les processus de restauration pour pouvoir intervenir dès que c'est nécessaire.
Ce billet est moins formel que d'habitude, car je vous avoue l'avoir écrit comme un pense-bête pour mes futurs exports/imports WordPress. J'ai perdu pas mal de temps car justement, je ne me souvenais plus qu'il fallait prendre toutes ces précautions, en particulier sur les médias. Donc, autant que mes observations vous servent aussi !
NB : il existe évidemment d'autres outils et d'autres méthodes que ceux que je présente ici, mais je ne peux parler que de ce que je connais. Si vous avez des conseils, des méthodos ou des outils à me conseiller pour améliorer mes process, n'hésitez pas à m'en parler dans les commentaires. :smile:
Si vous êtes à l'aise avec la ligne de commande (ce qui n'est pas mon cas), on m'a dit du bien de wp-cli, qui simplifie a priori beaucoup ce type d'opération de maintenance.
Moi, je n'utiliserai plus l'outil d'import/export natif de WordPress, car il pose trop de problèmes. Je préfère tout faire à la main : une sauvegarde FTP d'un côté, un dump SQL de l'autre. Comme ça, je suis sûre d'avoir une copie conforme de mon site à un instant T en cas de restauration.
Jetez aussi un œil aux commentaires de ce billet, qui contiennent d'excellents conseils.
4 mai 2014
Très bon article sur une pratique moins courante que la migration local -> FTP !
J'ai eu le même genre de problème il y a quelques jours et j'ai essayé une autre méthode -que j'inventais un peu au fur et à mesure que j'avançais :/ (ceci est réalisé par des professionnels, ne reproduisez pas ce comportement chez vous). En bref la dernière migration que j'ai faite datait de presque 1 an, et j'avais 2 heures top chronos pour tout bouger, du coup j'ai voulu tester la méthode plugin pour l'export de BDD et ma foi j'ai été assez bluffée.
J'ai commencé par télécharger le plugin WP-migrate db sur le site à migrer, et j'ai fait mon export BDD. (Là c'est assez bien foutu car le plugin gère directement les requêtes comme Change siteurl & homeurl).
Là dessus, vu qu'il me restait l'archive de ma version de WP (la 3.8.2), j'ai extrait uniquement wp-admin/ et wp-includes/ et j'ai récupéré le wp-content/ sur mon site à migrer et j'ai tout envoyé sur le ftp.
Là mon nouveau site m'a demandé de mettre à jour la bdd avant de pouvoir me logguer, une fois que je l'ai fait j'ai importé ma bdd et TADAAM !
Tout nikel ! =) Rien à changer : les menus, le slider ds le header, avec toutes les bonnes images.
Enfin bref tout ça pour dire que je m'attendais à pleurer du sang quand j'ai su que j'avais 2 heures et une mémoire vacillante pour faire ça, et tout s'est passé comme sur des roulettes !
Voilà, une méthode rapide et approuvée par moi =)
4 mai 2014
Salut ! Bienvenue par ici, et merci pour ton commentaire :)
Je ne connais pas le plugin dont tu parles, mais si c'est aussi facile que tu le dis, il faudra que je le teste ! Pas que je n'aime pas perdre une demie journée à faire de la maintenance, mais bon.
4 mai 2014
Je trouve que l'outil import/export de WordPress est très utile pour des petits sites ou pour ajouter du contenu dans un site déjà existant (dans le cas d'une refonte par exemple).
S'il y a trop de contenu, le xml sera trop lourd et ne pourra pas être importé (oui, j'ai déjà réussi à dépasser la limite) et s'il y a trop de configurations personnalisées à récupérer, c'est beaucoup plus rapide de récupérer la db au complet.
Ceci dit, ta mésaventure me fait peur pour les petits projets qui n'existent qu'en local sur mon poste, je vais vérifier où MAMP stocke ses données, pour pouvoir récupérer un backup facilement.
4 mai 2014
Salut Mymy, ça me fait plaisir de te recroiser par ici ! Merci pour ton commentaire :)
En effet, avec l'export XML il y a la question du poids - c'est surtout sur les médias que ça a tendance à merdoyer chez moi.
Par ailleurs, le coup de la sauvegarde des bases dans MAMP est une bonne idée. Cela dit, elles ne semblent pas conservées au format sql, mais dans un autre format que je ne connais pas.
Ça m'ennuie un peu de devoir aussi faire des sauvegardes pour un logiciel, alors tant pis, si ça déconne, je réutilise mes sauvegardes de sites.
Mais la prochaine fois, j'utiliserai la méthode 1 pour les restaurer... :-]
5 mai 2014
Salut Marie,
je comprend pas que (presque) personne ne pense à modifier le fichier host (il est dans /dev sur MacOSX)... cela permet d'avoir la même adresse en local et sur le serveur (en modifiant simplement une seule ligne de ce fichier :) ... donc plus la peine de changer les URLs dans la base... c'est bien pratique :)
5 mai 2014
Salut !
En effet, on peut faire ça. :)
Moi je ne le fais pas, car j'ai besoin de pouvoir consulter mes sites sur le web tout en bossant dessus en local. Donc pour éviter toute confusion, je préfère avoir des URLs bien distinctes.
Ceci dit, j'utilise toujours des virtual hosts, ne serait-ce que parce que WordPress n'aime pas trop
localhost, en particulier avec multisite.Merci d'avoir apporté cette précision !
5 mai 2014
Salut Marie,
Pour les projets versionnés, j'utilise git et export/import à la mano de la BDD.
Pour les hébergements mutualisés sans versionning, j'utilise le plugin WordPress Duplicator qui a l'avantage de sauvegarder une copie complète du site (BDD + FTP). Le formulaire d'import en local (ou même en ligne) est très facile d'utilisation.
Je note WP-CLI, j'utilise pas mal drush et c'est vrai que le tout-ligne-de-commande a ses avantages...
5 mai 2014
WordPress Duplicator a l'air très intéressant, je l'essayerai la prochaine fois. Merci ! :)
6 mai 2014
J'ai dû faire un portage d'un WP hier ... quelle galère... c'est étonnant qu'il n'y ai pas un outils simple de copie/colle de BDD avec une fonction UPDATE automatique de l'adresse ... Pourtant ça ne parait pas si compliqué par rapport au travail qu'à fait WordPress jusqu'à présent ...
Pour ceux que ça intéresse la requête SQL :
UPDATE wp_posts SET guid = REPLACE (guid, 'http://www.ancien-site.fr', 'http://www.nouveau-site.fr');
6 mai 2014
Salut Philippe !
Merci pour ton retour d'expérience. La requête SQL dont tu parles est en effet critique, d'ailleurs elle fait partie des requêtes magiques évoquées dans mon billet et que j'utilise quand j'ai besoin de changer l'URL de mon site WordPress en base. Si ça peut aider !
6 mai 2014
Bonjour Marie,
J'ai souvent à faire ce genre de manip dans mes projets et si cela intéresse des gens, voici les outils que j'ai fini par adopter :
- WP-CLI : très bien pour faire de la maintenance et un tas de choses sur WordPress. On travaille en ligne de commande dans une console en se plaçant dans le répertoire racine de son site. Attention cependant, si son WordPress est planté pour x raisons (problème d'accès à la BDD, page blanche ...) WP-CLI peut ne plus être accessible. Donc ne pas compter que sur cette outil pour réparer éventuellement des choses dans la BDD.
Il est possible de mettre des commandes WP-CLI dans un script shell ou autre type de script pour automatiser plusieurs tâches.
Pour plus d'infos : http://wp-cli.org/
- Percona Xtrabackup : c'est un outil mis à disposition gratuitement par la société Percona. Cet outil permet de faire des backups et restauration de BDD MySQL "like" (fonctionne donc aussi pour MariaDB). Percona Xtrabackup ne fait pas un Dump SQL de la base comme le fait la plupart des outils de backup de BDD mais une sauvegarde des bases sous forme de fichiers binaires, en gros ce qui est stocké dans /var/lib/mysql/ (serveur Linux). L'avantage c'est que c'est beaucoup plus rapide et plus sûre à mon avis.
Pour plus d'infos : http://www.percona.com/software/percona-xtrabackup
- DBSR : c'est un script PHP qui permet de faire un "search and replace" dans la BDD. Donc utile pour changer l'URL. Ce script est vraiment très performant, il fonctionne sur les données sérialisées également et gère très bien les caractères accentués. Il parait même qu'il gère correctement les langues un peu exotiques (caractères asiatiques, cyrillique ...) mais je n'ai pas testé ces cas particuliers.
Cet outil fournit une interface graphique mais peut aussi s'utiliser en ligne de commande et donc s'intégrer dans un script.
Pour plus d'infos : https://github.com/DvdGiessen/DBSR/
- Fabric : c'est une librairie en Python qui permet d’exécuter dans un script des lignes de commandes sur des serveurs locaux et/ou distants. Il gère les connexions SSH. J'utilise cet outil pour faire du déploiement en local ou sur serveurs distants mais aussi par exemple pour synchroniser un serveur de test afin qu'il soit identique au serveur de prod (utile pour les tests).
L'avantage de mettre toutes ses commandes dans un script c'est qu'une fois testé, la procédure de déploiement ou de backup/restauration est fiable et automatisée (limite l'erreur humaine). Vous tapez une ligne dans la console et c'est la machine qui travaille. Vous pouvez aller vous faire un chocolat chaud dans la cuisine :)
Pour plus d'infos : http://www.fabfile.org/
Tous ces outils sont très performants et puissants mais demandent de mettre un peu les mains dans le cambouis. Grand débutant s'abstenir. Il ne faut pas se décourager, si vous en avez vraiment besoin, l'investissement en apprentissage vaut le coût.
Merci pour cet article, on aura tous un jour ou l'autre besoin de restaurer ou réparer ses données ;-)
6 mai 2014
Salut Gilles !
Un grand merci pour ce commentaire génial, auquel je sens que je me réfèrerai souvent !
Parmi tous les outils que tu évoques, je n'en connais aucun, donc ça va être l'occasion de « mettre les mains dans le cambouis ».
Encore merci ;-)
6 mai 2014
Commence par WP-CLI et DBSR, ils sont relativement simples à prendre en main par rapport aux deux autres et peuvent être très utils.
WP-CLI permet vraiment de faire plein de choses (maj, installation, désinstallation, activation, desactivation de plugins, themes, maj du core WP, search and replace dans la bdd et pleins d'autres trucs).
DBSR est plus spécifique (search and replace dans bdd) mais très efficace.
++
Gilles
6 mai 2014
Ok, merci pour tes conseils ! Si je bloque sur quelque chose, je saurai à qui demander ! :-P
6 mai 2014
j'ai apprécié ce post sur le transfert vers un serveur distant.
J'ai un site wordpress en local et j'ai une question : comment installer 2 (plusieurs) sites wordpress en local.
je vous remercie par avance et j'espère une réponse rapide... par mail?
6 mai 2014
Bonsoir Chelovek !
Je reprends les questions que tu m'as posées par email, afin que ça puisse servir à d'autres :
WordPress fournit de base une méthode pour gérer plusieurs sites avec une seule installation : cela s'appelle WordPress multisite.
J'ai écrit deux articles à ce sujet : installation de WordPress multisite, et désinstallation de WordPress multisite – ça peut sans doute te donner quelques billes pour commencer.
Dans le cas d'un multisite, tu as un tableau de bord commun qui te sert à administrer le réseau de site, un tableau de bord dédié pour chaque site du réseau, ainsi qu'une seule base de données, dans laquelle les tables sont bien distinctes pour chaque site que tu crées via WordPress.
Le multisite est recommandé s'il y a un administrateur commun à plusieurs sites, même très différents les uns des autres, même n'ayant rien d'autre en commun que leur administrateur (on peut aussi utiliser différentes URLs, en prod, avec un multisite, bien que tout soit hébergé au même endroit).
Sinon, si tu ne veux pas utiliser WordPress multisite, oui il faudra que tu crées autant de dossiers en local que tu veux de site, ce qui donnera autant de bases de données différentes.
C'est ce que je fais, moi :)
7 mai 2014
bonjour,
merci pour tes renseignements très utiles.
c'est très sympathique de ta part.
je suis intéressé par l'installation de deux sites complètement indépendants l'un de l'autre, l'un à côté de l'autre, comme tu l'as fait :
1 /
faut-il installer 2 fois MAMP et 2 dossiers WordPress ou bien 1 seule fois MAMP et 2 dossiers WordPress ?
2 /
comment distinguer les adresses pour s'y rendre : loclahost1 et localhost2, par exemple ?
3/
y a-t-il des détails auxquels je dois faire attention ?
encore merci - très cordialement
PS. ton site est très bien stylé et très utile.
10 mai 2014
Salut !
MAMP est un logiciel, donc il ne s'installe qu'une seule fois sur ta machine (comme tu n'installes qu'une fois Chrome ou OpenOffice).
Si tu ne veux pas utiliser WordPress multisite, oui, il faut installer chaque site dans un dossier spécifique.
Par défaut, si tu as installé ton site 1 dans un dossier intitulé
foo, ton site 1 sera accessible en local par l'URLlocalhost/foo(localhost peut être suffixé par un numéro de port, en fonction de ta configuration).Mais je te recommande d'utiliser des VirtualHosts, pour obtenir les URLs que tu veux. Il suffit pour cela de modifier ton fichier host. Comme le suggère Lipaonline dans son commentaire, tu peux très bien appeler ton virtual host
foo.comsi le site en ligne est accessible depuis cette URL. Moi je ne le fais pas, mais encore une fois chacun peut configurer son environnement de dév comme il le souhaite !Je me sers beaucoup du tutorial Setting Up Virtual Hosts on MAMP pour configurer mes Virtual Hosts.
8 mai 2014
Salut,
On appelle ces fichiers WXR en général. Ils sont assez pratiques en effet mais je préfère nettement une sauvegarde de la base de données.
Je suis d'accord avec toi, la sauvegarde toujours la sauvgarde...
Pour WP-Cli tu peux consulter mon intro si tu veux : http://www.tweetpress.fr/codewp/introduction-wp-cli/
Le souci avec WAMP/MAMP/XAMP c'est que les configurations peuvent différer d'un environnement à l'autre, du coup tu peux avoir de mauvaises surprises avec ton serveur local sur lequel le site tourne bien et en ligne ça peut planter à cause d'une extension apache manquante ou d'une version PHP autre ou encore une autre cause.
La solution est plutôt de cloner son environnement de prod. Par exemple VAGRAM le permet, certains hébergeurs proposent même cette option qu'ils appellent "stagging".
Le transfert des fichiers finaux par FTP reste à proscrire dans la mesure du possible, même sftp.
Je te conseille de coupler avec un github ou un bitbucket privé. Après à toi de voir là où tu es la plus à l'aise.
10 mai 2014
Salut Julien !
Merci pour toutes ces billes. « Cloner son environnement de prod », c'est bête mais je n'y avais pas pensé. Je ne suis pas dév, et ce genre de manip' m'est totalement étrangère !
Quant au Github privé, ok mais ça ne fonctionnera pas pour la BDD, si ?
8 mai 2014
Pour mes imports / exports SQL (un point que tu n'abordes pas dans le détail dans cet article) je passe toujours par un export depuis PHPMyAdmin et un import réalisé à partir d'outils comme Sequel Pro / Cocoa Mysql ou MysqlWorkbench, qui permettent de gérer simplement de gros imports / exports. Il existe bien évidemment la possibilité de faire ça en ligne de commande, mais tant qu'il existe un GUI stable...
Du coup, entre l'import et l'export, j'ouvre le fichier plat avec TextEdit pour faire les remplacements adéquats.
10 mai 2014
Salut Vladkergan !
Merci pour ton commentaire. Je ne connais pas du tout Sequel Pro / Cocoa Mysql ni MysqlWorkbench. En quoi vaut-il mieux utiliser ce genre d'outils plutôt que de faire un import tout bête via PhpMyAdmin ?
23 juillet 2014
Coucou, merci pour ton article... Peux tu m'apporter une petite précision sur :
Car si on le fait pas correctement est ce qu'on est suceptible de ne rien retrouver dans média ? Car nous avons fait une réimportation et j'ai bien l'impression que nous avons omis cette étape surtout au niveau de la "taille"
De ce fait, nous n'avons plus rien dans média, et les galeries wordpress et même portfolio du theme ne fonctionne plus... As tu une idée ?
Merci :)
(Avant notre grande taille était 1100/733 et maintenant 1024x681....)
_
Mélanie
23 juillet 2014
Bonjour Mélanie,
Il m'est impossible de débuguer à distance, mais d'après ce que tu dis, oui, les médias n'ont pas été importés.
Il ne suffit pas de copier/coller manuellement les images dans le dossier
/wp-content/uploads, il faut aussi les importer dans la base de données de WordPress.Ensuite, une fois que tes médias apparaîtront à nouveau dans le Tableau de bord de WordPress, au niveau de l'item « Médias », ce n'est pas pour autant qu'ils s'afficheront dans tes articles ou dans tes pages : en effet, s'ils ont été importés sans les bonnes dimensions, une image fera 1024x681 par exemple, alors que, dans le HTML de ton billet, tu appelles la version 1100x733.
Dans ce cas-là, le plus simple est de recommencer l'importation de zéro. Tu vas te galérer si tu essayes d'importer uniquement les médias.
Mais, avant de recommencer l'importation, il faut veiller à modifier les dimensions des médias dans « Réglages », comme indiqué dans mon billet :)
Bon courage !
23 juillet 2014
Coucou,
Pourtant dans mon autre site, j'ai garder le wp-content/upload avec les images dessus et j'ai réimporter le XML... Et toutes les images même des galerie wordpress et thème sont revenus. Je n'avais pas cocher réimporter les médias. Je ne pense pas avoir changer la config de ce site dans Réglage/média par contre.
Je me souviens plus des réglages médias que nous avions mis avant :( Et chaque image est généré une paire de fois donc va savoir quelle dimension correspond à miniature, moyen et grand.
Merci beaucoup... Car nous avons 8Go de photos (Site de photographe)
23 juillet 2014
Dans la sauvegarde que tu as faite de ton ancien site, il suffit que tu regardes les dernières images que tu avais uploadées dans ton dossier
wp-content/uploads, car WordPress les nomme en fonction des tailles que tu as renseignées dans « Réglages ».Par exemple
mon-image-1100x733.jpg.Cela devrait t'aider à déduire quelles étaient les tailles que tu utilisais.
Sinon, tu peux aussi chercher dans la sauvegarde SQL que tu as faite de ton ancien site.
16 janvier 2015
MIlle mercis pour cet article
Jean - marc Bontemps
Musiques Actuelles
Ile de la Réunion
17 janvier 2015
:))
27 mars 2015
Bonjour Marie,
Mille merci pour ton article. Enfin un billet qui traite ce sens de migration.
Toutefois,j'ai une question. Je sèche toujours a l'etape 23 et 4. Comment remplacer les occurrences url proprement et a quel moment? Tu ne parles pas de modifier les tables Dans wp_options,pourquoi?
En fait,je pose la question car je n'arrive toujours pas a faire fonctionner mes sites en local. J'ai 8888 dans mon url,dois-je le mettre partout aussi?
Merci d'avance pour tes lumières.
David
27 mars 2015
Salut David,
Cette étape est bien évoquée :
Par ailleurs :
Pour chercher et remplacer facilement toutes les occurrences de tes anciennes URLs par les nouvelles, je te recommande le plugin Search and Replace – attention, pense bien à sauvegarder ta base SQL initiale avant de faire un chercher/remplacer.
Faute de quoi, si ça plante, tu ne pourras pas restaurer ton site.
Peut-être un souci d'URL en effet si tu n'as pas remplacé toutes les URLs de prod par les URLs
localhost:8888sur ton installation locale.Il faut bien remplacer tes URLs de prod par
http://localhost:8888lors de l'étape de chercher/remplacer SQL évoqué à l'instant :)Encore une fois : pense à faire des sauvegardes pour pouvoir tout restaurer en cas de souci !