Les images téléchargées ne s'affichent pas dans la médiathèque s'il y a des caractères spéciaux dans les mots-clés IPTC


8

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 recadrées aux tailles définies, il y a 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 en vedette et ils s'affichent correctement sur mon site Web.

J'ai pu trouver la cause du problème: s'il y a des caractères spéciaux (comme les trémas allemands) dans le champ "Mots-clés" IPTC dans les JPG, alors ce problème se produit. Dès que j'utilise Exiftool pour supprimer le champ "Mots clés" d'un JPG qui montre les problèmes mentionnés, ce fichier fonctionne sans aucun 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 des sociétés différentes. La version Wordpress est 4.4.1.

Je suis enclin à signaler cela comme un bug WordPress. Mais avant de le faire, je veux approfondir le vrai problème. Je pourrais trouver que pour toutes les "mauvaises" images, il n'y a pas d' _wp_attachment_metadataentrée dans le wp_postmetatableau.

Si je pirater le wp-admin/includes/image.phpfichier et le jeu $meta['keywords'] = array();en wp_read_image_metadata(), tout fonctionne bien. De toute évidence, il existe quelque part du code qui utilise le résultat de wp_read_image_metadata()pour créer une _wp_attachment_metadataligne pour cette pièce jointe. Mais où est ce code qui ne parvient pas à insérer _wp_attachment_metadatas'il y a un problème avec des chaînes mal encodées $meta['keywords']?

Et existe-t-il un crochet pour contourner ce problème dans mes installations? Une installation WordPress qui montre que le problème est utilisé par plusieurs éditeurs qui ne sont pas très avertis par ordinateur. Leur dire d'utiliser un logiciel sur leur PC pour supprimer les balises IPTC défectueuses est un pas. 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 non. La seule différence est dans le champ "mots-clés", où l'un a le contenu "sucré", l'autre "süß" (= mot allemand pour sucré).

image qui ne fonctionne pas image de travail


Si je me souviens bien, il n'y a pas de codage standard pour les champs IPTC, en fait, cela peut être n'importe quoi, ce qui est assez compliqué. Cependant +1 pour la question. Pouvez-vous fournir un exemple d'image pour vérifier ce comportement?
David

2
Cela me semble être un bug WordPress. Je pense que vous pouvez le signaler tel quel.
MikeNGarrett

Je pense que cela pourrait être corrigé dans WordPress 4.4.2: core.trac.wordpress.org/ticket/35316
JD

2
@ z80crew Êtes-vous en mesure de reproduire ce problème en cours de commentaire ci-dessus? Si c'est le cas, n'hésitez pas à ajouter une réponse et à marquer comme acceptée :)
Tim Malone

Le correctif de bogue de base a-t-il résolu cela? Comme le dit @TimMalone, l'ajout et l'acceptation d'une réponse nous aideraient à garder le WPSE en ordre. Merci.
Andy Macaulay-Brook

Réponses:


2

J'ai testé cela avec une image que j'ai créée moi-même avec Photoshop où j'ai inséré le mot "Süss" dans chaque champ IPTC imaginable.

Je l'ai téléchargé dans mon installation WordPress 4.6, qui n'a aucun plugin de gestion d'image installé. Le téléchargement s'est bien déroulé, les vignettes correctes ont été créées dans le répertoire des téléchargements et le champ de légende a été chargé correctement à partir du champ IPTC correspondant.

De plus, la vignette était affichée correctement dans la bibliothèque multimédia.

Donc, je suis enclin à dire que c'était effectivement un bug qui a été résolu depuis.


0

Le problème semble se produire avec des caractères spéciaux ("â", dans mon cas) dans les noms de fichiers aussi. Cela m'est arrivé au moins et je n'ai jamais modifié les informations exif, donc ce n'est pas seulement 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 les problèmes d'encodage sont souvent rencontrés, je ne trouve aucun article ou document disant que les caractères spéciaux ne sont pas acceptables ou devraient être évités dans les noms de fichiers de la bibliothèque wordpress cependant, vu les nombreux problèmes que les gens ont, il serait conseillé de ne jamais en utiliser ... ou demandez à wordpress de travailler dessus. Peut-être au moins échouez simplement les téléchargements si un spechar est trouvé pour appliquer des noms propres et aucun risque de problème supplémentaire.

J'espère que cela aide quelqu'un. L'encodage de caractères a toujours été un tel gâchis en informatique ... soupir ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.