Je vis trop dangereusement, il faut vraiment que je me fasse un site local…
J’ai sûrement été imprudent de tester des plugins directement sur mon site en ligne, mais pour l’instant tout va bien. J’ai juste dû désactiver les plugins qui me paraissaient un peu trop envahissants ou sans intérêt pour moi.
En lisant les bons auteurs, je me dis que j’ai eu de la chance de ne pas rencontrer le fameux écran blanc de la mort célèbre chez les développeurs WordPress.
Et comme je veux me lancer dans la « manipulation génétique » du site (utiliser les hooks, modifier le code CSS, etc.), il est prudent que je commence à écouter ceux qui savent : je vais travailler sur un brouillon local plutôt que sur le présent site en ligne. Outre une disparition brutale ou un site devenu tout moche, ça m’évitera de passer trop souvent en mode maintenance avec un panneau indiquant que le site revient tout de suite alors qu’en fait personne n’en sait rien.
Bibliographie
Je cite mes sources avec prudence car comme sur internet tout le monde s’inspire de tout le monde (moi y compris), je risque fort de prendre des copies pour des originaux.
Mais je ne pense pas être dans ce cas en citant cet article de Grégoire Noyelle. Cet article complète un article antérieur (dont il donne le lien). L’ensemble constitue un exposé très complet.
J’ai aussi utilisé cet article de WPMarmite ou encore celui-ci de WPEexplorer.
La méthode
Les articles cités plus haut sont très détaillés, je ne vais pas les copier. Je vais juste faire ressortir la logique de la méthode, en éclairant au passage les détails que je n’étais pas certain d’avoir compris avant d’avoir essayé. Et en reformulant, avec des mots que je comprenne, les concepts qui ne me sont pas encore familiers.
Déjà, un point général : certaines vues d’écran présentées dans les articles ont l’avantage d’être complètes, mais un peu déconcertantes si l’outil que j’utilise est d’une version différente (des cases à renseigner qui manquent, ça je m’en passe, mais cette option nouvelle, qu’est-ce que j’en fais ?). Si je ne trouve pas assez rapidement l’info qui va bien, je conserve le choix par défaut qui a été fait par le concepteur de l’outil. C’est bourrin, mais si ça marche pourquoi chercher à tout comprendre dans le détail ? Et en général c’est le cas, ça marche.
En ligne, j’ai mon site http://www.akilebo.com. Ça veut dire que chez mon hébergeur, il y a quelque part un dossier www.akilebo.com et une base de données que j’ai appelée mabellebase ou n’importe quoi d’autre. Le contenu de mon site WordPress n’est que la réunion des deux.
On va donc récupérer sur le PC la copie du dossier et la copie de la base de données, puis les installer sur un serveur local fonctionnellement similaire à celui de mon hébergeur.
On a alors presque fini, il reste à
- « interconnecter le dossier et la base de données »
- dire au site qu’il a changé d’adresse et qu’il n’est plus sur le web
- et, à propos d’adresse, reconstituer la structure des permaliens mais ça c’est l’affaire d’une minute.
1 – Copie locale du dossier www.akilebo.com
Sur mon PC, j’ai un client SFTP (FileZilla) qui m’a servi à mettre WordPress en ligne.
En entrant le nom du serveur sftp et le mot de passe fournis par mon hébergeur, il me permet, en sens inverse, de récupérer une copie complète du dossier www.akilebo.com.
2 – Copie de la base de données mabellebase
Je me connecte en ligne à l’outil phpMyAdmin accessible depuis mon compte chez l’hébergeur, je clique sur le nom de la base de données mabellebase, puis je choisis l’onglet Exporter.
Cela me permet de télécharger sur mon PC le fichier mabellebase.sql.
3 – Construire mon site local sur un serveur local
Il me faut un serveur local similaire (toutes proportions gardées) à celui de mon hébergeur. Comme je suis sous Windows, j’ai naturellement essayé WAMP (= Windows, Apache, MySQL, PHP). Je ne sais pas si je suis sous-doué, mais à chaque mise à jour de WAMP j’ai des problèmes. Avec XAMPP, aucune question à se poser, ça roule tout seul.
Je dois maintenant faire l’inverse de ce que j’ai fait sur le site en ligne, c’est-à-dire alimenter le serveur local pour qu’il possède le bon dossier et la bonne bases de données.
Comme je suis en local, pas besoin de client SFTP pour copier/coller des fichiers… Donc je place dans le répertoire xampp/htdocs/ la copie du dossier www.akilebo.com que j’ai téléchargé précédemment. Comme mon site sera à usage local, je peux simplifier son nom, je renomme le dossier « www.akilebo.com » en « akilebo » (ou pourquoi pas « akilebo.v3 » ou « zorglub »). Dans ce dossier, il y a le fichier wp-config.php (que je modifierai plus tard pour établir une connexion avec la base de données) ; il est inutile de le sauvegarder avant, puisque je pourrai toujours le retrouver dans le dossier www.akilebo.com.
Il reste à ajouter la base de données. Sous XAMPP, sur la ligne Apache je clique le bouton Start, et sur la ligne MySQL je clique le bouton Start, puis le bouton Admin. Je suis alors dans phpMyAdmin (login = root, PW vide ; comme je suis en local je ne me complique pas la vie).
Là je clique sur l’onglet « Bases de donnée », je renseigne le nom de la base que je veux créer (qui n’a aucune raison d’être « mabellebase » mais qui peut) et je choisis dans la liste Interclassement « utf8_general_ci ».
J’aurais bien choisi « utf8mb64_general-ci » comme je l’avais fait en ligne quand j’ai créé « mabellebase », mais cette option n’est pas proposée. Mon XAMPP n’est pas au niveau de mon hébergement chez Gandi, je savais bien que j’aurais dû prendre WAMP comme tout le monde ;o)
Utf8mb64 est un sur-ensemble de utf8. En choisissant le premier, aucun problème. Par contre, en choisissant le second, on peut ensuite importer des caractères utf8mb64 n’existant pas en utf8 ; en pratique ça ne m’est pas arrivé.
J’ai choisi comme nom « mabase » histoire de dire que ce n’est pas le même nom que la base de données « mabellebase » qui est en ligne, et de vérifier que ça ne pose aucun problème. En appuyant sur le bouton « Créer », c’est fait.
Comme elle est vide, on va la remplir à partir du fichier mabellebase.sql. Toujours dans phpMyAdmin, je sélectionne « mabase » dans l’arborescence présentée dans la colonne de gauche, puis je clique sur l’onglet « Importer ». La page ainsi ouverte comporte un bouton « Parcourir » qui me permet de choisir le fichier à importer, en l’occurrence mabellebase.sql (donc d’un nom différent de celui de la base de données, aucun problème). Il n’y a plus qu’à cliquer sur le bouton « Exécuter ». Attendre tranquillement le message annonçant le succès de l’importation.
Ça peut ne pas marcher si le fichier sql est trop volumineux. Et dans ce cas rien ne se produit en dehors de l’apparition d’un message d’erreur.
Explication à droite du bouton « Parcourir », il est marqué que le taille du fichier ne doit pas dépasser 2 Mo ; donc on est mal si, comme dans mon cas, le fichier fait 14 Mo (et encore, je débute…).
Dans ce cas, rien d’inquiétant : aller dans le répertoire xampp/php/ (ou équivalent avec un autre serveur), sélectionner le fichier php.ini et l’ouvrir avec Notepad++ (ou autre éditeur ASCII, mais Notepad++ est idéal pour éditer du code). Chercher « upload_max_filesize » et au lieu de « = 2M » mettre « = 500M ». Ça va aller tout de suite mieux. Au passage, j’en ai profité pour gonfler « memory_limit » en mettant « = 500M » au lieu de 128M. Et j’ai fait de même pour « post_max_size » en mettant « = 200M » au lieu de 8M.
Le site est maintenant installé (mais pas fini) sur le serveur local.
Je récapitule, pour la suite, les paramètres de ma base de données locale
- Nom : mabase (dans la suite, on écrira DB_NAME = ‘mabase’)
- Interclassement : utf8_general_ci (DB_CHARSET = ‘utf8’)
- Utilisateur : root (DB_USER = ‘root’)
- Mot de passe utilisateur : vide (DB_PASSWORD = »)
alors que sur le site en ligne le PW était plus costaud.. - Nom d’hôte : localhost (DB_HOST = ‘localhost’)
- Préfixe des tables : kb_ ($table_prefix = ‘kb_’)
[le même préfixe que celui de la base de données en ligne pour ne pas se créer un problème ; par défaut ce préfixe est _wp mais je préfère un bigramme rappelant vaguement de quel site il s’agit, ne serait-ce que parce qu’une base de données peut être commune à plusieurs sites WordPress qui devront donc uriliser des bigrammes distincts].
4 – Interconnecter le dossier akilebo et la base de données mabase
Avec ce qu’on a vu précédemment, cette étape était téléphonée. On va dire au dossier akilebo qu’il est rattaché à la base de donnése mabase en mettant à jour le fichier wp-config.php qu’il contient.
Sous Notepad++ (ou autre éditeur ASCII), on ouvre wp-config.php, et on y recherche les paramètres listés ci-dessus, que l’on met à niveau pour ceux qui ont changé par rapport au site en ligne :
- define(‘DB_NAME’, ‘mabase’) –> fait DB_NAME = ‘mabase’ (au lieu de mabellebase)
- define(‘DB_CHARSET ‘, ‘utf8 ‘) –> fait DB_CHARSET = ‘utf8’ au lieu de ‘utf8mb4’ ; dans un cas similaire (ie le site local avec un jeu de caractère utf8 alors que le site en ligne a un jeu de caractères utf8mb4), j’ai néanmoins choisi, sans constater de problème, de laisser en local DB_CHARSET = ‘utf8mb4’
- define(‘DB_USER ‘, ‘root’) –> fait ou laisse DB_USER = ‘root’
- define(‘DB_PASSWORD ‘, ») –> fait DB_PASSWORD = »
- define(‘DB_HOST ‘, ‘localhost’) laisse inchangé DB_HOST = localhost
- $table_prefix = kb_ laisse le préfixe des tables inchangé.
5 – Dire au site qu’il a changé d’adresse et qu’il n’est plus sur le web
Pour accéder au site en ligne, l’adresse à indiquer au navigateur est http://www.akilebo.com
Pour accéder au site local, l’adresse à indiquer au navigateur est http://localhost/akilebo
Si on entre cette dernière adresse (en ayant bien lancé XAMPP au préalable), on accède au site local, mais en essayant de naviguer dans le site on va générer des erreurs 404 (la page n’existe pas). C’est dû au fait que, dans WordPress, les liens vers les pages ou articles ou catégories sont absolus (URL complètes) et non relatifs. Je n’ai pas approfondi la question pour savoir si c’est bien ou pas bien et pourquoi, mais c’est comme ça.
C’est un problème car il faut corriger toutes les adresses, mais un script PHP permet de le résoudre aisément. Il s’agit de Database Search and Replace Script in PHP. Le site du concepteur interconnect/it est très clean, le script est à l’avenant.
Pour l’installer, télécharger le fichier Search-Replace-DB-master.zip depuis le site indiqué ci-dessus, puis le décompacter pour obtenir un dossier Search-Replace-DB-master contenant un fichier index.php plus quelques autres fichiers et un sous-dossier srdb-tests.
Copier ce dossier Search-Replace-DB-master, et le coller dans le dossier akilebo du site local (au même niveau que les dossiers wp-admin, wp-content, etc.).
Entrer dans le navigateur l’adresse suivante : http://localhost/akilebo/Search-Replace-DB-master
Si rien ne se passe, c’est qu’il ne fallait pas éteindre XAMPP…
Une fenêtre s’ouvre, indique les paramètres de la base de données (ceux de wp-config.php) et propose de chercher et remplacer toutes les occurrences d’une adresse par une autre adresse.
On lui dit de chercher partout l’adresse http://www.akilebo.com (sans / à la fin) et de la remplacer par http://localhost/akilebo (sans / à la fin). Le site de Grégoire Noyelle indiqué plus haut explique ça très bien avec vues d’écran et détails du paramétrage.
Deux boutons propose « Dry run » et « Live run ». Le premier lance un essai à blanc (il ne modifie rien et est assez rapide). Le second rejoue la même chose mais en effectuant réellement les modifications, et du coup pédale pendant plus d’une minute (rester cool). Rien de toxique à craindre : on a toujours le fichier mabellebase.sql au cas où quelque chose tournerait mal. Mais même pas, ça fonctionne impeccablement.
Remarque importante : après utilisation du script, cliquer sur le bouton « delete me »
Sur le site local aucun problème. Mais on devine que sur un site en ligne (disons http://www.akilebo.com) laisser un tel script pourrait avoir des effets comiques si quelqu’un de mal intentionné lançait pour voir son navigateur avec l’URL http://www.akilebo.com/Search-Replace-DB-master
Déjà, par réflexe, j’aurais tendance à renommer le dossier du script en « srdb34970 » plutôt que « Search-Replace-DB-master ». Mais en plus, pour les distraits, interconnect/it a prévu, dans la fenêtre, un bouton d’autodestruction « delete me » qui, dans un superbe et émouvant dernier geste, efface totalement le dossier du script et son contenu. Y compris (j’ai vérifié en local) si on a renommé le dossier en « srdb34970 ».
6 – Dernière étape : rétablir les permaliens
Miracle, on peut maintenant afficher le site local http://localhost/akilebo dans le navigateur web.
Comme c’est un clone du site en ligne, le nom et le mot de passe qui permettaient de se logger comme administrateur sur le site en ligne permettent évidemment de faire de même sur le site local.
Cela va nous permettre une dernière petite manip : on se connecte comme administrateur, on choisit « Réglages » puis « Permaliens », et là on clique sur le bouton en bas de la page « Enregistrer les modifications » ce qui reconstruit la table des permaliens (les URL des pages, articles, etc.). Je n’ai pas approfondi l’origine du problème, sa fréquence d’occurrence et ses conséquences exactes, mais comme la manip que je viens de décrire est très simple, il parait de bonne méthode de la faire systématiquement.
Remarque sur la manipulation inverse : installation en ligne de la copie d’un site local.
Je la testerai en mettant en ligne un autre site que je prépare en local, mais les bons auteurs indiquent que c’est exactement le même processus, à ceci près que maintenant la manipulation des fichiers sur le site cible se fait uniquement via le client SFTP. On devra donc, par exemple, modifier le fichier wp-config.php avant d’envoyer tout le dossier en ligne. Mais ça c’est vraiment un détail.
Le seul point qui me préoccupait était de savoir quelle taille de fichier .sql je peux importer depuis le phpMyAdmin de mon hébergement Gandi. Réponse : 128 Mo. Rassuré je suis.
