Migrer un thème classique complexe vers un thème bloc : notre retour

WordPress 6.5 vient de sortir, avec son lot de nouveautés attendues : l’Interactivity API, les block bindings, la Font Library. Mais avant même d’exploiter ces ajouts, un client nous a confié un chantier plus terre à terre : migrer un thème classique vieux de neuf ans, chargé d’un customizer maison et d’une dizaine de widgets PHP sur mesure, vers un thème bloc complet.

Ce type de migration ne se résume jamais à une simple conversion technique. C’est un arbitrage permanent entre ce que le nouveau système sait bien faire et ce qu’il vaut mieux, pour l’instant, laisser tel quel. Voici ce que ce chantier de douze semaines nous a appris, avec ses réussites et ses compromis assumés.

L’état des lieux du thème classique

Le thème de départ reposait sur une architecture typique des années 2015-2017 : des fichiers page-*.php multipliés pour chaque variante de mise en page, un customizer étendu avec des dizaines d’options via WP_Customize_Manager, et surtout onze widgets personnalisés enregistrés via la classe WP_Widget, allant du bloc « derniers articles stylisés » à un widget de prise de rendez-vous connecté à une API externe.

Avant de démarrer, nous avons cartographié chaque widget, chaque option de customizer et chaque template, en notant leur fréquence d’usage réelle sur le site. Cette étape, souvent négligée, a évité de reconstruire des fonctionnalités que personne n’utilisait plus depuis des années.

Convertir les templates PHP en fichiers HTML de blocs

La conversion des templates a été la partie la plus mécanique. Chaque page-*.php est devenu un template bloc dans templates/, avec la boucle WordPress remplacée par les blocs core/post-content, core/query ou core/template-part selon le contexte. Les zones répétées (en-tête, pied de page, barre latérale) sont devenues des template parts réutilisables, ce qui a en réalité réduit la duplication par rapport à l’ancien thème.

• 7 fichiers page-*.php ont fusionné en 3 templates bloc grâce aux template parts partagées
• Le customizer a perdu la quasi-totalité de ses options, remplacées par les réglages de theme.json et l’éditeur de style global
• Les menus de navigation, auparavant gérés avec wp_nav_menu(), utilisent désormais le bloc core/navigation

Le vrai chantier : les widgets PHP personnalisés

C’est ici que le temps a réellement été investi. Un widget WP_Widget classique ne se convertit pas automatiquement en bloc : il faut soit le recoder en bloc dynamique avec une fonction de rendu PHP, soit accepter de le garder actif via l’écran Widgets classique, toujours disponible en parallèle des blocs.

Sur les onze widgets recensés, nous avons fait trois choix différents selon les cas :

1. Cinq widgets d’affichage simple (derniers articles, réseaux sociaux, newsletter) ont été recodés en blocs dynamiques via register_block_type() avec une fonction render_callback
2. Trois widgets complexes, notamment celui connecté à l’API de prise de rendez-vous, ont été conservés tels quels et intégrés via le bloc core/legacy-widget, en attendant une refonte plus large
3. Trois widgets obsolètes, jamais utilisés depuis la refonte précédente, ont été purement supprimés

Un exemple de widget converti en bloc dynamique

function agence_register_last_posts_block() {
    register_block_type( __DIR__ . '/blocks/last-posts', array(
        'render_callback' => 'agence_render_last_posts_block',
    ) );
}
add_action( 'init', 'agence_register_last_posts_block' );

function agence_render_last_posts_block( $attributes ) {
    $query = new WP_Query( array(
        'posts_per_page' => absint( $attributes['count'] ?? 3 ),
    ) );
    ob_start();
    while ( $query->have_posts() ) {
        $query->the_post();
        the_title( '<h3>', '</h3>' );
    }
    wp_reset_postdata();
    return ob_get_clean();
}

Ce que nous avons délibérément gardé en classique

Deux écrans d’administration métier, utilisés uniquement par l’équipe interne du client pour gérer des tarifs et des disponibilités, sont restés de simples pages d’administration PHP, hors de tout système de blocs. Les convertir n’aurait apporté aucun bénéfice pour l’utilisateur final et aurait consommé un temps disproportionné par rapport à l’usage réel.

Une migration réussie n’est pas celle qui bascule tout vers les blocs, c’est celle qui choisit consciemment ce qui reste en PHP classique, avec une raison claire pour chaque exception.

Le résultat après douze semaines

Le site final combine un thème bloc pour tout ce qui touche à l’affichage public, et une poignée d’écrans PHP classiques pour la gestion interne. Le temps d’édition d’une page a baissé nettement pour l’équipe marketing du client, qui n’a plus besoin de solliciter un développeur pour ajuster une mise en page simple. À l’inverse, le temps de développement initial a été supérieur à ce qu’une simple mise à jour du thème classique aurait demandé.

En résumé

Migrer un thème classique complexe vers un thème bloc n’est jamais un chantier de conversion automatique. La cartographie préalable des widgets et options réellement utilisés, l’acceptation de garder certains éléments en PHP classique, et le recodage ciblé des widgets à forte valeur d’usage forment le triptyque qui a rendu ce projet viable en douze semaines plutôt qu’en six mois.