Sur un projet de refonte, on a voulu vérifier une intuition : jusqu’où peut-on aller en convertissant, morceau par morceau, un header.php tout à fait ordinaire en un template part écrit avec les blocs du plugin Gutenberg. L’exercice s’est révélé plus instructif que prévu, notamment pour comprendre les équivalences entre fonctions PHP et blocs.
Voici le point de départ, un en-tête assez représentatif de ce qu’on trouve dans la plupart des thèmes classiques : un logo, un menu de navigation et un champ de recherche.
<header class="site-header">
<a href="<?php echo esc_url( home_url( '/' ) ); ?>">
<?php the_custom_logo(); ?>
</a>
<?php wp_nav_menu( array( 'theme_location' => 'primary' ) ); ?>
<?php get_search_form(); ?>
</header>Étape 1 : le logo devient un bloc Site Logo
La fonction the_custom_logo() se remplace directement par le bloc Site Logo, qui va chercher la même image dans les réglages du site. Contrairement au PHP, le bloc propose dans l’éditeur des réglages de taille et de marge sans qu’aucune ligne de CSS supplémentaire ne soit nécessaire pour les cas simples.
Étape 2 : wp_nav_menu devient le bloc Navigation
L’appel à wp_nav_menu() se convertit en bloc Navigation. La différence est plus sensible ici : le bloc ne récupère pas directement un menu existant de la même façon, il faut reconstruire la structure des liens depuis l’éditeur ou depuis un import prévu à cet effet. Pour un menu à deux niveaux avec des liens vers les pages et une catégorie, l’opération reste rapide, mais un menu complexe avec des méga-menus personnalisés en JavaScript ne trouve pas encore d’équivalent direct.
Étape 3 : get_search_form devient le bloc Recherche
Le bloc Recherche reproduit le comportement de get_search_form(), avec quelques options de présentation en plus (bouton visible ou icône, largeur du champ). Le rendu HTML final diffère légèrement de celui généré par le thème classique, ce qui peut nécessiter un ajustement CSS si des styles spécifiques ciblaient les classes d’origine.
Étape 4 : assembler le tout dans un fichier HTML
Une fois les trois blocs configurés dans l’éditeur, leur export donne un fichier qui ressemble à ceci, destiné à un futur dossier block-templates ou parts :
<!-- wp:site-logo /-->
<!-- wp:navigation /-->
<!-- wp:search /-->Ce fichier ne contient plus une seule ligne de PHP. C’est là tout l’enjeu du Full Site Editing tel qu’il se dessine : le template devient une donnée déclarative plutôt qu’un programme.
Ce que l’exercice ne couvre pas
- Les conditions PHP complexes (afficher un élément uniquement sur certaines pages) n’ont pas toujours d’équivalent direct en bloc.
- Les hooks d’action personnalisés utilisés par des extensions tierces perdent leur point d’ancrage dans un en-tête tout en blocs.
- Le mécanisme de stockage définitif des fichiers HTML de thème n’est, à cette date, toujours pas figé.
Un deuxième essai, plus ambitieux
Pour aller plus loin que ce simple en-tête, on a tenté de reproduire également un bandeau d’alerte conditionnel, affiché uniquement lorsqu’un champ personnalisé du site indiquait une promotion en cours. Ici, l’exercice a montré ses limites plus nettement : rien dans les blocs de thème disponibles ne permet, à ce stade, de conditionner l’affichage d’un fragment à une donnée arbitraire sans écrire un bloc dynamique sur mesure, ce qui dépasse largement le cadre d’une simple conversion de gabarit existant.
Cette tentative confirme une chose : la conversion fonctionne remarquablement bien pour du contenu structurel stable, et beaucoup moins pour de la logique conditionnelle propre à un projet particulier.
Notre verdict
Convertir un en-tête simple prend quelques dizaines de minutes et permet de saisir concrètement la logique de correspondance entre fonctions PHP et blocs de thème. C’est un excellent exercice pédagogique, mais migrer un thème client entier de cette façon serait prématuré : trop de cas particuliers n’ont pas encore de solution stable. Ce genre de conversion partielle reste, pour l’instant, un outil de compréhension plus qu’une méthode de production.
