Cela m’a rendu fou pendant un certain temps. Toutes mes images récentes dans WordPress pouvaient être « écrasées » par WP Smush it, mais toutes celles d’avant 2009 avaient un message d’erreur en vrac. Si vous êtes ici, vous l’avez probablement déjà vu, mais juste pour être sûr que nous sommes tous sur la même longueur d’onde, voici à quoi cela pourrait ressembler :

Essentiellement, il est écrit « Impossible de trouver /home/yaddayadda/public_html/etc. Et dans ce cas, si vous regardez l’emplacement, il passe en fait deux fois – vous verrez la double barre oblique // après le premier « uploads » et il recommence. J’avais fait une petite recherche pour trouver une solution rapide mais je n’avais pas de chance, il était donc temps de commencer à creuser !

La cause (pour moi, en tout cas)

Normalement, les emplacements des images sont stockés dans la base de données WordPress avec leur chemin relatif. Cela signifie quelque chose comme 2006/04/image.png. Lorsque le moment est venu de trouver l’image, WordPress examine votre configuration pour voir où vos images sont stockées (généralement i), et commence à tout assembler pour obtenir le chemin complet final. C’est génial parce que ça rend les choses plus portables.

Malheureusement, lorsque j’ai créé le site WordPress en 2006, pour une raison quelconque, les images que j’ai téléchargées étaient stockées dans la base de données avec leur chemin absolu. Pour ceux qui ne connaissent pas le jargon, absolu signifie dans ce cas quelque chose comme /home/server_account/public_html/i/2006/04/image.png. Comme vous pouvez le deviner, cela peut poser un problème si vous déplacez votre dossier de téléchargement (ou l’installation de WordPress) vers un autre emplacement sur le serveur (ou vers un autre serveur avec un nom de compte différent). Lorsque j’ai transféré vers un autre hôte en 2008, j’ai évidemment dû faire un changement qui a corrigé les choses pour utiliser un chemin relatif, c’est pourquoi tout ce qui a été téléchargé depuis 2009 me convenait parfaitement.

En tout cas, alors que WordPress lui-même peut survivre avec un chemin absolu (tant qu’il est correct), le chemin absolu pose un problème pour WP Smush.it. D’après ce que je peux dire, il bloquera l’emplacement de votre dossier de téléchargement devant le chemin, quoi qu’il arrive. Donc, si vos images étaient stockées dans la base de données avec un chemin absolu, vous vous retrouvez dans un sacré pétrin.

Ok, assez de bavardages. Comment réparer ? !

Juste pour vous avertir, une partie de ce processus consiste à modifier manuellement votre base de données WordPress. Donc si vous n’êtes pas à l’aise pour faire cela, vous pouvez continuer à chercher et espérer que quelqu’un a trouvé une solution plus élégante. Et même si vous êtes à l’aise, *****back up first***** just in case !!!

Je vais maintenant faire une hypothèse – souvenez-vous que j’ai dit que mes images récentes fonctionnaient bien (étant correctement écrasées). Je suppose qu’il en va de même pour vous et que si vous deviez télécharger une nouvelle image maintenant, elle serait bien écrasée. Si ce n’est pas le cas, vous voudrez d’abord régler ce problème.

Étape 1 (après la sauvegarde) – modification de la base de données

A) la voie la plus sûre (mais la plus longue) – l’édition manuelle

J’ai utilisé phpMyAdmin, mais il y a probablement des plugins de base de données WordPress que vous pouvez utiliser si vous n’avez pas accès à phpMyAdmin.

1) Ouvrez votre base de données WordPress et sélectionnez la table « wp_postmeta »
2) Localisez les entrées « _wp_attached_file » que vous avez un problème de smushing, et cliquez sur « Edit« . (ne vous embêtez pas à modifier les entrées « _wp_attachment_metadata » – faire des changements à cet endroit ne fonctionne pas et nous demanderons donc à WordPress de les régénérer plus tard).

cliquez sur l’image ci-dessous pour l’agrandir

Notez que la « meta_value » des 2 premiers (étiquetés « GOOD ») est 2006/03/sitemaps1.gif qui est un chemin relatif. En revanche, celles qui sont étiquetées « BAD » ont un chemin qui commence par /home/ qui est un chemin absolu dont nous ne voulons pas.

ASTUCE : Si vous avez regardé l’image, vous avez probablement remarqué… c’est un peu le bordel. Une chose qui peut être utile est d’avoir un autre navigateur (ou onglet) qui s’ouvre avec votre médiathèque WordPress, et de chercher l’ID de l’URL quand vous passez la souris sur chacune des images problématiques (tant que votre navigateur affiche la barre d’état en bas, vous devriez la voir là). Vous pouvez également passer la souris sur le bouton « Re-smush » – il affichera le même numéro d’identification. Faites correspondre ce numéro avec celui de la colonne « post_id » dans la table de la base de données pour faire correspondre les images à l’entrée de la base de données.

3) Une fois dans la page d’édition, réduisez l’emplacement/le chemin d’accès au fichier. Cliquez sur les images ci-dessous pour un avant et un après.

Si vous avez configuré WordPress pour organiser les téléchargements d’images par année et par mois, il y a de fortes chances que votre résultat final soit identique à la deuxième image, en supprimant tout le contenu jusqu’à et y compris le i/ et en laissant le reste.
N’oubliez pas que vous ne voulez pas de barre oblique.

4) Une fois que vous avez cliqué sur « Go », vous devriez regarder à nouveau le tableau. Et l’entrée que vous venez de modifier devrait être correcte.

CONSEIL : Avant d’éditer la suivante (et la suivante, et la suivante), vous devriez probablement passer à l’étape suivante ci-dessous, juste pour vous assurer que rien ne se dérègle. De plus, il serait dommage d’en éditer une centaine pour découvrir que votre travail n’est pas encore terminé pour une raison quelconque. Occupez-vous de cette image pour l’instant, jusqu’à ce que vous sachiez que tout va bien.

B) la voie rapide et dangereuse

Au lieu de modifier manuellement toutes ces lignes, si vous avez accès à phpMyAdmin et que vous n’avez pas envie de modifier manuellement des dizaines (voire des centaines de lignes selon le nombre d’images que vous avez), il est possible de faire une requête MySQL pour lancer une recherche et un remplacement important.

Notez que je vous recommande fortement de commencer par éditer manuellement au moins une ligne – à défaut d’autre chose, cela vous permettra de comprendre ce que vous faites. Oh, et si vous ne l’avez pas encore fait pour une raison quelconque, assurez-vous que vous avez fait une double sauvegarde. Une requête SQL qui tourne mal peut détruire votre site en un clin d’œil.

Le préliminaire : 

Si vous vous souvenez de notre méthode manuelle ci-dessus, nous changeons essentiellement des choses comme

/home/username/public_html/i/2006/08/image.jpg

 à :

2006/08/image.jpg

Ce /home/username/public_html/i/ est en fait supprimé à plusieurs reprises, une fois pour chaque image. Au lieu de le faire manuellement, pour gagner du temps, nous pouvons dire à MySQL de parcourir la table wp_postmeta et de supprimer chaque instance de /home/username/public_html/i/ qu’il trouve. C’est un peu dangereux car si pour une raison quelconque WordPress ou un autre plugin met cette ligne là pour autre chose et en a besoin là…., elle disparaîtra. J’ai jeté un rapide coup d’oeil et je n’ai rien remarqué qui puisse poser problème, mais pour ce que j’en sais, peut-être que dans la prochaine version de WordPress, il y aura quelque chose de nouveau que cela détruira. Ai-je mentionné que vous devriez d’abord faire marche arrière ?

Commençons.

1) Suivez les instructions du « manuel » ci-dessus jusqu’à ce point :

Vous verrez que j’ai légèrement modifié les instructions. Vous allez sélectionner ceci et le copier dans le presse-papiers avec CTRL-C, ou CMD-C sur le Mac. Ou cliquez sur le bouton droit de la souris pour copier. Ou…. bien disons que si vous ne savez même pas comment copier, je suis très choqué (et pourtant extrêmement impressionné) que vous soyez à l’aise pour modifier une base de données.

Maintenant, collez cette ligne dans un document texte quelque part. Nous devons commencer à assembler la requête SQL.

Le format que nous allons utiliser est le suivant :

UPDATE `table_name` SET `field_name` = replace(same_field_name, 'unwanted_text', 'wanted_text')

Il est peut-être préférable de copier la ligne entière dans un fichier texte plutôt que de la taper. Il y a deux types de guillemets différents utilisés dans la ligne ci-dessus  » ‘ et il est facile d’utiliser accidentellement le mauvais. Nous devons changer ces éléments colorés pour les valeurs appropriées, voici donc ce que nous allons faire.

table_name sera wp_postmeta (si vous avez un préfixe autre que « wp_« , assurez-vous d’utiliser votre préfixe à la place)
field_name va être meta_value (vous pouvez voir dans l’image ci-dessus que c’était le nom du champ que nous étions en train d’éditer)
same_field_name va être aussi meta_value
unwanted_text est la ligne que nous avons copiée avec CTRL-C avant
wanted_text sera supprimé, ne laissant que les 2 citations uniques.

Allez-y et faites ces changements maintenant. Avec les changements en place, vous devriez maintenant avoir quelque chose qui *résemble* à cela :

UPDATE `wp_postmeta` SET `meta_value` = replace(meta_value, '/home/username/public_html/i/', '')

Il y a de fortes chances qu’avec une installation standard, la vôtre soit identique à l’exception de la ligne verte (à moins que votre hébergeur ne vous ait littéralement donné « username » comme nom d’utilisateur et que vous ayez réussi à avoir exactement le même problème de chemin que moi). N’oubliez pas que vous utilisez la ligne avec laquelle vous avez fait un CTRL-C.

Donc maintenant, pour le mettre :

1) Votre base de données étant sélectionnée, choisissez l’onglet SQL en haut.
2) Collez votre ligne UPDATE (s’il y a du texte par défaut, il suffit de le copier par-dessus)
3) Appuyez sur « Go ».

Si vous réussissez, vous serez dirigé vers une page suivante qui vous indiquera le nombre de lignes qui ont été modifiées. Vous pouvez consulter la table wp_postmeta et jeter un coup d’œil rapide pour vous assurer que la modification a été effectuée correctement. Si quelque chose d’assez horrible s’est produit à la place (ou quelque chose de vraiment difficile à réparer… comme si vous aviez manqué une barre oblique et supprimé « upload » au lieu de « upload/ » ), assurez-vous d’avoir cette base de données sauvegardée prête et restaurez-la.

Étape 2 – Sortez de l’éditeur de base de données et installez un plugin.

Malheureusement, il ne suffit pas de modifier la base de données. Nous avons besoin de WordPress pour régénérer les métadonnées des pièces jointes (essentiellement les lignes de la table de la base de données que nous n’avons pas éditées).

Le moyen le plus simple que j’ai trouvé pour faire cela est un plugin appelé « Regenerate Thumbnails« . Pour être honnête, il fait plus que ce dont nous avons besoin, mais j’ai eu du mal à trouver un plugin dont le seul travail était de régénérer les métadonnées. Voici pourquoi cela fonctionne bien pour nous :

1) Il s’installe facilement (vous pouvez l’installer à partir de WordPress), et aucune configuration à modifier.
2) Si vous voulez juste régénérer des vignettes (et des métadonnées) pour des images spécifiques, vous pouvez le faire, et c’est facile.
3) Si vous voulez régénérer les vignettes (et les métadonnées) pour tout, vous pouvez le faire aussi, et c’est facile.

Bien sûr, il y a quelques inconvénients possibles… le plugin va recréer les vignettes en fonction des valeurs actuelles dans Paramètres/Médias (pour les vignettes, petites, moyennes et grandes). Si vous avez modifié les paramètres de taille de l’image à plusieurs reprises dans le passé, faites preuve d’imagination et vous pourrez voir les conséquences involontaires que cela peut avoir. De plus, si un grand nombre de vos images ne peuvent pas être écrasées et que vous prévoyez d’utiliser ce plugin pour régénérer toutes les images à la fois, la charge de votre serveur pourrait monter en flèche jusqu’à ce qu’elle soit complète. Vous voudrez peut-être le faire tôt le matin pour minimiser l’impact sur le trafic web. Soyez très prudent si vous utilisez ce plugin sur un serveur partagé, en particulier si vous avez des milliers d’images.

Vous voudrez peut-être régénérer une image à la fois pour être sûr. Gardez à l’esprit qu’il existe probablement un certain nombre d’autres plugins qui fonctionneraient si vous préférez autre chose – Regenerate Thumbnails est simplement le premier que j’ai trouvé qui semblait répondre à mes besoins.

Je vous suggère fortement de sauvegarder vos images avant de continuer, juste au cas où… Vous pouvez facilement faire une sauvegarde complète de votre site web via cPanel si votre hébergeur l’utilise. Sinon, au minimum, tar ou zip le contenu de votre dossier de téléchargement.

Ok, donc en supposant que vous l’ayez installé et activé le plugin, voici les étapes suivantes :

1) Entrez dans la médiathèque, trouvez l’image que vous avez modifiée dans la base de données et cliquez sur Régénérer les miniatures.

2) En supposant qu’elle se termine sans erreur (cela devrait fonctionner si l’édition de la base de données s’est bien passée), cliquez sur Re-Smush.

Le méchant message « Impossible de trouver » (Could not find) devrait maintenant disparaître, et……

Aaaet….. VOILA !

Si votre essai en image unique a fonctionné, revenez à la première partie et commencez à parcourir les images (vérifiez régulièrement vos messages pour vous assurer que les images sont toujours visibles sans effets secondaires néfastes).

Conclusion

Ok, c’était beaucoup de travail. Mais avec un peu de chance, à la fin, toutes vos images pourront être facilement écrasées. Regardez certains de vos posts pour vous assurer que tout est toujours en ordre et gardez ces sauvegardes à portée de main au cas où vous auriez un problème quelques jours plus tard.

Si vous avez suivi le processus et que vous avez des conseils ou des histoires à partager (de bonnes réussites, espérons-le, mais des histoires d’horreur feront l’affaire aussi), n’hésitez pas à le faire dans la section des commentaires ci-dessous !