Roadmap WordPress 2026 : nouveautés et préparation

Ce qui change

Depuis la version 6.9, WordPress accélère le déploiement de fonctionnalités majeures prévues dans la roadmap 2026. La priorité est donnée à la compatibilité totale PHP 8.2+, l’introduction de l’éditeur de site « unifié » pour tous les thèmes, la dépréciation de plusieurs hooks historiques et la refonte de la gestion des médias en natif. Les agences et blogueurs qui utilisent des builders comme Divi 5, Elementor ou Avada devront s’adapter : certains hooks et points d’entrée changent, des templates classiques deviennent obsolètes, et la gestion du cache est modifiée.

Plusieurs tickets Trac et dev notes détaillent ces changements :

J’ai déjà rencontré des incompatibilités sur des sites qui utilisaient des plugins de médias personnalisés ou des hooks obsolètes dans leur thème enfant. Les erreurs sont rarement explicites : souvent, une fonctionnalité disparaît sans message d’alerte.

Résumé rapide

WordPress impose l’éditeur de site unifié à tous les thèmes (classiques compris) dès 6.10.
Refonte du Media Library : nouvelle API, fichiers WebP/AVIF nativement, hooks médias déplacés.
Dépréciation de plusieurs hooks historiques dont the_content dans certains contextes.
Les thèmes enfants utilisant des templates classiques doivent migrer vers les templates block ou hybrides.
Divi 5, Elementor et Avada : modules personnalisés doivent cibler les nouveaux hooks et l’API éditeur.
Minimum PHP recommandé : 8.1+, abandon du support 7.4 et 8.0 prévu pour la fin 2026.
Gestion du cache affinée, scripts et CSS mieux séparés, priorité aux assets modulaires.

Avant / Après en code

Template de page personnalisée (avant)


// Ancienne façon (avant WP 6.10)
add_filter('the_content', 'custom_page_template');
function custom_page_template($content) {
    if (is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $content;
    }
    return $content;
}

Template block/hybride (après)


// Nouvelle façon (WordPress 6.10+)
add_filter('render_block', 'custom_contact_block', 10, 2);
function custom_contact_block($block_content, $block) {
    if ($block['blockName'] === 'core/post-content' && is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $block_content;
    }
    return $block_content;
}

Le hook the_content n’est plus toujours appelé selon la structure de la page ou du template (notamment avec le nouvel éditeur unifié). Le hook render_block permet d’agir précisément sur les blocs ciblés.

Gestion des médias (avant)


// Ancienne façon
add_filter('wp_handle_upload_prefilter', 'check_custom_upload');
function check_custom_upload($file) {
    // Vérifie la taille, le type, etc.
    return $file;
}

Gestion des médias (après)


// Nouvelle API (WP_Media_Manager)
add_action('media_file_upload', 'check_custom_upload_modern', 10, 1);
function check_custom_upload_modern($media_object) {
    // $media_object est une instance avec méthodes de validation
    if ($media_object->get_size() > 5 * 1024 * 1024) {
        $media_object->add_error('Fichier trop volumineux');
    }
}

L’API média devient orientée objet. Les filtres historiques restent temporairement mais sont dépréciés. Les extensions doivent migrer sinon les erreurs ne seront plus gérées.

Impact concret

Les blogueurs qui utilisaient des shortcodes ou des hooks classiques dans leur thème pourront voir certaines personnalisations inactives après la 6.10. Les développeurs de plugins doivent migrer leurs hooks et vérifier la compatibilité de leurs assets JS/CSS. Les thèmes enfants basés sur des templates PHP classiques ne sont plus supportés par défaut par l’éditeur unifié.

Pour les builders :

Divi 5 : Les modules personnalisés doivent utiliser les nouveaux points d’entrée JS fournis par l’API de l’éditeur. Le système de sauvegarde côté Divi s’appuie désormais sur des hooks WordPress natifs (save_block) ; les anciens modules risquent de ne plus sauvegarder correctement leurs paramètres.
Elementor : Les widgets personnalisés doivent déclarer leur compatibilité avec le site editor. Les hooks elementor/frontend/after_register_scripts sont remplacés par des hooks block editor.
Avada : Le Fusion Builder doit être mis à jour pour utiliser la nouvelle API médias et les templates block. Les shortcodes classiques peuvent ne plus fonctionner selon la structure du template.

J’ai déjà observé des problèmes où un code fonctionnait parfaitement en 6.8 mais plus en 6.9.4, simplement parce qu’un hook comme the_content n’était plus appelé dans le template block par défaut.

Risques, compatibilités et points de vigilance

Plusieurs hooks historiques sont dépréciés ou n’ont plus d’effet dans l’éditeur unifié : the_content, get_the_excerpt, wp_head dans certains contextes.
Les thèmes enfants basés sur des templates PHP classiques ne sont plus garantis compatibles.
Les plugins qui manipulent la Media Library via les anciens filtres risquent d’être « silencieux » : plus d’erreur, plus de modification, rien dans les logs.
La gestion des assets (CSS/JS) change. Les assets non déclarés via wp_register_script ou wp_enqueue_block_script peuvent ne plus charger dans l’éditeur ou en frontend.
Les codes qui utilisent des fonctions non compatibles PHP 8.2+ (ex : certaines fonctions create_function) déclenchent des warnings ou sont ignorés.
Problèmes classiques : fichiers placés au mauvais endroit, oubli de vider le cache, permaliens non réinitialisés après passage à un template block, hooks personnalisés non déclarés dans le functions.php du thème enfant.
Le support PHP 7.4 et 8.0 sera supprimé avec WordPress 6.11 (Q4 2026).

Tableau de diagnostic pour les problèmes courants :

Symptôme	Cause probable	Vérification	Solution
Personnalisation du contenu inopérante	Hook `the_content` plus appelé	Debugger les hooks actifs sur la page	Utiliser `render_block` ou `save_block`
Erreur sur téléchargement d’image	Plugin utilise vieux filtre media	Vérifier les logs, tester avec le plugin désactivé	Adapter plugin à la nouvelle API médias
JS/CSS non chargé en éditeur	Mauvais enqueue ou nom de handle erroné	Inspecter l’éditeur, console du navigateur	Utiliser `wp_enqueue_block_script`
Module Divi/Elementor ne sauvegarde plus	Hook obsolète ou API non compatible	Consulter changelog builder	Migrer sur nouveaux hooks JS/API
Fatal error sur page	Fonction PHP obsolète (`create_function`, etc.)	Activer WP_DEBUG, consulter logs PHP	Réécrire le code avec closures modernes

Comment migrer

Identifier les hooks utilisés : Recherchez tous les add_filter, add_action dans vos thèmes/plugins. Privilégiez render_block ou save_block pour les contenus.

Vérifier les templates enfants : Passez aux templates block ou hybrides. Pour un template classique :


// Ancien template enfant
get_header();
the_content();
get_footer();

Passez à :


// Nouveau template block (template-parts/content-contact.html)

    
    
Sommaire

Ce qui change
Résumé rapide
Avant / Après en code
Impact concret
Risques, compatibilités et points de vigilance
Comment migrer
Faut-il agir maintenant ou attendre ?
Conseils de maintenance
Ressources
FAQ



Ce qui change

Depuis la version 6.9, WordPress accélère le déploiement de fonctionnalités majeures prévues dans la roadmap 2026. La priorité est donnée à la compatibilité totale PHP 8.2+, l’introduction de l’éditeur de site "unifié" pour tous les thèmes, la dépréciation de plusieurs hooks historiques et la refonte de la gestion des médias en natif. Les agences et blogueurs qui utilisent des builders comme Divi 5, Elementor ou Avada devront s’adapter : certains hooks et points d’entrée changent, des templates classiques deviennent obsolètes, et la gestion du cache est modifiée.


Plusieurs tickets Trac et dev notes détaillent ces changements : 

#61111 - Unified Site Editor rollout
Dev note : Media Management Overhaul
PR #62041 - Hook Deprecations
Site Editor global availability



J’ai déjà rencontré des incompatibilités sur des sites qui utilisaient des plugins de médias personnalisés ou des hooks obsolètes dans leur thème enfant. Les erreurs sont rarement explicites : souvent, une fonctionnalité disparaît sans message d’alerte.


Résumé rapide

WordPress impose l’éditeur de site unifié à tous les thèmes (classiques compris) dès 6.10.
Refonte du Media Library : nouvelle API, fichiers WebP/AVIF nativement, hooks médias déplacés.
Dépréciation de plusieurs hooks historiques dont the_content dans certains contextes.
Les thèmes enfants utilisant des templates classiques doivent migrer vers les templates block ou hybrides.
Divi 5, Elementor et Avada : modules personnalisés doivent cibler les nouveaux hooks et l’API éditeur.
Minimum PHP recommandé : 8.1+, abandon du support 7.4 et 8.0 prévu pour la fin 2026.
Gestion du cache affinée, scripts et CSS mieux séparés, priorité aux assets modulaires.


Avant / Après en code
Template de page personnalisée (avant)

// Ancienne façon (avant WP 6.10)
add_filter('the_content', 'custom_page_template');
function custom_page_template($content) {
    if (is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $content;
    }
    return $content;
}


Template block/hybride (après)

// Nouvelle façon (WordPress 6.10+)
add_filter('render_block', 'custom_contact_block', 10, 2);
function custom_contact_block($block_content, $block) {
    if ($block['blockName'] === 'core/post-content' && is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $block_content;
    }
    return $block_content;
}


Le hook the_content n’est plus toujours appelé selon la structure de la page ou du template (notamment avec le nouvel éditeur unifié). Le hook render_block permet d’agir précisément sur les blocs ciblés.

Gestion des médias (avant)

// Ancienne façon
add_filter('wp_handle_upload_prefilter', 'check_custom_upload');
function check_custom_upload($file) {
    // Vérifie la taille, le type, etc.
    return $file;
}


Gestion des médias (après)

// Nouvelle API (WP_Media_Manager)
add_action('media_file_upload', 'check_custom_upload_modern', 10, 1);
function check_custom_upload_modern($media_object) {
    // $media_object est une instance avec méthodes de validation
    if ($media_object->get_size() > 5 * 1024 * 1024) {
        $media_object->add_error('Fichier trop volumineux');
    }
}


L’API média devient orientée objet. Les filtres historiques restent temporairement mais sont dépréciés. Les extensions doivent migrer sinon les erreurs ne seront plus gérées.


Impact concret

Les blogueurs qui utilisaient des shortcodes ou des hooks classiques dans leur thème pourront voir certaines personnalisations inactives après la 6.10. Les développeurs de plugins doivent migrer leurs hooks et vérifier la compatibilité de leurs assets JS/CSS. Les thèmes enfants basés sur des templates PHP classiques ne sont plus supportés par défaut par l’éditeur unifié.


Pour les builders :

Divi 5 : Les modules personnalisés doivent utiliser les nouveaux points d’entrée JS fournis par l’API de l’éditeur. Le système de sauvegarde côté Divi s’appuie désormais sur des hooks WordPress natifs (save_block) ; les anciens modules risquent de ne plus sauvegarder correctement leurs paramètres.
Elementor : Les widgets personnalisés doivent déclarer leur compatibilité avec le site editor. Les hooks elementor/frontend/after_register_scripts sont remplacés par des hooks block editor.
Avada : Le Fusion Builder doit être mis à jour pour utiliser la nouvelle API médias et les templates block. Les shortcodes classiques peuvent ne plus fonctionner selon la structure du template.



J’ai déjà observé des problèmes où un code fonctionnait parfaitement en 6.8 mais plus en 6.9.4, simplement parce qu’un hook comme the_content n’était plus appelé dans le template block par défaut.


Risques, compatibilités et points de vigilance

Plusieurs hooks historiques sont dépréciés ou n’ont plus d’effet dans l’éditeur unifié : the_content, get_the_excerpt, wp_head dans certains contextes.
Les thèmes enfants basés sur des templates PHP classiques ne sont plus garantis compatibles.
Les plugins qui manipulent la Media Library via les anciens filtres risquent d’être "silencieux" : plus d’erreur, plus de modification, rien dans les logs.
La gestion des assets (CSS/JS) change. Les assets non déclarés via wp_register_script ou wp_enqueue_block_script peuvent ne plus charger dans l’éditeur ou en frontend.
Les codes qui utilisent des fonctions non compatibles PHP 8.2+ (ex : certaines fonctions create_function) déclenchent des warnings ou sont ignorés.
Problèmes classiques : fichiers placés au mauvais endroit, oubli de vider le cache, permaliens non réinitialisés après passage à un template block, hooks personnalisés non déclarés dans le functions.php du thème enfant.
Le support PHP 7.4 et 8.0 sera supprimé avec WordPress 6.11 (Q4 2026).


Tableau de diagnostic pour les problèmes courants :




Symptôme
Cause probable
Vérification
Solution




Personnalisation du contenu inopérante
Hook the_content plus appelé
Debugger les hooks actifs sur la page
Utiliser render_block ou save_block


Erreur sur téléchargement d’image
Plugin utilise vieux filtre media
Vérifier les logs, tester avec le plugin désactivé
Adapter plugin à la nouvelle API médias


JS/CSS non chargé en éditeur
Mauvais enqueue ou nom de handle erroné
Inspecter l’éditeur, console du navigateur
Utiliser wp_enqueue_block_script


Module Divi/Elementor ne sauvegarde plus
Hook obsolète ou API non compatible
Consulter changelog builder
Migrer sur nouveaux hooks JS/API


Fatal error sur page
Fonction PHP obsolète (create_function, etc.)
Activer WP_DEBUG, consulter logs PHP
Réécrire le code avec closures modernes




Comment migrer

Identifier les hooks utilisés : Recherchez tous les add_filter, add_action dans vos thèmes/plugins. Privilégiez render_block ou save_block pour les contenus.
Vérifier les templates enfants : Passez aux templates block ou hybrides. Pour un template classique :

// Ancien template enfant
get_header();
the_content();
get_footer();

Passez à :

// Nouveau template block (template-parts/content-contact.html)

    
    



Adapter la gestion des médias : Remplacez les hooks wp_handle_upload_prefilter etc. par la nouvelle API objet.
Mettre à jour les modules Divi/Elementor/Avada : Déclarez explicitement la compatibilité avec l’éditeur site et les nouveaux hooks (voir la doc respective).
Tester sur une copie locale : Jamais en production sans sauvegarde complète. Vérifiez la sauvegarde des modules personnalisés, le rendu des templates, la gestion des médias.
Vérifier la compatibilité PHP : Passez vos serveurs/stacks à PHP 8.1 ou 8.2, vérifiez que tous les plugins/thèmes sont compatibles.


Pièges fréquents : code copié d’un ancien tutoriel, snippet collé dans le mauvais fichier (functions.php parent au lieu d’enfant), oubli du purge cache, confusion entre actions et filtres.


Faut-il agir maintenant ou attendre ?

Si vous utilisez un thème enfant ou un plugin personnalisé qui touche au contenu, aux médias ou aux assets, il faut agir dès maintenant. Les hooks historiques sont déjà dépréciés (WP 6.9.4) et certains ne sont plus actifs en 6.10 bêta.


Pour les sites purement FSE ou blocks natifs, la transition est quasiment transparente. Mais si vous avez des shortcodes, des templates PHP classiques ou des modules page builder custom, la migration est nécessaire pour garantir la pérennité de vos personnalisations.


Je recommande de tester sur une copie locale, de consulter la dev note de chaque extension majeure, et de surveiller les logs PHP. Si votre builder (Divi/Elementor/Avada) publie un patch de compatibilité, appliquez-le sans attendre.


Conseils de maintenance

Planifiez un audit complet de vos hooks et templates avant la sortie de WordPress 6.10 stable.
Mettez en place des tests automatiques pour les hooks personnalisés et la gestion des médias.
Utilisez WP-CLI pour scanner les hooks dépréciés et les fichiers de template classiques.
Consultez régulièrement les changelogs de vos plugins page builder. Divi 5, Elementor et Avada publient leurs propres guides de migration.
Passez vos serveurs à PHP 8.2 au plus tôt, testez la compatibilité de tous les plugins actifs.
Programmez des sauvegardes automatiques et des points de restauration avant chaque mise à jour majeure.
Déployez sur staging avant production, et purgez toujours le cache (serveur + navigateur) après migration.
Vérifiez la génération des permaliens et régénérez-les après modification du template ou migration FSE.


Ressources

Dev note : Media Management Overhaul (2026)
Trac #61111 : Unified Site Editor rollout
PR #62041 : Hook Deprecations (GitHub)
Dev note : Site Editor global availability
Block Editor Reference Guides
WP-CLI Commands


FAQ

Mon shortcode ne s’affiche plus, que faire ?

Vérifiez si le template utilise encore do_shortcode ou si le contenu est désormais rendu via un block. Migrez votre logique sous forme de block personnalisé.

Je vois des erreurs de type "hook non défini", normal ?

Oui, de nombreux hooks (the_content, get_the_excerpt) sont dépréciés dans certains templates block. Passez sur render_block ou save_block.

Divi 5/Elementor me dit que mes modules custom sont obsolètes

Vos modules doivent cibler les nouveaux hooks JS/API du site editor. Consultez la doc officielle du builder utilisé.

Mon plugin de gestion média ne bloque plus les mauvais fichiers

Il doit utiliser la nouvelle API objet. Les anciens filtres sont ignorés dans la nouvelle Media Library.

Mes CSS/JS ne chargent plus en éditeur

Enregistrez-les avec wp_enqueue_block_script ou enqueue_block_editor_assets. Ne vous fiez plus aux anciens hooks globaux.

Les permaliens sont cassés après migration

Régénérez les permaliens dans Réglages > Permaliens après toute migration de template.

Je vois encore des erreurs PHP 7.4

Mettez à jour votre version PHP (min 8.1). Les extensions non compatibles doivent être remplacées.

Puis-je continuer à utiliser des templates enfants PHP classiques ?

Non, la compatibilité sera supprimée avec la sortie stable de 6.10. Passez aux templates block/hybrides.

Comment vérifier la compatibilité de mon site ?

Utilisez WP-CLI ou des plugins comme Query Monitor pour détecter les hooks dépréciés et surveiller les logs.

Les mises à jour automatiques sont-elles sûres ?

Toujours tester sur staging avant production. Les changements structurels peuvent casser le site si un plugin ou un thème n’est pas prêt.




Articles connexes

Intégrer WordPress au sein de WordPress
Nouveautés WordPress qui changent l’écosystème WP
Bonnes pratiques WordPress pour un site robuste
Nouveautés WordPress et impacts concrets pour les devs

Adapter la gestion des médias : Remplacez les hooks wp_handle_upload_prefilter etc. par la nouvelle API objet.
Mettre à jour les modules Divi/Elementor/Avada : Déclarez explicitement la compatibilité avec l’éditeur site et les nouveaux hooks (voir la doc respective).
Tester sur une copie locale : Jamais en production sans sauvegarde complète. Vérifiez la sauvegarde des modules personnalisés, le rendu des templates, la gestion des médias.
Vérifier la compatibilité PHP : Passez vos serveurs/stacks à PHP 8.1 ou 8.2, vérifiez que tous les plugins/thèmes sont compatibles.

Pièges fréquents : code copié d’un ancien tutoriel, snippet collé dans le mauvais fichier (functions.php parent au lieu d’enfant), oubli du purge cache, confusion entre actions et filtres.

Faut-il agir maintenant ou attendre ?

Si vous utilisez un thème enfant ou un plugin personnalisé qui touche au contenu, aux médias ou aux assets, il faut agir dès maintenant. Les hooks historiques sont déjà dépréciés (WP 6.9.4) et certains ne sont plus actifs en 6.10 bêta.

Pour les sites purement FSE ou blocks natifs, la transition est quasiment transparente. Mais si vous avez des shortcodes, des templates PHP classiques ou des modules page builder custom, la migration est nécessaire pour garantir la pérennité de vos personnalisations.

Je recommande de tester sur une copie locale, de consulter la dev note de chaque extension majeure, et de surveiller les logs PHP. Si votre builder (Divi/Elementor/Avada) publie un patch de compatibilité, appliquez-le sans attendre.

Conseils de maintenance

Planifiez un audit complet de vos hooks et templates avant la sortie de WordPress 6.10 stable.
Mettez en place des tests automatiques pour les hooks personnalisés et la gestion des médias.
Utilisez WP-CLI pour scanner les hooks dépréciés et les fichiers de template classiques.
Consultez régulièrement les changelogs de vos plugins page builder. Divi 5, Elementor et Avada publient leurs propres guides de migration.
Passez vos serveurs à PHP 8.2 au plus tôt, testez la compatibilité de tous les plugins actifs.
Programmez des sauvegardes automatiques et des points de restauration avant chaque mise à jour majeure.
Déployez sur staging avant production, et purgez toujours le cache (serveur + navigateur) après migration.
Vérifiez la génération des permaliens et régénérez-les après modification du template ou migration FSE.

Ressources

FAQ

Mon shortcode ne s’affiche plus, que faire ?
Vérifiez si le template utilise encore do_shortcode ou si le contenu est désormais rendu via un block. Migrez votre logique sous forme de block personnalisé.
Je vois des erreurs de type « hook non défini », normal ?
Oui, de nombreux hooks (the_content, get_the_excerpt) sont dépréciés dans certains templates block. Passez sur render_block ou save_block.
Divi 5/Elementor me dit que mes modules custom sont obsolètes
Vos modules doivent cibler les nouveaux hooks JS/API du site editor. Consultez la doc officielle du builder utilisé.
Mon plugin de gestion média ne bloque plus les mauvais fichiers
Il doit utiliser la nouvelle API objet. Les anciens filtres sont ignorés dans la nouvelle Media Library.
Mes CSS/JS ne chargent plus en éditeur
Enregistrez-les avec wp_enqueue_block_script ou enqueue_block_editor_assets. Ne vous fiez plus aux anciens hooks globaux.
Les permaliens sont cassés après migration
Régénérez les permaliens dans Réglages > Permaliens après toute migration de template.
Je vois encore des erreurs PHP 7.4
Mettez à jour votre version PHP (min 8.1). Les extensions non compatibles doivent être remplacées.
Puis-je continuer à utiliser des templates enfants PHP classiques ?
Non, la compatibilité sera supprimée avec la sortie stable de 6.10. Passez aux templates block/hybrides.
Comment vérifier la compatibilité de mon site ?
Utilisez WP-CLI ou des plugins comme Query Monitor pour détecter les hooks dépréciés et surveiller les logs.
Les mises à jour automatiques sont-elles sûres ?
Toujours tester sur staging avant production. Les changements structurels peuvent casser le site si un plugin ou un thème n’est pas prêt.

Roadmap WordPress 2026 : nouveautés et préparation

Ce qui change

Résumé rapide

Avant / Après en code

Template de page personnalisée (avant)

Template block/hybride (après)

Gestion des médias (avant)

Gestion des médias (après)

Impact concret

Risques, compatibilités et points de vigilance

Comment migrer

Ce qui change

Résumé rapide

Avant / Après en code

Template de page personnalisée (avant)

Template block/hybride (après)

Gestion des médias (avant)

Gestion des médias (après)

Impact concret

Risques, compatibilités et points de vigilance

Comment migrer

Faut-il agir maintenant ou attendre ?

Conseils de maintenance

Ressources

FAQ

Articles connexes

Faut-il agir maintenant ou attendre ?

Conseils de maintenance

Ressources

FAQ

Articles connexes

Envoyer Un Commentaire Annuler la réponse