# Widgets blocs : migrer un thème classique en douceur vers WordPress 5.8 > WordPress 5.8 a introduit les widgets en blocs. Comment adapter sidebar.php et register_sidebar sans casser un thème classique existant. - Auteur : Clément Hadrot - Publié le : 2021-10-05 - Mis à jour le : 2021-10-05 - Catégorie : Thèmes - URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/migrer-widgets-blocs-theme-classique/ ## L’essentiel - L'écran Widgets bloc remplace l'ancien écran sans rien casser côté register_sidebar - Certains widgets tiers anciens restent incompatibles avec la nouvelle interface - Un thème classique bien écrit n'a souvent rien à modifier WordPress 5.8, sorti cet été, a discrètement transformé l'un des écrans les plus anciens de l'administration : celui des widgets. Exit la interface glisser-déposer historique, place à un écran construit entièrement autour de l'éditeur de blocs. Pour un thème classique développé avant cette bascule, la question se pose légitimement : faut-il tout réécrire ? Bonne nouvelle après plusieurs migrations menées ces dernières semaines : un thème classique correctement structuré n'a généralement presque rien à changer. Ce tutoriel détaille ce qui fonctionne tel quel, ce qui mérite une vérification, et comment adapter `sidebar.php` si nécessaire. ## Ce qui ne change pas : register_sidebar La fonction `register_sidebar()`, appelée classiquement dans `functions.php` via le hook `widgets_init`, continue de fonctionner exactement comme avant. C'est elle qui déclare l'existence d'une zone de widgets, avec son identifiant, son nom et ses balises d'enrobage HTML : ``` function mon_theme_widgets_init() { register_sidebar( array( 'name' => __( 'Sidebar principale', 'mon-theme' ), 'id' => 'sidebar-1', 'description' => __( 'Zone affichée sur les articles.', 'mon-theme' ), 'before_widget' => '
', 'after_widget' => '
', 'before_title' => '

', 'after_title' => '

', ) ); } add_action( 'widgets_init', 'mon_theme_widgets_init' ); ``` Cette déclaration reste identique en widgets classiques comme en widgets blocs. C'est le nouvel écran d'administration qui change, pas la façon dont le thème déclare ses zones. ## Ce qui change réellement : le contenu stocké > L'essentiel à retenir : L'écran Widgets bloc remplace l'ancien écran sans rien casser côté register_sidebar ; Certains widgets tiers anciens restent incompatibles avec la nouvelle interface ; Un thème classique bien écrit n'a souvent rien à modifier La différence se situe dans la manière dont le contenu des widgets est désormais stocké et rendu. Avec les widgets blocs, chaque zone de widgets devient elle-même une zone d'édition de blocs, ce qui signifie que même un simple widget "Texte" est en réalité rendu comme un bloc `core/paragraph` ou `core/html` selon le contenu saisi. Le HTML final reste globalement identique, mais le balisage interne peut ajouter des classes supplémentaires liées au système de blocs. Pour un `sidebar.php` classique, cela ne pose généralement aucun problème car l'appel reste le même : ``` if ( is_active_sidebar( 'sidebar-1' ) ) { dynamic_sidebar( 'sidebar-1' ); } ``` ## Vérifier la compatibilité des widgets tiers Le vrai point d'attention concerne les extensions qui fournissent leurs propres widgets personnalisés, notamment les anciens plugins de réseaux sociaux ou de formulaires. Certains, non mis à jour depuis longtemps, affichent encore leur interface via l'ancienne classe `WP_Widget` sans que celle-ci s'intègre proprement dans le nouvel écran bloc. Les symptômes les plus courants : - Le widget apparaît dans une liste séparée intitulée « widgets classiques » plutôt que dans le catalogue de blocs principal - Les champs de configuration du widget s'affichent mal ou se réinitialisent après enregistrement - Le rendu front reste correct, seule l'expérience d'édition est dégradée Dans la majorité des cas rencontrés, le rendu public du site n'est pas impacté : seul le confort d'édition dans l'administration en pâtit. Un bon test consiste à ouvrir l'écran **Apparence > Widgets** après la mise à jour et à vérifier que chaque widget actif reste éditable normalement. ## Adapter sidebar.php si besoin Si votre thème affichait manuellement du HTML autour des widgets sans passer par `before_widget` et `after_widget`, c'est le bon moment pour corriger ce genre de pratique. Le nouvel écran bloc respecte scrupuleusement ces paramètres d'enrobage, et un thème qui les ignorait pouvait jusqu'ici s'en sortir par chance. Voici la structure que je recommande désormais pour un fichier `sidebar.php` propre : ``` ``` ## Revenir temporairement aux widgets classiques Le temps de migrer les extensions les plus problématiques, il reste possible de désactiver l'écran bloc et de retrouver l'interface historique, via l'extension officielle *Classic Widgets* publiée par l'équipe cœur de WordPress. C'est une solution de transition à privilégier plutôt que de bloquer une montée de version entière du site pour ce seul motif. > Avant toute mise à jour vers WordPress 5.8 sur un site client avec des widgets personnalisés, je teste systématiquement l'écran Widgets sur un environnement de recette. Cinq minutes suffisent généralement à repérer un widget tiers mal supporté, bien avant que le client ne s'en aperçoive en production. ## En résumé Pour un thème classique bien structuré, la migration vers les widgets blocs de WordPress 5.8 se passe sans accroc : `register_sidebar()` et `dynamic_sidebar()` continuent de fonctionner à l'identique. Le principal risque vient des extensions tierces anciennes, pas du thème lui-même. Un audit rapide de l'écran Widgets après mise à jour, complété si besoin par l'extension Classic Widgets en solution temporaire, suffit à sécuriser la transition sans réécrire une ligne de code du thème.