Distinguer une bibliothèque vide d’images qui ne s’affichent pas
Vous ouvrez Médias et la bibliothèque semble vide, le chargement tourne sans fin ou des cases grises remplacent les photos. Pourtant, certaines images apparaissent encore sur le site. Le premier objectif est de déterminer ce qui manque : les résultats affichés, les fiches des médias ou les fichiers nécessaires à leurs aperçus.
Une fiche de média est un enregistrement dans WordPress, avec un titre, un identifiant et des informations sur le fichier. Une vignette est une petite version utilisée pour l’affichage. La fiche peut exister alors que cette variante ne se charge plus. À l’inverse, un fichier peut rester présent sur l’hébergement sans fiche correspondante dans la bibliothèque.
Ce guide traite la consultation de médias déjà attendus. Si un nouvel envoi annonce un format interdit, une taille excessive, une erreur de traitement ou d’écriture sur le disque, relevez ce message : il demande un diagnostic d’importation distinct. Répéter les envois ne réparera pas nécessairement l’affichage des anciens médias.
Préparer une comparaison sans modifier les originaux
Enregistrez ou copiez hors de WordPress tout texte encore en cours de rédaction. Notez le nom d’une image attendue, une page qui l’utilise et la dernière date où la bibliothèque fonctionnait. Gardez également le détail d’une migration, d’une mise à jour ou d’un changement de stockage récent.
Relevez la version de WordPress et le type d’environnement. Sur WordPress.com, certains accès techniques dépendent de l’offre ; utilisez l’assistance lorsque les fichiers ou les journaux ne sont pas accessibles. Dans un réseau multisite, vérifiez le site choisi dans l’administration : chaque site ne présente pas nécessairement les médias de ses voisins.
N’effacez aucune case vide. Elle peut correspondre à une image utilisée. Les premières comparaisons se font sans supprimer de fichier, changer les permissions ni restaurer une sauvegarde. Avant une correction des données ou des fichiers, conservez une sauvegarde adaptée et faites préciser le retour arrière.
Choisir entre les trois approches
Commencez par la première approche pour tout écran vide : elle retire les restrictions d’affichage et compare les vues disponibles. Un filtre oublié se corrige immédiatement, sans intervention sur l’hébergement.
La deuxième approche convient si la liste fonctionne mais pas la grille, si le sélecteur d’un article reste vide ou si le chargement tourne indéfiniment. Il faut observer la demande de médias envoyée par l’écran, puis la réponse reçue.
La troisième devient prioritaire lorsque les fiches sont présentes mais leurs images cassées, ou lorsque les deux vues restent vides après une migration. Elle distingue l’adresse demandée, le fichier réellement disponible et les données qui inscrivent ce média dans WordPress. Ne lancez pas les trois parcours comme une série de réparations obligatoires.
Approche 1 : remettre les filtres à zéro
Depuis l’administration, ouvrez Médias puis Bibliothèque. Effacez entièrement la recherche. Choisissez Tous les médias et Toutes les dates, ou leurs équivalents dans votre interface. En vue liste, appliquez les filtres avec le bouton prévu et revenez à la première page des résultats.
Si une extension ajoute des dossiers, des catégories ou un filtre d’auteur, retirez aussi cette sélection depuis son interface. Notez sa valeur avant de la changer pour pouvoir la remettre ensuite. Un dossier virtuel sélectionné ne prouve pas que le fichier a été déplacé sur le serveur.
Vérifiez notamment que vous n’affichez pas uniquement les médias associés au document ouvert ou les éléments non attachés. La notion de média attaché décrit une association dans WordPress ; elle ne constitue pas un inventaire de tous les endroits où une image est utilisée.
Lorsque les médias réapparaissent, recherchez votre fichier témoin par un élément simple de son nom. Vous avez corrigé un affichage limité. Si les résultats restent vides sans filtre, poursuivez avec les vues grille et liste.
Comparer la grille, la liste et les pages suivantes
Utilisez les icônes de vue placées au-dessus de la bibliothèque. Dans la liste, cherchez les titres et les lignes, même si leurs petites images sont cassées. Des lignes présentes montrent que cet écran retrouve des fiches ; elles ne garantissent pas que les fichiers correspondants sont lisibles.
Si la liste fonctionne alors que la grille reste en chargement, conservez provisoirement la liste pour consulter les détails. Passez à l’approche suivante pour comprendre le chargement de la grille. Ce contraste ne suffit pas à désigner une extension précise comme responsable.
Ne confondez pas non plus la première série d’images et la bibliothèque entière. En liste, parcourez les pages. Depuis WordPress 7.1, la grille utilise par défaut le défilement infini, avec une préférence personnelle permettant de le désactiver dans le profil. Les versions et réglages antérieurs peuvent présenter un autre mécanisme de chargement.
Si seules les images suivantes ne viennent pas, notez cette limite. Une recherche directe du fichier et la pagination de la liste permettent de vérifier s’il existe sans charger toute la photothèque.
Comparer l’administration et le sélecteur de l’éditeur
Ouvrez ensuite un brouillon de contrôle, sans publier. Dans un bloc Image, choisissez la médiathèque et cherchez le même fichier. N’effectuez pas un nouvel envoi pour cette comparaison. Si vous utilisez un constructeur de pages ou une fiche produit, notez précisément le sélecteur concerné.
Une bibliothèque normale dans Médias et vide dans un seul sélecteur oriente vers ce parcours d’édition, ses filtres ou ses requêtes. Vous pouvez continuer à relever les informations depuis la bibliothèque principale, mais ne concluez pas que l’enregistrement d’une page utilisant cette image fonctionnera.
Si seul votre compte rencontre le problème, demandez à une personne déjà autorisée de comparer le même écran. Des règles d’accès peuvent limiter la consultation. Ne partagez pas de mot de passe et ne donnez pas le rôle Administrateur uniquement pour essayer. Un administrateur doit examiner la restriction réelle avant de la modifier.
Approche 2 : repartir d’une session utilisable
Après avoir préservé le travail ouvert, reconnectez-vous par l’adresse habituelle de l’administration. Rouvrez la bibliothèque depuis son menu, sans reprendre un ancien onglet resté ouvert depuis plusieurs jours. Comparez le même fichier et la même vue. Une session renouvelée peut corriger une demande dont l’authentification n’est plus valable.
Essayez ensuite un autre profil de navigateur à jour, sans extension supplémentaire, avec le même compte. Une fenêtre privée n’exclut pas forcément toutes les extensions. Si le résultat change, comparez les réglages du navigateur avant de toucher au serveur.
Cette méthode ne demande ni suppression de tous vos cookies ni désactivation générale de la sécurité. Si vous changez un réglage ciblé pour ce site, notez sa valeur et rétablissez-la après un essai sans amélioration. Quand plusieurs navigateurs et utilisateurs rencontrent la même panne, relevez la requête en échec plutôt que de répéter les reconnexions.
Observer la demande de médias qui échoue
Dans Chrome, ouvrez les outils de développement depuis le menu du navigateur, puis Réseau. Laissez cet outil ouvert et rechargez seulement l’écran Médias. Pour un sélecteur, ouvrez-le à nouveau après avoir sécurisé votre brouillon. Cherchez les requêtes apparues au moment du chargement ; le filtre Fetch/XHR aide à repérer les échanges de données.
La grille classique utilise notamment admin-ajax.php avec l’action query-attachments. D’autres parcours d’éditeur utilisent l’API REST, une interface de communication dont les routes médias comprennent /wp/v2/media. Ne supposez pas que tous les écrans emploient la même route : observez celle réellement demandée.
Sélectionnez la requête et relevez son heure, son statut et son adresse. Consultez Aperçu ou Réponse pour distinguer une liste de médias d’une page de connexion ou d’un message de blocage. Ne modifiez pas la requête et ne collez aucun script dans la console. Des captures nettoyées suffisent pour transmettre le constat au support.
Interpréter la réponse sans confondre code et cause
Un statut 401 ou une redirection vers la connexion invite à vérifier l’authentification. Un 403 indique un refus : droits du compte, protection de la requête ou règle du pare-feu doivent être examinés. Ce code ne démontre pas un défaut de permission du dossier des images.
Un 404 sur la route de consultation demande de vérifier cette route et les adresses. Il ne signifie pas que toutes les photos ont disparu. Une erreur 500 ou 503 nécessite les journaux du serveur à l’heure relevée. Évitez de conclure immédiatement à un manque de mémoire.
Même avec un statut 200, examinez la réponse : une page HTML, un message PHP ou une erreur applicative ne remplace pas les données structurées attendues. Une réponse valide mais vide demande de reprendre filtres, contexte du compte et présence des fiches.
Ouvrir manuellement une adresse REST dans un nouvel onglet ne reproduit pas forcément la demande authentifiée de l’éditeur. Celle-ci peut inclure un jeton de validation, appelé nonce, et des paramètres absents de votre essai. Appuyez le diagnostic sur l’échange observé, sans diffuser cookies ni jetons.
Corriger seulement le composant identifié
Avec ces éléments, demandez au responsable du site de rapprocher la requête des journaux et des changements récents. Une règle de sécurité déclenchée doit être corrigée pour l’appel légitime concerné, pas désactivée pour toute l’administration. Une réponse mise en cache à tort demande de corriger cette règle de cache.
Si un composant est suspect, comparez son activation sur une copie isolée disposant de ses propres données. Neutralisez les envois, paiements et autres effets externes. Notez son réglage initial, changez un seul élément, reprenez la même consultation puis rétablissez-le si l’essai ne résout rien.
Après correction, vérifiez grille, liste et sélecteur. Une nouvelle extension de médiathèque peut modifier l’écran sans résoudre la requête défectueuse. Gardez le diagnostic centré sur le chargement existant. Si les fiches reviennent mais que leurs images restent cassées, poursuivez vers l’accès aux fichiers.
Approche 3 : comparer l’adresse du fichier et celle de la vignette
Depuis la liste, ouvrez la fiche du média témoin et relevez l’URL du fichier. Ouvrez cette adresse dans un nouvel onglet. Vérifiez que vous consultez bien le fichier, pas une page de pièce jointe entourée du thème. Pour une image destinée à être publique, comparez aussi son accès sans connexion ; respectez les restrictions prévues pour les contenus privés.
Revenez à l’écran cassé et regardez dans Réseau la requête de l’image, avec le filtre Img si nécessaire. La vignette demandée peut avoir une autre adresse que le fichier principal. Comparez le domaine, le dossier, le nom et l’extension, sans modifier l’URL au hasard pour fabriquer une variante supposée.
Par exemple, le fichier principal peut s’ouvrir alors que seule une version redimensionnée manque. À l’inverse, la fiche peut pointer vers un ancien domaine. Ces deux situations demandent des corrections différentes. Conservez les adresses exactes et le résultat de chaque ouverture avant de lancer une réparation.
Distinguer fichier absent, refus d’accès et adresse obsolète
Un 404 sur l’image indique que cette adresse ne fournit pas la ressource attendue ; le fichier peut manquer, avoir changé de chemin ou être masqué par une règle. Un 403 appelle une vérification d’accès. Demandez à l’hébergeur de comparer le chemin réel, le propriétaire et les permissions, sans imposer un réglage universel ni ouvrir les dossiers en 777.
Si le site est en HTTPS mais demande encore une image en HTTP, relevez les avertissements du navigateur. Selon la ressource, le navigateur tente une adresse HTTPS ou bloque le chargement. La correction consiste à rétablir une adresse sécurisée valide, sans autoriser globalement le contenu non sécurisé.
Un CDN est un service intermédiaire qui distribue des copies des médias. Si les fichiers passent par ce service ou un stockage externe, son adresse et ses règles font partie du diagnostic. Faites vérifier l’origine autorisée avant une purge ciblée ; vider un cache ne recrée pas un fichier absent.
Quand seule une taille d’image manque
Une image possède des informations décrivant ses dimensions et ses variantes. Si l’original est lisible mais qu’une vignette ne l’est pas, faites comparer ces informations avec les fichiers réellement présents. Une mauvaise URL de stockage doit être corrigée avant de demander une nouvelle miniature.
Après identification de la cause, une régénération limitée au média concerné peut reconstruire certaines tailles. Elle exige une source lisible et un environnement capable de la traiter. Avec un stockage externe, faites confirmer la méthode adaptée à cette intégration. Une régénération ne récupère pas un original perdu.
Si WP-CLI est déjà disponible, l’administrateur peut cibler l’identifiant vérifié, après sauvegarde des fichiers et des données associées. Ne lancez pas une régénération générale pour résoudre une grille vide ou une requête refusée : elle intervient sur un autre problème.
Régénérer un seul média avec WP-CLI déjà disponible
Ce parcours suppose un accès autorisé au terminal et un original lisible. Ouvrez la fiche du média depuis la vue liste et relevez son identifiant dans l’adresse d’édition : le nombre placé après post= correspond à cette fiche. Faites confirmer cet identifiant et le dossier WordPress par l’administrateur avant d’exécuter une commande.
Depuis le répertoire de cette installation, l’exemple suivant régénère les tailles du média 123. Remplacez 123 par l’identifiant réellement vérifié. La commande écrit immédiatement lorsqu’un identifiant est fourni ; ce n’est pas une simulation. Sur un multisite, l’administrateur doit aussi sélectionner le bon sous-site avec l’option --url.
L’option --skip-delete conserve les anciennes miniatures qui pourraient encore être référencées. Elle n’annule pas les modifications des fichiers régénérés ni celles des métadonnées : la sauvegarde reste nécessaire. N’ajoutez pas d’option de suppression ou de mise à jour automatique des références pour ce premier essai ciblé.
Relevez le résultat, puis contrôlez la fiche, la vignette attendue et une page utilisant l’image. Si l’original ne peut pas être lu ou traité, arrêtez les régénérations : il faut résoudre cette cause. Si une modification dégrade le résultat, faites restaurer seulement les fichiers et données associés au média depuis la copie de contrôle. Sans WP-CLI disponible, demandez à l’hébergeur cette opération ciblée ; l’installation d’une nouvelle extension n’est pas nécessaire à ce diagnostic.
wp media regenerate 123 --skip-deleteAprès une migration, vérifier ce qui a réellement été transféré
Comparez un média ancien et un média récent, ainsi que leurs dates et chemins. Si seuls les fichiers d’une période manquent, vérifiez si les dossiers correspondants ont été transférés. Un dossier de médias peut avoir été personnalisé ou externalisé ; ne supposez pas que tout se trouve forcément au même endroit que sur l’ancien hébergement.
Si les adresses pointent vers l’ancien domaine, faites distinguer les URL présentes dans les articles, celles calculées pour les médias et celles produites par un service de stockage. Changer le titre d’une image ou réenregistrer les permaliens ne corrige pas automatiquement ces trois sources.
Une correction d’adresses en base doit préserver les données structurées de WordPress. Confiez au responsable une opération limitée, précédée d’une sauvegarde et d’une simulation avec un outil adapté. Ne remplacez pas aveuglément du texte dans un export SQL. Contrôlez les occurrences proposées avant toute écriture et vérifiez ensuite les médias témoins.
Des fichiers présents ne suffisent pas à remplir la bibliothèque
Déposer des images par SFTP dans un dossier ne crée pas automatiquement leurs fiches WordPress. De même, une migration peut transférer les fichiers sans les enregistrements qui les décrivent. Une image encore visible dans un article ne prouve donc pas qu’elle figure dans la bibliothèque de la nouvelle installation.
Si les deux vues restent vides, faites confirmer la base et le site réellement consultés, puis la présence des pièces jointes et de leurs métadonnées. Le contrôle doit précéder tout import : une règle de filtrage pourrait simplement masquer des fiches existantes.
Lorsque des fiches manquent réellement, choisissez avec le responsable entre une récupération ciblée depuis l’ancienne copie et un import contrôlé des fichiers autorisés. Réimporter peut créer de nouveaux identifiants et des doublons sans réparer les associations des pages. Commencez par un seul média, contrôlez son adresse et ses usages, puis définissez le traitement du lot restant.
Récupérer les éléments manquants sans remplacer le site actuel
Si un fichier a disparu, cherchez une copie locale, l’ancien stockage ou une sauvegarde contenant exactement cet élément. Si ses données WordPress manquent aussi, une archive de fichiers seule ne suffit pas. Demandez une inspection de la sauvegarde dans un environnement séparé, avec une base distincte et un accès protégé.
Récupérez uniquement les éléments identifiés. Avant de replacer un fichier au même chemin, vérifiez qu’il n’écrase pas une version actuelle différente. Avant de réintégrer des données, faites préserver les identifiants et associations nécessaires sans remplacer les autres contenus. Un ancien identifiant déjà réattribué sur le nouveau site ne doit pas être écrasé pour forcer cette correspondance.
Ne restaurez pas toute la base ni toute la préproduction pour retrouver quelques vignettes : les articles, comptes, commentaires et commandes récents pourraient être affectés. Si aucune copie exploitable n’existe, indiquez cette limite. Ni un nettoyage de cache ni une extension installée après la disparition ne garantit le retour du média original.
Confirmer le résultat et transmettre un dossier utile
Recherchez à nouveau le média témoin, sans filtre, en grille puis en liste. Ouvrez sa fiche, contrôlez le fichier et sa vignette, puis sélectionnez-le dans un brouillon. Vérifiez l’aperçu et une page déjà publiée qui l’utilise. Une bibliothèque redevenue visible ne suffit pas si ses images restent inaccessibles aux lecteurs.
Reprenez ensuite un deuxième média d’une autre date pour vérifier la portée de la correction. Rétablissez les réglages temporaires et conservez la sauvegarde jusqu’à validation. Notez la cause constatée et la modification retenue plutôt que de conserver plusieurs changements dont l’effet reste inconnu.
Pour le support, transmettez les écrans touchés, la version, l’heure, le média témoin et les résultats grille, liste, sélecteur et URL directe. Ajoutez le statut de la requête concernée et les changements récents. Nettoyez les captures et ne partagez pas un export réseau complet contenant une session privée. Ces éléments permettent de travailler sur le bon niveau, sans recommencer une série d’essais destructifs.
