Repérer l’étape où la miniature manque
L’image principale s’ouvre depuis votre stockage objet, mais certaines petites tailles restent absentes dans la médiathèque, une galerie ou une carte d’article. Le résultat recherché est de retrouver chaque variante nécessaire à son emplacement distant et de vérifier que la page demande cette version correcte.
Le stockage objet conserve les fichiers sous des noms complets appelés clés. Un conteneur, souvent nommé bucket, regroupe ces objets. La présence de l’original ne garantit pas celle d’une miniature : cette dernière doit d’abord être générée, décrite dans WordPress, puis transférée et rendue accessible par la bonne adresse de diffusion.
Il faut donc distinguer un fichier jamais créé, un fichier créé mais non envoyé, un objet présent sous une autre clé et un objet inaccessible au lecteur. Relancer toute la bibliothèque ne répond pas à ces quatre situations de la même manière. Choisissez d’abord un seul média témoin et une taille précise.
Ce guide concerne une externalisation déjà configurée. Il ne demande pas de changer de fournisseur ou d’installer un second système de transfert. Si le défaut vient seulement d’une ancienne URL après migration ou d’une nouvelle taille de thème non générée, commencez par ce diagnostic. Ici, le contrôle porte surtout sur la continuité entre WordPress, le fichier dérivé et sa copie distante.
Comparer l’original, la variante demandée et sa clé distante
Dans Médias → Bibliothèque, ouvrez la fiche d’une image touchée et notez son identifiant, le nom principal et la page qui l’utilise. Depuis la page publique, relevez dans Réseau l’URL exacte de la variante en échec. Conservez le domaine, le chemin, le nom, l’extension et le statut de réponse.
Dans la console du stockage, utilisez votre accès autorisé pour retrouver ce même objet dans le conteneur concerné. Comparez la clé entière, y compris un préfixe, l’année, le mois et une éventuelle version ajoutée au chemin. Une recherche du seul nom du fichier peut retrouver une autre copie sans prouver que l’adresse demandée la désigne.
Vérifiez aussi si la variante existe sur le serveur WordPress lorsque votre organisation conserve des copies locales. L’absence locale peut être volontaire après externalisation ; elle ne prouve pas la perte du fichier distant. Inversement, un fichier local présent ne démontre pas que le transfert a abouti.
À cette étape, ne créez pas un objet sous une clé devinée à partir de l’URL du CDN. Un domaine de diffusion peut masquer ou transformer son chemin d’origine. Relevez le conteneur et la clé enregistrés par l’intégration, puis comparez avec la console. Ce contrôle est une lecture seule et doit aboutir à une localisation confirmée de la variante, ou à son absence établie dans le bon périmètre.
Préserver les deux stockages avant une reprise
Avant toute régénération ou recopie, conservez les fichiers disponibles, les métadonnées du média en base et les informations de l’intégration qui associent ce média aux objets distants. Une sauvegarde des fichiers locaux peut omettre ceux qui ont été retirés du serveur après transfert. Vérifiez donc qu’une copie récupérable existe aussi pour le stockage objet.
Pour travailler sur une copie de WordPress, isolez également les écritures distantes. Une copie de base branchée sur le même conteneur et les mêmes clés peut modifier ou supprimer des objets utilisés par le site public. Faites préparer un stockage de contrôle séparé, ou un périmètre effectivement isolé, avant de lancer une action depuis cette copie.
Identifiez qui peut agir : l’éditeur d’article, l’administrateur WordPress et le gestionnaire du stockage ne possèdent pas nécessairement les mêmes droits. En multisite, confirmez le sous-site et l’identité du média avec l’administrateur réseau. Une même valeur numérique peut désigner une autre image dans un autre contexte.
Commencez par un média et gardez les valeurs précédentes des réglages. N’activez pas la suppression des copies locales pendant l’enquête. Si elle était déjà prévue, organisez la récupération de la source avec l’intégration avant le traitement. Le retour arrière doit pouvoir rétablir les fichiers, les métadonnées et la correspondance distante ; désactiver le plugin ne reconstitue pas cet ensemble.
Lire les réglages de l’intégration déjà utilisée
Avec WP Offload Media, ouvrez Réglages → WP Offload Media ; en réseau, utilisez le contexte d’administration prévu. Relevez le conteneur, le préfixe et le domaine de diffusion. Dans Support → Diagnostic Info, consultez notamment Names and Dimensions of Image Sizes pour vérifier que la taille attendue est bien déclarée.
Le présent exemple est documenté avec WP Offload Media Lite 3.4.4, édité par WP Engine, qui demande WordPress 5.9 et PHP 8.1 au minimum et est déclaré testé jusqu’à WordPress 7.1.4. Il décrit une intégration déjà en place, sans recommander de l’ajouter à côté d’un autre outil d’externalisation.
Distinguez les fonctions automatiques de Lite et les outils manuels de l’édition payante. La copie initiale de toute une ancienne bibliothèque, les outils de retour local et certaines actions à la demande ne doivent pas être supposés gratuits. Une licence inactive ou une limite de médias atteinte peut aussi rendre des outils indisponibles sans interrompre tous les nouveaux transferts automatiques.
N’éditez pas le conteneur ou le préfixe pour essayer une miniature. Un tel changement affecte l’organisation des objets et peut demander une migration suivie des références. Conservez le diagnostic dans un emplacement privé en retirant les secrets inutiles. Le résultat attendu de cette lecture est le périmètre exact du média et la méthode de reprise réellement disponible dans votre installation.
Approche 1 : recopier un média connu avec l’action manuelle disponible
Ce parcours convient lorsque les fichiers locaux et les métadonnées de la variante sont corrects, mais que sa copie distante manque. Il suppose WP Offload Media avec une licence et des droits qui exposent l’action manuelle correspondante, ainsi qu’une sauvegarde du média et des objets touchés. Ce n’est pas une fonction promise dans Lite.
Dans Médias → Bibliothèque, retrouvez uniquement le média témoin. Utilisez son action Copy to Bucket lorsqu’elle est disponible. Selon la présentation de la bibliothèque, les actions peuvent être regroupées dans un menu. Vérifiez l’identité et le périmètre avant de lancer : ne choisissez pas une suppression ni une action sur toute la bibliothèque.
Cette action recopie les fichiers du média à partir de l’état connu de WordPress. Elle n’apparaît pas lorsque le fichier principal local requis manque ; faites d’abord rétablir cette source par la méthode de l’intégration. Ne remplacez pas cette absence par un nouvel import qui créerait un autre média.
Après la recopie, vérifiez la clé de la variante dans la console, puis l’URL réellement demandée dans la page. Si le fichier a été remplacé de façon incorrecte, restaurez l’objet et les métadonnées concernés depuis la copie préparée. Ne supprimez pas le média de WordPress pour annuler le transfert : cette suppression peut aussi retirer ses fichiers distants. Si l’action n’est pas disponible, passez au parcours de génération adapté au lieu de rechercher une fonction gratuite inexistante.
Vérifier le besoin de génération avant de reprendre le transfert
Si la taille n’a jamais été créée, une recopie ne suffira pas. Confirmez son nom, ses dimensions et la capacité de la source à la produire. Une taille absente de la définition active doit être rétablie par le thème ou le composant qui en est responsable avant de lancer un traitement.
Dans le diagnostic de WP Offload Media, la liste des dimensions décrit les tailles enregistrées, pas l’existence de chacune pour tous les médias. Comparez-la avec le fichier et les métadonnées du témoin. Une variante physique présente mais non décrite peut ne pas être considérée comme faisant partie du média à transférer.
Avec WP-CLI déjà installé et un accès autorisé, la commande ci-dessous liste les tailles actives. Exécutez-la dans la bonne installation et le bon sous-site. Ne désactivez pas le thème ni l’intégration nécessaire au moyen d’options de lancement : vous perdriez le contexte que vous cherchez à examiner.
Conservez le nom technique exact pour la reprise ciblée. Si l’original est trop petit, manquant ou illisible, arrêtez la génération et récupérez une source adaptée. Le stockage objet peut conserver l’image principale, mais le moteur qui fabrique les tailles doit pouvoir la lire avec les droits de cette opération.
wp media image-sizeApproche 2 : générer la taille puis laisser l’intégration la reprendre
Ce parcours convient à un média déjà reconnu comme externalisé dont une taille nécessaire manque. Avec WP Offload Media Lite 3.4.4, le code prévoit un traitement particulier avant wp media regenerate : il permet de récupérer la source locale nécessaire et attend la génération des métadonnées avant la reprise du transfert. Cela ne constitue pas un outil universel d’import de toute une ancienne bibliothèque dans Lite.
L’exemple ci-dessous demande WP-CLI déjà disponible, un accès autorisé, l’intégration active et une source récupérable. Remplacez 123 par l’identifiant du média et carte-theme par la taille confirmée. En multisite, sélectionnez aussi explicitement le bon sous-site avec --url. Gardez le contexte de thème et d’extensions nécessaire.
La commande écrit immédiatement et peut déclencher des écritures distantes par l’intégration. --skip-delete évite la suppression des anciennes miniatures par cette commande, mais ne gouverne pas toutes les décisions de nettoyage du plugin de stockage. Il ne remplace donc ni la sauvegarde distante ni le contrôle des objets concernés.
Après exécution, lisez le rapport et les erreurs du transfert, puis vérifiez la variante dans la console et la page. Un succès de génération ne prouve pas celui de la copie distante. Si le résultat est incorrect, restaurez le média et sa correspondance depuis les copies préparées. N’enlevez pas l’identifiant pour relancer toute la bibliothèque.
wp media regenerate 123 --image_size=carte-theme --skip-deleteApproche 3 : corriger la diffusion lorsque l’objet est déjà présent
Si la variante existe sous la bonne clé, vérifiez le chemin entre cet objet et le navigateur avant une nouvelle copie. Dans Réglages → WP Offload Media → Delivery Settings, relevez Delivery Provider, Deliver Offloaded Media et, lorsqu’il est utilisé, Use Custom Domain Name (CNAME). Comparez ces réglages avec l’adresse publique attendue.
Si Deliver Offloaded Media a été désactivé alors que les copies locales ont été retirées, le site peut demander des fichiers qui ne sont plus disponibles localement. Après confirmation de ce cas, conservez la valeur précédente, réactivez la diffusion externalisée prévue puis contrôlez les nouvelles URL. Ne désactivez pas ce mécanisme au hasard pour forcer un retour local incomplet.
Si le domaine de diffusion est incorrect, faites confirmer le domaine et l’origine légitimes avant de corriger ce seul champ. Changer de fournisseur ou de conteneur dépasserait ce dépannage. Le résultat attendu est une URL qui désigne le bon objet avec le mode d’accès prévu.
Une réponse ancienne peut encore être conservée dans un CDN. Vérifiez d’abord l’objet et l’origine, puis purgez seulement la ressource ou le périmètre concerné avec l’outil déjà configuré. Pour annuler un changement sans effet, remettez la valeur initiale et conservez le résultat observé. Une purge ne crée pas une miniature absente et ne répare pas une mauvaise clé.
Distinguer objet absent, accès privé et erreur interorigine
Un refus d’accès ne prouve pas toujours qu’un objet existe. Certains stockages peuvent masquer son absence derrière une réponse 403 lorsque l’identité qui fait la demande ne peut pas en vérifier la présence. Utilisez la console et les droits prévus pour confirmer la clé, au lieu de déduire son existence du seul statut public.
Comparez ensuite l’accès attendu pour l’original et pour ses variantes. Des médias privés peuvent être servis par des URL signées, valables pendant une durée limitée. Une ancienne adresse copiée dans un contenu ou un cache peut avoir expiré. Contrôlez la génération de l’adresse par l’intégration plutôt que de recopier sa signature à la main.
Ne rendez pas tout le conteneur public pour examiner une miniature. Un stockage privé servi par une distribution autorisée peut être parfaitement normal. La correction doit conserver cette organisation et les restrictions prévues pour les documents ou produits qui partagent le même espace.
Enfin, un message CORS concerne des règles d’accès entre origines. L’affichage d’une image et son utilisation par du JavaScript ou un canvas ne demandent pas toujours les mêmes autorisations. Relevez la requête et l’usage en échec avant de modifier cette configuration. Ajouter une autorisation générale ne crée pas un objet manquant et ne corrige pas toutes les erreurs d’URL.
Étendre la reprise sans créer de nouveaux médias concurrents
Après réussite du témoin, regroupez les cas qui ont la même cause : tailles non générées, transferts incomplets ou domaine de diffusion incorrect. Un même lot peut contenir plusieurs défauts ; il ne faut pas lui appliquer une seule opération parce que toutes les cartes semblent vides.
Pour quelques médias, répétez le parcours ciblé en conservant leur identifiant. Pour une grande collection, faites préparer une liste et des lots compatibles avec les ressources du serveur et du stockage. Contrôlez les erreurs et l’état distant après chaque lot avant de poursuivre. Une génération locale rapide peut être suivie d’une copie distante encore incomplète.
Ne réimportez pas toutes les photographies pour obtenir de nouveaux identifiants. Les articles, galeries et réglages continueraient à référencer les anciens médias, tandis que les nouvelles copies occuperaient un autre emplacement. La reprise doit conserver les associations utiles ou faire l’objet d’une migration explicitement préparée.
Gardez les anciennes variantes et les sources tant que les usages importants ne sont pas validés. Une taille qui n’est plus déclarée par le thème peut encore être liée directement dans un ancien contenu. Le nettoyage des objets devenus inutiles est une opération distincte, à traiter après cette réparation et avec sa propre possibilité de récupération.
Contrôler le résultat sur la page et dans le stockage
Vérifiez d’abord la variante dans le bon conteneur et sous la clé attendue, puis son accès par le domaine utilisé par le site. Sur un contenu public, comparez aussi une session déconnectée. Pour un média privé, testez avec l’audience autorisée sans transformer son accès en accès public.
Rechargez les pages témoins à plusieurs largeurs et contrôlez les requêtes réellement effectuées. Une image peut fonctionner sur ordinateur et demander une autre variante sur téléphone. Comparez également une carte, une galerie et la fiche du média : elles n’utilisent pas nécessairement la même taille.
Conservez un relevé du média, de la taille, du chemin distant, de l’opération et du résultat. Si le fichier a été créé mais pas transféré, transmettez l’erreur de copie au responsable de l’intégration. Si l’objet existe mais reste refusé, transmettez la requête et le mode d’accès attendu au gestionnaire de diffusion. Cette séparation évite de régénérer en boucle une image déjà correcte.
Clôturez l’intervention seulement après avoir annulé les essais inutiles ou validé les réglages conservés. Une copie de contrôle ne doit pas rester capable d’écrire dans les clés du site public. Gardez les sauvegardes locales, distantes et les métadonnées nécessaires pendant la période utile de vérification ; elles permettront de revenir à un état cohérent si un autre usage révèle une régression.
Suivre une miniature fictive de WordPress à sa clé distante
Sur une copie isolée, choisissez un média et une taille enregistrée par le thème. Dans la recette, l’image d’origine mesure 640 × 400 et la taille carte-theme doit produire un JPEG de 240 × 160. Relevez l’identifiant dans la médiathèque et l’adresse réellement utilisée par la carte dans l’onglet Réseau. Si WordPress sert l’original par défaut quand la taille n’existe pas, relevez aussi ses dimensions. Un statut 200 sur cette adresse ne démontre pas que la miniature est disponible.
La génération ciblée avec WP-CLI a créé image-temoin-240x160.jpg sur la copie et l’a ajouté aux métadonnées du même média. La page demandait alors la clé fictive atelier/2026/11/image-temoin-240x160.jpg, encore absente du stockage de test. La réponse est passée à 404 bien que le fichier local existe. Ce cas montre où placer le prochain contrôle : vérifier l’objet exact et la méthode de transfert déjà utilisée. Le fichier original est resté disponible.
Vérifier le transfert et l’adresse de diffusion séparément
Dans la recette, une copie du fichier dérivé a été déposée dans un dossier qui simule le conteneur, sous la clé exacte demandée. La même URL a ensuite répondu 200 avec le JPEG de 240 × 160. Une seconde manipulation a fait demander le préfixe ancien/ à la page. L’objet restait présent sous atelier/, mais l’URL redevenait introuvable. Remettre le bon préfixe a rétabli la réponse sans régénérer le fichier.
Sur votre copie, faites ce contrôle dans cet ordre. Comparez d’abord le nom présent dans les métadonnées au fichier dérivé. Vérifiez ensuite sa clé complète dans la console du stockage. Revenez à l’URL réellement demandée avant toute purge. Si l’objet existe et que les clés diffèrent, examinez la correspondance enregistrée ou le réglage de diffusion qui construit cette adresse. Si elles correspondent mais que l’accès est refusé, vérifiez le mode de distribution et les droits prévus pour ce média.
Revenir au point de départ du média témoin
Gardez ensemble la sauvegarde des métadonnées, le fichier local et la copie du périmètre d’objets touchés. Sur la copie d’essai, rétablissez uniquement cet ensemble et revérifiez les dimensions et l’identifiant. Dans la recette, remettre les métadonnées précédentes et retirer la variante d’essai du périmètre de diffusion a reproduit le comportement initial. L’original est resté identique. Sur un site en service, vérifiez les écritures intervenues depuis la sauvegarde avant de restaurer des données.
La recette utilise WordPress et WP-CLI pour la génération. Le transfert et la diffusion sont simulés par un dossier local, sans clé d’accès ni fournisseur distant. Les boutons de WP Offload Media et les conditions d’accès du stockage doivent être vérifiés avec la configuration que vous êtes autorisé à administrer.
