Autoload : mesurer les options chargées à chaque requête et les basculer
Ce qui est mesuré ici, au juste
À chaque appel — page d'accueil, image, appel REST —, WordPress lit en une seule requête toutes les options dont la colonne autoload est renseignée. Ces lignes ne coûtent donc pas du temps une seule fois, mais à chaque fois. Quelles valeurs de la colonne comptent comme « est chargée », Kakapo le demande à WordPress lui-même (wp_autoload_values_to_autoload, depuis la 6.6, filtre compris) ; sur les installations plus anciennes, c'est la liste yes, on, auto-on, auto qui s'applique. La longueur de chaque valeur est ensuite comptée en PHP, donc en octets réels. LENGTH() en SQL serait plus rapide, mais compte selon le pilote des caractères au lieu d'octets — sous SQLite, de faux chiffres apparaîtraient dans l'interface pour les caractères accentués et les émojis. La lecture se fait par tranches de 100 lignes et au maximum 20 000 lignes par passage ; si ce plafond est atteint, l'interface le dit et présente expressément les chiffres comme une borne inférieure. La mesure ne s'exécute qu'à l'ouverture de la section ou sur « Mesurer à nouveau » — jamais pendant la construction de page d'un visiteur — et reste ensuite valable 300 secondes.
Bien lire les quatre indicateurs
En haut figurent quatre chiffres. « Chargé à chaque appel » indique la taille totale, le nombre d'options et la durée de la mesure. « Part du seuil d'alerte » rapporte cela à 800 000 octets — exactement le même seuil que le contrôle « Santé du site » du cœur de WordPress, filtre compris ; deux limites d'alerte différentes dans une même installation ne feraient que semer la confusion. « Dont basculable » est la part sans propriétaire actif, c'est-à-dire ce à quoi vous pouvez réellement toucher. « Déjà basculé » additionne ce que vous avez déjà retiré ici du chargement. En dessous, la carte « D'où vient la charge » montre la même quantité répartie par origine, et la deuxième carte les 25 postes individuels les plus gros.
L'attribution est une comparaison de noms, pas une preuve
La table options n'a pas de colonne « Propriétaire ». Kakapo compare donc le nom de l'option avec ce qui se trouve réellement sur le disque : le nom du répertoire, le nom de fichier du script principal et le domaine de texte de chaque plugin installé ainsi que les slugs de tous les thèmes. Le préfixe correspondant le plus long l'emporte, sinon « kakapowp » l'emporterait sur « kakapowp_performance » et le mauvais plugin serait indiqué. Ce qu'un plugin utilise vraiment pour ses options ne figure dans aucun en-tête — une abréviation comme « wpseo » ne se déduit pas de « Yoast SEO ». Ces cas-là atterrissent dans le compartiment « aucune attribution », et cela veut dire « je ne sais pas », et non « n'appartient à personne ». Si vous connaissez un préfixe avec certitude, vous l'ajoutez via le filtre kwpp_autoload_praefixe ; le plugin fait exactement la même chose pour son propre préfixe.
Ce qui peut être basculé — et pourquoi beaucoup reste bloqué
Le bouton « Basculer » n'apparaît que si deux conditions sont remplies en même temps : l'option pèse au moins 1 KB et elle n'appartient à aucun composant actif. Restent donc bloquées les options du cœur de WordPress (liste fixe issue de populate_options, plus les motifs theme_mods_*, widget_* et *_user_roles — celles-là sont réellement nécessaires à chaque appel), les caches temporaires (les transients relèvent du nettoyage en profondeur, où ils disparaissent complètement au lieu d'être seulement chargés plus tard), tout ce qui provient d'un plugin actif ou du thème actif, et tout ce qui pèse moins de 1 KB, parce que la requête individuelle supplémentaire y coûte plus que les octets économisés. Passe la souris sur un bouton grisé : la raison y est indiquée en info-bulle. Le cas qui vaut la peine est presque toujours l'extension inactive ou désinstallée depuis longtemps, dont les lignes sont simplement restées là. Sans licence valide, la section est en veille — la mesure et l'affichage continuent, mais rien n'est basculé.
Basculer, journal, annuler
L'écriture passe par wp_set_option_autoload() du cœur, et non par un UPDATE maison : c'est la seule façon de vider ensuite les bons caches, sinon un cache d'objets externe continuerait à livrer l'ancien état. Sur les installations dépourvues de cette fonction, Kakapo écrit « no » et vide lui-même alloptions, notoptions et l'entrée individuelle. Avant l'écriture, la ligne est encore une fois vérifiée à neuf : existe-t-elle encore, est-elle seulement encore sur « chargée », et quelle est sa taille à cet instant — le journal doit indiquer ce qui a réellement été retiré du chargement. Si la base de données n'exécute pas la modification, le message le dit expressément, et rien n'a été modifié. Le journal conserve jusqu'à 200 entrées avec l'ancienne valeur de colonne, la taille, l'heure et le nom d'utilisateur. L'annulation est possible à l'unité ou pour toutes en une fois ; c'est « chargée » qui est réécrit, parce que la valeur intermédiaire « auto » de WordPress n'est pas restaurable via la fonction du cœur — la valeur d'origine reste visible dans le journal. Si une option a entre-temps complètement disparu, par exemple parce que le plugin a été désinstallé, Kakapo le signale et supprime l'entrée devenue sans objet au lieu de prétendre qu'elle a été « annulée ».