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_metadata
entrée dans le wp_postmeta
tableau.
Si je pirater le wp-admin/includes/image.php
fichier 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_metadata
ligne pour cette pièce jointe. Mais où est ce code qui ne parvient pas à insérer _wp_attachment_metadata
s'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é).
Réponses:
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.
la source
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 ...
la source