Wordpress
WordPress 7.2 et Secrets API : préparer la mise à niveau
Le 12 novembre 2026, l’équipe hébergement de WordPress a demandé des essais avant la première version candidate de WordPress 7.2, prévue le 17 novembre. La nouvelle Secrets API permet aux extensions de stocker des clés d’API et des identifiants OAuth sous forme chiffrée. Pour un parc de sites existants, l’essai le plus utile consiste à vérifier que ces secrets restent lisibles après une restauration.
Par Laurent LOUIS-THERESE ·
Vérifier qui fournit la clé
Avec la configuration standard documentée pour la bêta 5, la Secrets API exige une valeur utilisable pour WP_SECRETS_KEY. L’installateur web la génère pour une nouvelle installation. Une mise à niveau ne l’ajoute pas à un site existant. Les installateurs qui écrivent leur propre fichier wp-config.php doivent prévoir la clé dans leur procédure de déploiement. Un hébergeur peut également fournir un mécanisme de stockage ou de gestion des clés spécifique.
Identifiez les extensions qui utiliseront l’API et vérifiez qui gère la clé sur chaque environnement. Sur un site géré par un prestataire, cette responsabilité doit figurer dans la procédure de restauration.
Tester une restauration avec un secret fictif
En recette, enregistrez un identifiant fictif avec une extension compatible ou via l’API, puis vérifiez que l’application sait l’utiliser. Restaurez la base et la configuration associée dans un environnement isolé. Confirmez que le secret reste lisible et que les journaux ne contiennent pas sa valeur.
La base et la clé doivent pouvoir être restaurées ensemble, avec des contrôles d’accès adaptés. Un clonage de production vers la recette mérite son propre scénario, avec des identifiants de test et une procédure qui évite d’y rendre utilisables les secrets de production.
Prévoir le comportement d’une extension en cas d’erreur
Pour une extension PHP, traitez séparément un secret jamais configuré et un secret enregistré devenu illisible. Dans le premier cas, l’interface peut demander un identifiant. Dans le second, elle doit signaler le problème de configuration ou de disponibilité pour que l’exploitant puisse intervenir. Vérifiez aussi ce que l’utilisateur voit si le fournisseur de secrets est en lecture seule.
Les résultats publiés par l’équipe hébergement portent sur des versions bêta. Rejouez les essais à la première version candidate, puis avec la version stable avant de déployer sur le parc. Le calendrier publié prévoit WordPress 7.2 le 8 décembre 2026.
Sources