Les images téléchargées n'apparaissent pas dans la médiathèque s'il y a des caractères spéciaux dans les mots-clés IPTC
Certaines images téléchargées sur WordPress n'apparaissent pas dans la médiathèque. Les images sont téléchargées et même rognées aux tailles définies. Il existe une entrée dans la médiathèque, mais l'image d'aperçu ne s'affiche pas. Je peux même les utiliser comme image sélectionnée et elles apparaissent correctement sur mon site Web.
J'ai pu trouver la cause du problème: s'il existe des caractères spéciaux (tels que des trémas allemands) dans le champ "Mots-clés" IPTC des fichiers JPG, ce problème se produit. Dès que j'utilise Exiftool pour supprimer le champ "Mots-clés" d'un fichier JPG présentant les problèmes mentionnés, ce fichier fonctionne sans problème. J'ai pu vérifier ce problème sur trois installations WordPress sur deux serveurs Web complètement différents hébergés par différentes sociétés. La version Wordpress est 4.4.1.
Je suis enclin à signaler cela comme un bogue WordPress. Mais avant cela, je veux approfondir le vrai problème. Je pourrais trouver que pour toutes les "mauvaises" images, il n'y a pas d'entrée _wp_attachment_metadata dans la table wp_postmeta.
Si je pirate le fichier wp-admin/includes/image.php et que je règle $meta['keywords'] = array(); dans wp_read_image_metadata(), tout fonctionne correctement. De toute évidence, il existe quelque part un code qui utilise le résultat de wp_read_image_metadata() pour créer une ligne _wp_attachment_metadata pour cette pièce jointe. Mais où est ce code qui n'insère pas _wp_attachment_metadata s'il y a un problème avec des chaînes mal codées dans $meta['keywords']?
Et y a-t-il un crochet pour résoudre ce problème dans mes installations? Une installation WordPress qui montre que ce problème est utilisé par plusieurs éditeurs extrêmement désagréables sur le plan informatique. Leur dire d'utiliser un logiciel sur leur PC pour supprimer les balises IPTC défectueuses est inacceptable. Mais je ne veux pas non plus pirater le fichier principal mentionné sur un système en direct.
Mise à jour: Voici deux images identiques où l'une montre le problème, l'autre pas. La seule différence est dans le champ "mots-clés", où l'un a le contenu "sweet", l'autre "süß" (= mot allemand pour sweet).
J'ai testé cela avec une image que j'ai moi-même créée avec Photoshop dans laquelle j'ai inséré le mot "Süss" dans chaque champ IPTC imaginable.
Je l'ai téléchargé sur mon installation WordPress 4.6, sur laquelle aucun plugin de traitement d'image n'est installé. Le téléchargement s'est bien déroulé, les bonnes vignettes ont été créées dans le répertoire de téléchargement et le champ de légende a été chargé correctement à partir du champ IPTC correspondant.
En outre, la vignette était correctement affichée dans la médiathèque.
Donc, je suis enclin à dire que c'était en fait un bug qui a été résolu depuis.
Le problème semble se produire avec des caractères spéciaux ("â", dans mon cas) dans les noms de fichiers aussi. C'est ce qui m'est arrivé au moins et je n'ai jamais édité d'informations exif, donc ce n'est pas uniquement lié au champ IPTC. Cela fonctionne maintenant comme prévu après la modification du nom de fichier, en supprimant l'accent.
Le plus étrange est que, sachant que des problèmes d'encodage sont souvent rencontrés, je ne peux trouver aucun article ni document expliquant que les caractères spéciaux ne sont pas acceptables ou doivent être évités dans les noms de fichiers de bibliothèques wordpress. Toutefois, vu les nombreux problèmes rencontrés par les utilisateurs, il ... ou demandez à wordpress de travailler dessus. Peut-être au moins échouons-nous tout simplement si un spéchar est appliqué pour imposer des noms propres et aucun risque de problème supplémentaire.
J'espère que ça aide quelqu'un. L'encodage des caractères a toujours été un tel désastre en informatique ... soupir ...