Lancer le traitement par lots sur la médiathèque existante
Ce que fait l'exécution — et ce qui doit être activé au préalable
Les deux modules d'image de Kakapo Performance travaillent au moment où WordPress génère les tailles d'image : la compression fixe la qualité et retire les marqueurs EXIF, IPTC et XMP des tailles générées, le module de format crée les dérivés WebP et AVIF. Les deux agissent donc à partir du prochain téléversement. Pour les images qui se trouvent déjà dans la médiathèque, il ne se passe rien — et c'est exactement cette lacune que comble le traitement par lots.
Le traitement n'invente aucun travail. Il applique à l'existant exactement ce que tu as activé plus haut pour les nouveaux téléversements : WebP et/ou AVIF, et « Supprimer les métadonnées ». Si rien de tout cela n'est actif, le bouton de démarrage est verrouillé et en indique la raison — par exemple que le serveur ne sait pas écrire de WebP, ou que tout simplement aucun réglage n'est actif. Tu trouves la carte « Retraiter la médiathèque existante » dans la section « Images », sous les réglages d'image ; l'ordre dans l'interface correspond à l'ordre d'utilisation : d'abord régler, puis lancer le traitement sur l'existant.
Seuls sont touchés les fichiers joints de type JPEG et PNG qui ne se trouvent pas dans la corbeille. La ligne « Images JPEG/PNG dans le stock » t'en donne le nombre avant que tu ne démarres.
Démarrer, observer, mettre en pause
Un clic sur « Lancer le traitement par lots » crée le traitement et le démarre aussitôt. Le travail se fait par passes disposant d'un budget de temps de 8 secondes ; ensuite la passe rend compte, l'affichage est actualisé et la suivante démarre après 200 millisecondes. S'il reste moins de 3,5 secondes à la fin d'une passe, aucun nouveau fichier joint n'est entamé — le module de format compte en interne au moins trois secondes par image. Sur les serveurs où max_execution_time est défini, le budget est en plus plafonné à 80 pour cent de cette limite, afin que la passe ne soit pas coupée en plein milieu de la requête.
La barre montre une progression réelle : le nombre de fichiers joints traités divisé par le nombre total. En dessous figurent les chiffres en cours — dérivés générés et ignorés, une ligne pour WebP et une pour AVIF, ainsi que les fichiers allégés et les octets libérés. Tout en bas défilent les 14 dernières lignes du journal, chacune avec le nom du fichier et le résultat obtenu pour ce fichier.
« Mettre en pause » arrête l'exécution. Le bouton s'appelle ensuite « Reprendre », et le démarrage suivant repart exactement au fichier joint où il s'était arrêté. La même chose se produit si tu fermes simplement l'onglet : l'exécution s'arrête, rien n'est perdu. Si tu rouvres la page, elle interroge l'état et poursuit d'elle-même une exécution encore en cours.
Comment l'exécution survit à une interruption
L'état est enregistré avant le travail sur chaque fichier joint, et non seulement après. Si un passage meurt en plein milieu — limite d'exécution du serveur web, mémoire vive, un fichier sur lequel GD s'étrangle —, le passage suivant sait où cela a coincé. Si le même fichier joint reste trois tentatives durant sans le moindre progrès, il est laissé de côté avec une ligne en clair dans le journal, plutôt que de bloquer durablement l'exécution sur un seul fichier.
Deux pages d'administration ouvertes en même temps ne peuvent pas se gêner : un verrou n'autorise jamais qu'un seul passage à la fois. Si un passage est abattu par le serveur web et que le verrou reste en place, il est considéré comme orphelin au bout de 180 secondes et repris.
À la reprise, le nombre total est redéterminé au lieu d'être figé — entre la pause et la reprise, des fichiers ont pu être téléversés ou supprimés. Si tu désactives tous les paramètres d'image au milieu de l'exécution, elle s'arrête d'elle-même au lieu d'accomplir un travail que plus personne n'a demandé. « Réinitialiser » abandonne la progression et le rapport ; les fichiers déjà générés restent en place.
Lire correctement le rapport
À la fin figure une ligne de conclusion avec des tailles de fichiers mesurées — pas des estimations. Pour chaque dérivé généré, l'exécution compare la taille du fichier source à celle du résultat, deux valeurs réelles prises au moment de la génération. N'est compté que ce qui est apparu au cours de cette exécution ; ce qui a déjà été converti lors du téléversement n'y figure pas une seconde fois.
Trois choses y sont formulées ainsi à dessein, et non pas plus joliment : WebP et AVIF ont des lignes séparées, parce que deux dérivés naissent du même fichier source — une somme commune compterait le fichier source deux fois. Les pourcentages valent donc par ligne et ne doivent pas être additionnés ; un navigateur ne récupère jamais qu'un seul des deux formats. Et les nouveaux fichiers occupent en plus de la place sur le disque : l'économie se fait sur la transmission au visiteur. Seule la suppression des métadonnées libère réellement de l'espace de stockage, et ces octets figurent sur une ligne à part.
Si rien n'a été généré, le rapport le dit aussi : soit tout était déjà fait pour le stock, soit aucun résultat n'était plus petit que son fichier source. Un résultat qui n'est pas plus petit est rejeté et compté comme « ignoré » — jamais comme un gain.
Quand quelque chose est ignoré
Chaque dérivé non généré reçoit une raison en clair, et les raisons sont regroupées dans la ligne finale :
• « pas plus petit que l'original » — normal, l'original est conservé. • « trop grand pour la mémoire vive disponible » — le module de format vérifie les dimensions de l'image avant le décodage et refuse, plutôt que de laisser PHP se heurter à la limite de mémoire. • « un fichier se trouvait déjà à l'emplacement cible » — il n'est pas écrasé. Cela arrive typiquement lorsque la note attachée au fichier joint a été perdue alors que les fichiers sont toujours là. • « illisible » — endommagé, JPEG CMJN ou une variante exotique. • « non inscriptible » — vérifier les droits dans le dossier uploads. • « format non disponible sur ce serveur » — AVIF exige PHP 8.1 ou plus récent avec libavif, WebP une bibliothèque GD avec libwebp.
Deux choses que l'on prend souvent pour des erreurs sans en être : une deuxième exécution ne montre presque plus de mouvement, parce que ce qui est fait n'est pas refait — un marqueur sur le fichier joint retient pour combien de fichiers la suppression des métadonnées est déjà faite. Et changer un niveau de qualité ne renouvelle aucun fichier déjà généré ; il faudrait pour cela commencer par supprimer les dérivés.