# Le bloc Widgets Legacy : afficher un vieux widget sans le réécrire

> Un client refuse de perdre son widget maison en attendant sa réécriture propre en bloc. Le bloc Legacy Widget permet de gagner du temps sans tout casser.

- Auteur : Clément Hadrot
- Publié le : 2021-03-08
- Mis à jour le : 2021-03-08
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/bloc-widgets-legacy-afficher-vieux-widget-sans-reecrire/

## L’essentiel

- Aucune réécriture nécessaire dans l'immédiat
- Le widget garde tous ses réglages d'origine
- Solution transitoire, pas définitive

Le client avait un widget maison développé plusieurs années auparavant, affichant des indicateurs météo pour trois villes différentes, avec une logique de cache et un appel à une API externe. Réécrire ce widget en bloc natif demandait un vrai chantier, sans budget prévu à court terme. Il fallait pourtant avancer sur la migration du thème vers les gabarits expérimentaux du plugin Gutenberg.

La solution est venue d'un bloc encore peu documenté à l'époque : Legacy Widget, ou `core/legacy-widget`. Ce bloc ne fait qu'une seule chose, mais il la fait bien : afficher, tel quel, n'importe quel widget classique enregistré via l'API historique de WordPress, sans exiger la moindre réécriture.

## Ce que fait précisément ce bloc

Techniquement, `core/legacy-widget` encapsule un widget existant, identifié par son identifiant de classe (par exemple `WP_Widget_Meteo` dans ce cas précis), et délègue son rendu à l'ancienne fonction `the_widget()` en coulisses. L'inspecteur du bloc propose même de choisir le widget parmi la liste de ceux disponibles sur le site, exactement comme le faisait autrefois l'écran classique « Widgets » du tableau de bord.

Les réglages spécifiques du widget, comme le nombre de villes affichées ou l'unité de température choisie sur ce projet, restent accessibles et modifiables directement dans le panneau du bloc, sans qu'aucune ligne de code n'ait été touchée dans le widget lui-même.

## La mise en œuvre sur ce projet

```
// Le widget existant n'a rien demandé de plus, il reste enregistré normalement
function agence_register_widgets() {
    register_widget( 'WP_Widget_Meteo' );
}
add_action( 'widgets_init', 'agence_register_widgets' );
```

Aucune modification n'a été nécessaire côté widget. Dans la template part de la colonne latérale du nouveau thème expérimental, j'ai simplement inséré le bloc Legacy Widget, sélectionné « Météo trois villes » dans la liste déroulante, et le rendu s'est affiché immédiatement, identique en tout point à ce qu'il produisait dans l'ancien thème.

> L'essentiel à retenir : Aucune réécriture nécessaire dans l'immédiat ; Le widget garde tous ses réglages d'origine ; Solution transitoire, pas définitive

## Les limites à garder en tête

- Le rendu final reste du HTML généré par le widget classique, sans transformation en attributs de bloc modifiables visuellement.
- Impossible de composer ce widget avec d'autres blocs à l'intérieur de sa propre zone : il reste une boîte fermée.
- La compatibilité à long terme dépend entièrement du widget d'origine, qui continue de vivre grâce à l'API historique de WordPress plutôt que d'être modernisé.

Cette solution reste donc transitoire par nature. Elle ne dispense pas d'une vraie réécriture en bloc natif un jour, mais elle permet de ne pas bloquer un projet entier à cause d'un seul widget hérité difficile à moderniser dans l'immédiat.

## Pourquoi j'ai proposé cette solution plutôt qu'une réécriture rapide

Une réécriture rapide et bâclée du widget en bloc natif aurait probablement introduit des régressions sur la logique de cache existante, assez subtile, qui évitait de surcharger l'API météo tierce. Le risque de casser un comportement fonctionnel pour gagner en pureté architecturale ne me semblait pas justifié dans le calendrier du projet.

> Une solution transitoire honnête, clairement identifiée comme telle, vaut toujours mieux qu'une réécriture précipitée qui introduit de nouveaux bugs sous couvert de modernité.

## Notre verdict

Le bloc Legacy Widget a rempli exactement son rôle : débloquer une migration sans sacrifier une fonctionnalité existante ni imposer un chantier de réécriture dans l'urgence. Je le recommande sans réserve pour tout widget encore fonctionnel dont la réécriture n'est pas prioritaire dans le calendrier d'un projet.

Je conseille toutefois de noter, dans la documentation technique du projet, la liste précise des widgets ainsi encapsulés, avec la date à laquelle chacun a été identifié comme candidat à une future réécriture. Sans cette trace écrite, ce genre de solution transitoire a fâcheusement tendance à devenir définitive par simple oubli, plutôt que par choix assumé.

La vraie réécriture en bloc natif reste inscrite dans la feuille de route du client, mais elle pourra désormais se faire sereinement, sans pression de blocage sur le reste de la migration du thème.