Exploiter « What’s new for developers

Si vous avez déjà mis à jour WordPress et découvert après coup qu’un hook a changé de comportement, que votre plugin déclenche un warning PHP 8.1, ou qu’un composant JS du bloc editor a été déprécié, vous connaissez le vrai coût de “je verrai plus tard”. La rubrique “What’s new for developers?” (les notes développeurs de chaque version) est précisément l’antidote… à condition de la consommer correctement, et pas comme un simple article de blog.

Le problème / Le besoin

Le besoin est simple : vous voulez anticiper les changements techniques de WordPress (core) qui impactent vos thèmes, plugins, snippets et intégrations (Divi, Elementor, Avada), sans passer des heures à lire des tickets Trac ou des PR GitHub.

Dans mon expérience, la plupart des incidents “mystérieux” après mise à jour viennent de trois choses :

Des dépréciations ignorées (PHP, JS, APIs WP) jusqu’au jour où elles deviennent des erreurs.
Des changements de comportement non détectés (capabilities, REST, éditeur de blocs, query).
Des différences d’environnement (cache, minification, versions PHP) qui masquent les warnings.

À la fin, vous saurez :

Lire efficacement “What’s new for developers?” pour WordPress 6.9.x (avril 2026) et en tirer une checklist exploitable.
Automatiser une partie du travail : repérer les dépréciations, journaliser, et déclencher des alertes en admin.
Tester proprement les changements avant de pousser en production.

Résumé rapide

On va transformer les notes “What’s new for developers?” en process : lecture ciblée + extraction + tests.
On va coder un mini-plugin “assistant de release” qui :
- affiche une checklist en admin,
- active un journal de dépréciations (PHP) côté WP_DEBUG_LOG,
- ajoute un mode de surveillance (admin notice) après mise à jour.
On va utiliser des APIs stables : hooks admin, options, capacités, escaping, et un peu de JS optionnel.
Compatibilité visée : WordPress 6.9.4, PHP 8.1+.
On finira avec une méthode de test reproductible (staging + WP-CLI + logs).

Quand utiliser cette solution

Vous maintenez un site (ou plusieurs) avec des snippets “historique” dans un thème enfant ou un plugin de snippets.
Vous développez un thème / plugin et vous voulez réduire les régressions à chaque release WordPress.
Vous gérez des sites avec page builder (Divi 5, Elementor, Avada) et vous voulez repérer vite les conflits (scripts, styles, hooks).
Vous avez déjà eu un incident post-update (écran blanc, erreurs REST, blocs cassés) et vous voulez un filet de sécurité.

Quand ne PAS utiliser cette solution

Vous ne pouvez pas activer WP_DEBUG et vous n’avez pas accès aux logs serveur : vous serez aveugle sur les dépréciations PHP. Dans ce cas, privilégiez l’observabilité via l’hébergeur (logs applicatifs) ou un APM.
Votre site est “no-code” et vous ne touchez jamais à functions.php / plugins : mieux vaut simplement suivre les notes de version et confier la validation à votre prestataire.
Vous cherchez une analyse exhaustive des changements core : la bonne source reste les tickets/PR. Les notes “What’s new for developers?” sont un résumé, pas une vérité complète.

Prérequis / avant de commencer

Avant toute chose :

Travaillez sur un staging (copie du site) avec la même version PHP et la même stack cache/CDN si possible.
Assurez-vous d’être en WordPress 6.9.4 et PHP 8.1+. Les warnings dépendent beaucoup de PHP.
Faites une sauvegarde (fichiers + base) et notez votre version actuelle + liste des plugins.

Outils utiles :

Developer Blog (WordPress.org) : c’est là que paraissent les posts “What’s new for developers?”.
Référence des fonctions WordPress (pour vérifier une API sans tomber sur un vieux tuto).
WordPress Core Trac (quand une note mentionne un changement, vous remontez au ticket).
wordpress-develop sur GitHub (pour lire le diff et comprendre le “pourquoi”).
php.net — configuration des erreurs (utile si vous devez ajuster le logging).

Sécurité : on va ajouter une page admin et stocker des options. On vérifiera les capacités (manage_options), on utilisera des nonces pour les actions, et on échappera toutes les sorties HTML.

L'approche naïve (et pourquoi l'éviter)

Ce que je vois souvent : quelqu’un lit en diagonale “What’s new for developers?”, repère 2 lignes, puis ajoute un snippet vite fait dans functions.php… et oublie tout le reste.

Exemple typique (anti-pattern) : activer un “mode debug” permanent en production, ou écrire une notice admin sans permissions.

<?php
// ❌ Exemple à éviter : pas de permission, pas de nonce, et debug permanent.
add_action('admin_notices', function () {
    echo '<div class="notice notice-warning"><p>Vérifiez les nouveautés dev de la dernière version.</p></div>';
});

// ❌ Exemple à éviter : forcer l'affichage des erreurs (risque sécurité + UX).
@ini_set('display_errors', '1');
error_reporting(E_ALL);

Pourquoi c’est un problème :

Sécurité : afficher des erreurs PHP peut révéler des chemins serveur, des secrets, des versions.
Maintenabilité : aucune trace de ce qui a été vérifié, ni de ce qui reste à faire.
Performance : des notices admin inutiles partout, et parfois des logs qui grossissent sans rotation.
Qualité : vous ne testez pas les scénarios réels (éditeur, REST, cron, front, page builder).

La bonne approche — tutoriel pas à pas

L’idée : vous utilisez “What’s new for developers?” comme un flux d’actions. Vous ne cherchez pas à tout retenir, vous cherchez à extraire ce qui impacte votre code, puis à prouver que tout marche via des tests et des logs.

Étape 1 — Définir votre “surface d’impact”

Avant même d’ouvrir les notes, listez :

Vos points d’entrée : thème enfant, mu-plugins, plugin custom, snippets, intégrations REST, blocs, shortcodes.
Les zones à risque : checkout WooCommerce, formulaires, recherche, pages builder, endpoints REST, cron.

J’ai souvent vu des mises à jour casser uniquement l’éditeur (Gutenberg) ou uniquement l’API REST. Si vous ne testez que le front, vous passez à côté.

Étape 2 — Lire “What’s new for developers?” comme une checklist

Quand vous ouvrez le post de la version (ex. 6.9), cherchez systématiquement :

Dépréciations (PHP/JS) et “deprecated” : ce sont vos dettes techniques.
Breaking changes ou changements de comportement : ce sont vos risques immédiats.
Performance : parfois un changement de cache/query modifie l’ordre d’exécution ou les timings.
REST API : permissions, schémas, champs, authent.
Block editor : scripts, packages, changements dans les supports de blocs.

Étape 3 — Installer un mini-plugin “assistant de release”

Vous allez créer un plugin (recommandé) plutôt que de coller du code dans functions.php. Ça évite les pertes lors d’un changement de thème et facilite la désactivation.

Créez un dossier :

wp-content/plugins/wp-release-dev-assistant/

Puis un fichier :

wp-content/plugins/wp-release-dev-assistant/wp-release-dev-assistant.php

Ce plugin va :

Ajouter une page “Release Dev Assistant” sous “Outils”.
Enregistrer une option “dernière version WP validée”.
Afficher une notice si la version installée est plus récente que la version validée.
Activer un logging des dépréciations (sans les afficher à l’écran).

Étape 4 — Activer le logging proprement (staging d’abord)

Sur staging, activez :

WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY à false

Référence : Debug WordPress.

Étape 5 — Tester les scénarios et “taguer” la version comme validée

Une fois vos tests faits, vous cliquez “Marquer cette version comme validée”. La notice disparaît, et vous gardez une trace.

Code complet

Copiez-collez ce fichier tel quel dans wp-content/plugins/wp-release-dev-assistant/wp-release-dev-assistant.php, puis activez le plugin dans l’admin.

<?php
/**
 * Plugin Name: WP Release Dev Assistant
 * Description: Aide à exploiter "What's new for developers?" en transformant une mise à jour WordPress en checklist + validations + logging de dépréciations.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 * Author: Votre Nom
 * License: GPLv2 or later
 */

if (!defined('ABSPATH')) {
    exit;
}

final class WP_RDA_Plugin {

    private const OPTION_VALIDATED_VERSION = 'wp_rda_validated_wp_version';
    private const OPTION_ENABLE_DEPRECATION_LOG = 'wp_rda_enable_deprecation_log';

    public static function init(): void {
        add_action('admin_menu', [__CLASS__, 'register_admin_page']);
        add_action('admin_init', [__CLASS__, 'register_settings']);

        // Notice uniquement en admin, et uniquement pour les admins.
        add_action('admin_notices', [__CLASS__, 'maybe_show_update_notice']);

        // Logging des dépréciations : on branche tôt, mais après le chargement WP.
        add_action('plugins_loaded', [__CLASS__, 'maybe_hook_deprecation_logging'], 1);

        // Action sécurisée pour "valider" la version.
        add_action('admin_post_wp_rda_validate_version', [__CLASS__, 'handle_validate_version']);
    }

    public static function register_admin_page(): void {
        add_management_page(
            'Release Dev Assistant',
            'Release Dev Assistant',
            'manage_options',
            'wp-release-dev-assistant',
            [__CLASS__, 'render_admin_page']
        );
    }

    public static function register_settings(): void {
        register_setting(
            'wp_rda_settings',
            self::OPTION_ENABLE_DEPRECATION_LOG,
            [
                'type'              => 'boolean',
                'sanitize_callback' => static function ($value) {
                    return (bool) $value;
                },
                'default'           => true,
            ]
        );
    }

    public static function maybe_show_update_notice(): void {
        if (!current_user_can('manage_options')) {
            return;
        }

        $validated = get_option(self::OPTION_VALIDATED_VERSION, '');
        $current   = get_bloginfo('version');

        // Si aucune validation n'a été faite, on affiche une notice "soft".
        if ($validated === '') {
            echo self::render_notice(
                'info',
                'Aucune version WordPress n’a été marquée comme validée sur ce site. Après vos tests, marquez la version actuelle comme validée dans Outils → Release Dev Assistant.'
            );
            return;
        }

        // Si la version actuelle est plus récente que la version validée, on alerte.
        if (version_compare($current, $validated, '>')) {
            $message = sprintf(
                'WordPress est en %1$s, mais la dernière version validée est %2$s. Lisez “What’s new for developers?” pour la/les version(s) intermédiaire(s), testez, puis validez.',
                esc_html($current),
                esc_html($validated)
            );
            echo self::render_notice('warning', $message);
        }
    }

    private static function render_notice(string $type, string $message): string {
        $allowed_types = ['info', 'warning', 'error', 'success'];
        if (!in_array($type, $allowed_types, true)) {
            $type = 'info';
        }

        return sprintf(
            '<div class="notice notice-%1$s"><p>%2$s</p></div>',
            esc_attr($type),
            wp_kses_post($message)
        );
    }

    public static function render_admin_page(): void {
        if (!current_user_can('manage_options')) {
            wp_die(esc_html__('Accès refusé.', 'wp-rda'));
        }

        $current   = get_bloginfo('version');
        $validated = get_option(self::OPTION_VALIDATED_VERSION, '');
        $enabled   = (bool) get_option(self::OPTION_ENABLE_DEPRECATION_LOG, true);

        $validate_url = wp_nonce_url(
            admin_url('admin-post.php?action=wp_rda_validate_version'),
            'wp_rda_validate_version'
        );
        ?>
        <div class="wrap">
            <h2>Release Dev Assistant</h2>

            <p>
                Version WordPress actuelle : <strong><?php echo esc_html($current); ?></strong><br>
                Dernière version marquée comme validée : <strong><?php echo esc_html($validated !== '' ? $validated : 'Aucune'); ?></strong>
            </p>

            <hr>

            <h3>Checklist pratique (basée sur “What’s new for developers?”)</h3>
            <ol>
                <li>Lire les sections <em>Dépréciations</em> (PHP/JS) et noter ce qui touche votre code.</li>
                <li>Vérifier les changements REST API (permissions, schémas, champs).</li>
                <li>Tester l’éditeur : création/édition, patterns, blocs réutilisables, widgets blocs.</li>
                <li>Tester le front : formulaires, recherche, pages builder, performance (cache).</li>
                <li>Relire <code>wp-content/debug.log</code> et corriger les warnings/dépréciations.</li>
            </ol>

            <hr>

            <h3>Options</h3>
            <form method="post" action="options.php">
                <?php
                settings_fields('wp_rda_settings');
                ?>

                <p>
                    <label>
                        <input type="checkbox" name="<?php echo esc_attr(self::OPTION_ENABLE_DEPRECATION_LOG); ?>" value="1" <?php checked($enabled); ?>>
                        Activer le logging des dépréciations PHP dans <code>debug.log</code> (recommandé sur staging)
                    </label>
                </p>

                <p>
                    <button class="button button-primary" type="submit">Enregistrer</button>
                </p>
            </form>

            <hr>

            <h3>Valider la version</h3>
            <p>
                Quand vous avez terminé vos tests pour WordPress <strong><?php echo esc_html($current); ?></strong>, marquez-la comme validée.
            </p>
            <p>
                <a class="button button-secondary" href="<?php echo esc_url($validate_url); ?>">Marquer cette version comme validée</a>
            </p>

            <hr>

            <h3>Raccourcis utiles</h3>
            <ul>
                <li>Docs Debug : <a href="https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/" target="_blank" rel="noopener">developer.wordpress.org</a></li>
                <li>Developer Blog : <a href="https://developer.wordpress.org/news/" target="_blank" rel="noopener">developer.wordpress.org/news</a></li>
                <li>Trac : <a href="https://core.trac.wordpress.org/" target="_blank" rel="noopener">core.trac.wordpress.org</a></li>
            </ul>

        </div>
        <?php
    }

    public static function handle_validate_version(): void {
        if (!current_user_can('manage_options')) {
            wp_die(esc_html__('Accès refusé.', 'wp-rda'));
        }

        check_admin_referer('wp_rda_validate_version');

        $current = get_bloginfo('version');

        // On stocke la version courante comme "validée".
        update_option(self::OPTION_VALIDATED_VERSION, $current, true);

        wp_safe_redirect(
            add_query_arg(
                [
                    'page'    => 'wp-release-dev-assistant',
                    'updated' => '1',
                ],
                admin_url('tools.php')
            )
        );
        exit;
    }

    public static function maybe_hook_deprecation_logging(): void {
        $enabled = (bool) get_option(self::OPTION_ENABLE_DEPRECATION_LOG, true);
        if (!$enabled) {
            return;
        }

        // Si WP_DEBUG_LOG n'est pas actif, on ne force rien : on évite les surprises en prod.
        if (!defined('WP_DEBUG_LOG') || !WP_DEBUG_LOG) {
            return;
        }

        /**
         * WordPress déclenche des hooks spécifiques lors de l’utilisation de fonctions dépréciées.
         * - deprecated_function_run
         * - deprecated_argument_run
         * - deprecated_hook_run
         *
         * Référence : hooks visibles dans wp-includes/functions.php (wordpress-develop).
         */
        add_action('deprecated_function_run', [__CLASS__, 'log_deprecated_function'], 10, 3);
        add_action('deprecated_argument_run', [__CLASS__, 'log_deprecated_argument'], 10, 3);
        add_action('deprecated_hook_run', [__CLASS__, 'log_deprecated_hook'], 10, 4);
    }

    public static function log_deprecated_function(string $function, string $replacement, string $version): void {
        self::write_log_line(sprintf(
            'DEPRECATION (function) %1$s deprecated since %2$s. Replacement: %3$s',
            $function,
            $version,
            $replacement !== '' ? $replacement : 'n/a'
        ));
    }

    public static function log_deprecated_argument(string $function, string $message, string $version): void {
        self::write_log_line(sprintf(
            'DEPRECATION (argument) %1$s deprecated since %2$s. Message: %3$s',
            $function,
            $version,
            $message !== '' ? $message : 'n/a'
        ));
    }

    public static function log_deprecated_hook(string $hook, string $replacement, string $version, string $message): void {
        self::write_log_line(sprintf(
            'DEPRECATION (hook) %1$s deprecated since %2$s. Replacement: %3$s. Message: %4$s',
            $hook,
            $version,
            $replacement !== '' ? $replacement : 'n/a',
            $message !== '' ? $message : 'n/a'
        ));
    }

    private static function write_log_line(string $line): void {
        // On évite d’exploser les logs avec des multi-lignes.
        $line = str_replace(["r", "n"], ' ', $line);

        // error_log écrit dans debug.log si WP_DEBUG_LOG est activé.
        error_log('[WP_RDA] ' . $line);
    }
}

WP_RDA_Plugin::init();

Explication du code

Vue d’ensemble (simple)

Le plugin fait trois choses :

Il affiche une notice si WordPress a été mis à jour mais pas “validé” (ça force une discipline de test).
Il fournit une page admin avec une checklist et un bouton de validation.
Il journalise les dépréciations WordPress dans debug.log via des hooks dédiés.

Détails techniques (hooks, sécurité, qualité)

admin_menu : ajoute une page sous “Outils”. Avantage : peu intrusif, pas un menu custom au premier niveau.
register_setting : enregistre une option typée (bool). On sanitize explicitement.
admin_notices : affiche une notice uniquement si current_user_can('manage_options'). Ça évite d’embêter les éditeurs/auteurs.
admin_post_* : endpoint admin pour traiter l’action “valider la version”. On protège avec nonce (check_admin_referer) et permission.
Logging des dépréciations : WordPress déclenche des actions quand une fonction/argument/hook déprécié est utilisé. On les écoute, puis on écrit dans debug.log via error_log() (qui respecte WP_DEBUG_LOG).
Escaping : esc_html pour le texte, esc_url pour les URLs, wp_kses_post pour le message de notice (si vous voulez y mettre des liens plus tard).

Pourquoi je ne force pas WP_DEBUG dans le plugin : c’est un réglage d’environnement. Forcer le debug depuis un plugin est une mauvaise surprise en production, et peut devenir un incident de sécurité.

Variantes et cas d'usage

Variante 1 — Ajouter un tableau de diagnostic “post-update”

Si vous gérez plusieurs sites, vous voulez souvent un tableau “symptôme → vérif → solution” directement dans l’admin. Vous pouvez enrichir la page avec un tableau statique (ou généré) basé sur vos incidents récurrents.

Symptôme	Cause probable	Vérification	Solution
Écran blanc après update	Fatal error PHP (incompatibilité PHP 8.1+, plugin)	Lire `debug.log` et logs serveur	Désactiver plugin fautif, corriger, mettre à jour
Blocs qui ne chargent plus en admin	Conflit JS / minification / package déprécié	Console navigateur + désactiver optimisation	Exclure scripts, mettre à jour builder, corriger enqueue
REST API renvoie 401/403	Changement de permission/cap, endpoint custom fragile	Tester endpoint avec token/cookie	Revoir `permission_callback`, capacités, nonces
Styles cassés sur une page builder	Cache/CDN, ordre CSS, asset combiné	Vider caches, comparer HTML/CSS	Purger cache, ajuster priorités d’enqueue

Variante 2 — Journaliser aussi les erreurs PHP (avec prudence)

Vous pouvez ajouter un handler d’erreurs PHP, mais je le fais rarement sur un site “normal” : ça peut doubler les logs et compliquer le diagnostic. Si vous le faites, limitez aux environnements de staging, et n’affichez jamais en front.

Référence utile côté PHP : set_error_handler().

Variante 3 — Lier la validation à un “lot de tests”

Sur des sites plus pro, je remplace le bouton “valider” par une validation conditionnelle : la version est validée seulement si un set de pages a été visité (smoke test) et si le log ne contient pas de dépréciations nouvelles. Ça demande plus de code (et de stockage), mais ça évite le “j’ai cliqué sans tester”.

Compatibilité Divi 5 / Elementor / Avada

“What’s new for developers?” touche souvent l’éditeur de blocs, les scripts, et les APIs. Les page builders ne sont pas directement concernés… jusqu’au moment où un changement d’asset, de dépendance JS, ou de hooks admin provoque un conflit.

Divi 5

Divi charge beaucoup d’assets en admin et en front. Si vous voyez des erreurs console après update WP, testez en désactivant temporairement minification/combinaison (Divi + cache plugin).
Votre plugin n’injecte pas de scripts, donc risque faible. La notice admin peut apparaître dans l’admin Divi : c’est voulu, mais limité aux admins.

Elementor

Après une mise à jour WordPress, testez spécifiquement l’éditeur Elementor (mode édition) + prévisualisation. Les conflits se voient souvent là (console, requêtes XHR).
Si Elementor active son “Safe Mode”, vos logs de dépréciations restent utiles pour distinguer “core” vs “add-on”.

Avada (Fusion Builder)

Avada a son propre pipeline CSS/JS. Après update, purge des caches Avada + plugin de cache + CDN. J’ai vu des “régressions” qui étaient juste des assets anciens servis.
Votre plugin ajoute une page sous Outils, pas dans les menus Avada : pas de collision d’UI.

Vérifications après mise en place

Activez le plugin, puis allez dans Outils → Release Dev Assistant.
Vérifiez que la notice admin apparaît (si aucune version n’a été validée).
Sur staging, activez WP_DEBUG + WP_DEBUG_LOG, puis provoquez volontairement une dépréciation (par exemple en activant un vieux plugin en staging) et vérifiez que wp-content/debug.log contient des lignes [WP_RDA] DEPRECATION ....
Cliquez “Marquer cette version comme validée”, puis vérifiez que :
- l’option est enregistrée,
- la notice disparaît (si version identique).
Mettez à jour WordPress (sur staging) vers une version supérieure : la notice doit réapparaître.

Si ça ne marche pas

Le plugin n’apparaît pas : vérifiez le chemin et le nom du fichier. Une erreur classique est de créer le fichier au mauvais endroit (ex. wp-content/plugin au lieu de wp-content/plugins).
Erreur fatale à l’activation : regardez le message exact. Souvent :
- un ; manquant,
- un fichier encodé bizarrement,
- une version PHP trop ancienne (le plugin demande 8.1+).
Pas de logs de dépréciations :
- assurez-vous que WP_DEBUG_LOG est bien true,
- vérifiez que wp-content/debug.log est accessible en écriture,
- confirmez que des dépréciations se déclenchent réellement (sur un site propre, il peut ne rien y avoir).
La notice reste même après validation :
- videz le cache admin (plugin cache, objet cache persistant),
- vérifiez que l’option wp_rda_validated_wp_version est bien mise à jour (via un plugin type “Health Check” ou via la DB).
Rien ne se passe en cliquant “valider” :
- vérifiez que vous êtes admin,
- vérifiez que la nonce n’est pas bloquée par un cache agressif,
- testez en désactivant temporairement un plugin de sécurité qui filtre admin-post.php.

Pièges et erreurs courantes

Erreur	Cause	Solution
Code collé dans `functions.php` et perdu après changement de thème	Mauvais emplacement	Utiliser un plugin dédié (comme ici) ou un mu-plugin
`Parse error: syntax error`	Parenthèse / point-virgule manquant	Copier-coller le fichier complet, vérifier l’éditeur, activer l’affichage d’erreurs sur staging
Notice visible pour tous les utilisateurs	Oubli de `current_user_can()`	Restreindre aux admins (ex. `manage_options`)
La notice ne s’affiche jamais	Hook inadapté ou priorité	Utiliser `admin_notices` (pas `wp_footer`), et ne pas sortir trop tôt
Pas de logs alors que `WP_DEBUG_LOG` est activé	Fichier non inscriptible / chemin différent / host bloque `error_log`	Vérifier permissions, logs serveur, config PHP, tester `error_log('test')`
Tests “OK” mais bug en prod	Cache/CDN/minification différent	Reproduire la stack en staging, purger caches, comparer headers
Dépréciations ignorées car “ça marche quand même”	Dette technique	Traiter les dépréciations comme des tickets à corriger avant la prochaine release
Conflit avec plugin de snippets	Snippet chargé deux fois / ordre de chargement	Désactiver les doublons, préférer un plugin unique, vérifier `plugins_loaded`
Permaliens cassés après update (404)	Règles de réécriture non régénérées	Aller dans Réglages → Permaliens → Enregistrer

Conseils sécurité, performance et maintenance

Ne loggez pas en prod “par défaut” : gardez WP_DEBUG_LOG pour staging, ou activez-le temporairement en prod en cas d’incident (et désactivez ensuite).
Rotation des logs : debug.log peut grossir vite. Sur des sites à fort trafic, j’ai déjà vu des fichiers de plusieurs Go. Mettez en place une rotation côté serveur.
Traitez les dépréciations comme des bugs : une dépréciation aujourd’hui devient souvent une suppression demain. C’est exactement ce que “What’s new for developers?” vous permet d’anticiper.
Compatibilité future : stocker la version validée comme une option simple est stable. Évitez de parser automatiquement des contenus externes (RSS/HTML) dans l’admin : c’est fragile et ça peut introduire des risques (timeouts, contenu injecté, etc.).
Performance admin : la notice est légère. Le logging est passif et ne s’active que si WP_DEBUG_LOG est vrai.

Ressources

FAQ

“What’s new for developers?” existe pour chaque version mineure ?

Le plus souvent, les posts “What’s new for developers?” sont centrés sur les versions majeures (ex. 6.9). Les mineures (6.9.1, 6.9.2…) sont plutôt des releases de maintenance/sécurité, avec des notes plus courtes. Pour une mineure, je vérifie quand même Trac/GitHub si un fix touche une zone sensible (REST, éditeur, multisite).

Pourquoi stocker une “version validée” ?

Parce que ça transforme un ressenti (“je crois que ça va”) en état (“cette version a été testée”). Sur des sites d’équipe, ça évite aussi le flou : quelqu’un voit la notice, sait qu’il reste du travail.

Est-ce que ce plugin remplace la lecture des notes de version ?

Non. Il vous force à faire le travail au bon moment, et il vous donne un endroit où centraliser une checklist. La source reste le Developer Blog et, si besoin, Trac/GitHub.

Pourquoi ne pas récupérer automatiquement le contenu “What’s new for developers?” dans l’admin ?

Parce que c’est fragile (HTML qui change), et que ça introduit des risques (timeouts, contenu externe). Je préfère un lien vers la source officielle et une checklist stable que vous adaptez à votre contexte.

Je ne vois aucune dépréciation dans `debug.log`. C’est normal ?

Oui. Un site propre et à jour peut n’en produire aucune. Les dépréciations apparaissent surtout avec des plugins anciens, du code custom daté, ou des intégrations JS.

Est-ce compatible multisite ?

Oui, mais l’option est stockée au niveau du site (pas du réseau). Si vous voulez une validation au niveau réseau, il faut passer sur des options réseau (get_site_option/update_site_option) et ajouter la page dans l’admin réseau.

Je suis sur PHP 8.0, ça marche ?

Le plugin déclare PHP 8.1 minimum. Techniquement, une partie pourrait fonctionner en 8.0, mais vous allez précisément rater des warnings/dépréciations spécifiques à 8.1+. Pour un process de mise à jour WordPress en 2026, je recommande de vous aligner sur 8.1+.

Où se trouve exactement “What’s new for developers?” ?

Sur le Developer Blog. Cherchez le post de la version (ex. “WordPress 6.9 Field Guide” ou “What’s new for developers in 6.9”). Selon les releases, le format peut varier, mais l’intention reste la même : une synthèse orientée dev.

Ça peut créer des faux positifs (notice affichée alors que tout est OK) ?

Oui, et c’est volontaire : la notice ne dit pas “ça ne marche pas”, elle dit “ce n’est pas validé”. Sur des environnements où WordPress est mis à jour automatiquement, c’est même un bon rappel.

Je peux l’utiliser avec un plugin de snippets au lieu d’un plugin dédié ?

Possible, mais je l’évite. Les plugins de snippets sont pratiques, mais j’ai déjà vu des snippets cassés par une mauvaise manipulation, ou chargés dans un ordre inattendu. Pour un outil de process (validation + logging), un plugin dédié est plus robuste.

Exploiter « What’s new for developers » sur WordPress