Défoirage intensif de liens d'images dans WordPress5 min read

Presque deux ans après l’apparition de WordPress 2.5 (permettant enfin de gérer «correctement» les images), j’accomplis finalement quelque chose qui me torturait depuis tout ce temps dans ma liste de tâches:

Cliquer sur ce bouton était jouissif. J’ai passé 3,4 heures à faire la réparation/transition ce soir (j’ai pris mon temps pour ne pas faire de gaffes).

Le problème

Avant WordPress 2.5, j’étais forcé de mettre mes images en ligne «à la main». Conséquemment, avec le temps, j’ai accumulé environ 629 images placées manuellement dans «wp-includes/images/». Et comme la syntaxe de mes liens a changé, que mes noms de domaines ont changé (trois fois!) et que wordpress utilise maintenant mod_rewrite pour les liens, j’étais coincé avec des centaines d’images ne s’affichant plus. La question était alors «comment déplacer proprement tous ces fichiers dans le nouveau dossier wp-content/uploads et mettre à jour correctement tous les liens et références dans la base de données?»

Après avoir réfléchi un peu ce soir (ok, je m’ennuyais et je me sentais courageux) et avoir discuté brièvement avec des développeurs sur IRC, j’ai conclu que le moyen le plus efficace serait de faire du “search & replace” dans la base de données. Très peu à l’aise avec cette idée, j’ai toutefois fait mon dump de base de données avec ce plugin.
J’ai alors constaté, à mon grand bonheur, que les fichiers «.sql» s’éditent très bien avec gedit (je le rappelle, je n’y connais rien en bases de données; je m’attendais à me retrouver face à une «boîte noire»). Ouf. gedit étant un de mes meilleurs amis, j’étais maintenant à l’aise avec l’idée de pouvoir expérimenter hors-ligne, sur une copie de ma base de données (astuce de performance: désactiver la coloration syntaxique).

L’analyse

En fouillant le fichier SQL à l’aide de gedit… c’est là qu’on s’amuse à constater que, mes liens, c’était du gros n’importe quoi. En temps normal, on veut des liens dans ce genre:

• /home/jeff/blog/wp-content/uploads/capture.png, ou encore
• https://fortintam.com/blog/wp-content/uploads/capture-1.png

Et pourtant, on en retrouvait de toutes les sortes (qui se faisaient généralement bousiller par mod_rewrite):

• images/nekohayo20041026.jpg
• /home/jeff/blog/images/schrodinger.jpg
• /home/kiddo/blog/images//nekohayo20070701-7.png
• https://fortintam.com/blog/images/nekohayo20080511-13.jpg
• http://kiddo.ecchi.ca/blog/images//capture.png (oui, deux slashs!)
• http://kiddo.ecchi.ca/blog/images/fichiers/oral_logiciels_libres_2006_11_01.avi
• http://kiddo.ecchi.ca/blog/images/nekohayo20050125.jpg

Et, au travers de tout ça, des liens ne devant pas être charcutés par erreur:

• http://kiddo.ecchi.ca/blog/wp-content/plugins/podpress/images/powered_by_podpress.jpg’
• http://jimmac.musichall.cz/images/logo/f-spot-mini.png
• http://wordpress.org/development/wp-includes/images/smilies/icon_smile.gif
• http://www.laptops4me.com/images/pict/LS-WPC11.jpg
• http://www.lateral-thinkers.co.nz/images/partners.microsoft.logo.gif
• http://www.thinkgeek.com/images/products/front/blogging.jpg”

Le verdict

En regardant intensément tout ça, j’en suis venu à déduire le pattern principal sur lequel je me baserais pour faire mes remplacements: puisqu’il faut un truc devant «/images/» (pour éviter de charcuter les liens qui ne sont pas des images internes de mon blog), il faut donc que je cherche pour «/blog/images/». Mais avant ça, il fallait également que je standardise tous les noms de domaines. Meh.

Le traitement/les étapes

Attention les amis, ça va être aride.

1. Backuper la base de données
2. Ouvrir le fichier SQL avec gedit
3. Faire les remplacements suivants, en ordre (pour pouvoir prendre en compte toutes les variétés tordues de syntaxes ci-haut); vous n’avez pas à vous taper la lecture de cette liste, c’est juste pour s’amuser à voir le nombre de remplacements consécutifs que j’ai eu à faire:
   • “nanokron.info” en “ecchi.ca” (31 remplacements)
   • “kiddo.ecchi.ca” en “fortintam.com” (613 remplacements)
   • “nekohayo.ecchi.ca” en “fortintam.com” (11 remplacements)
   • “/home/kiddo/” en “/home/jeff/” (9 remplacements)
   • “images/nekohayo” en “images/” (643 remplacements)
   • “images//nekohayo” en “images/” (3 remplacements)
   • “/blog/images/” en “/blog/wp-content/uploads/” (583 remplacements)
   • ‘src=”images/’ en ‘src=”https://fortintam.com/blog/wp-content/uploads/’ (384 remplacements)
   • ‘href=”images/’ en ‘href=”https://fortintam.com/blog/wp-content/uploads/’ (26 remplacements; oui, WordPress fait vraiment tout en liens absolus maintenant!)
   • ‘value=”images/’ en ‘value=”https://fortintam.com/blog/wp-content/uploads/’ (2 remplacements)
   • ‘src=”wp-content/images/’ en ‘src=”https://fortintam.com/blog/wp-content/uploads/’ (1 remplacement
   • “ecchi.caimages/” en “ecchi.ca/blog/wp-content/uploads/” (3 remplacements)
   • “nekohayo200” en “200” (88 remplacements # pour les titres d’images restants
   • “/wp-content/uploads//” en “/wp-content/uploads/” (9 remplacements; pour une raison X, certaines images avaient deux slashs)
4. À l’aide de phpmyadmin, créer une database «nekohayo-test» pour les besoins de nos tests
5. Modifier les premières lignes du fichier SQL pour pointer vers cette base de données
6. Importer le fichier SQL dans phpmyadmin. Attention, s’assurer que l’encodage correspond; MySQL/phpmyadmin suggère de l’UTF-8 par défaut, mais le dump SQL créé par WordPress était encodé en latin1 (ctrl+F “charset”)
7. Renommer les fichiers «nekohayo200*» en «200*», avec la commande «rename “s/nekohayo200/200/” -v *”»
8. En utilisant le mode de «Vue en liste [arborescente]» de Nautilus, déplacer les images d’un dossier à l’autre, garder la sélection active
9. Modifier la config de wordpress (wp-config.php) pour pointer vers la base de données temporaire
10. Tester si tout est réparé sur le site web (autant les anciennes images que les récentes)
11. Dans la vraie base de données «nekohayo», backuper puis dropper toutes les anciennes tables
12. Importer le fichier SQL dans phpmyadmin, cette fois dans la vraie base de données «nekohayo»
13. Modifier la config de wordpress pour pointer de nouveau vers la base de données «nekohayo»
14. Détruire la base de données «nekohayo-test» après s’être assuré que tout fonctionne

Ouf. Trois heures plus tard, j’ai enfin un blog qui ne renvoie pas des 404 pour rien tout le temps, et je n’ai pas trois dossiers différents où se situent les images.
S’auto-héberger, décidément, c’est du travail acharné pour pas grand chose des fois.