WordPress 5.5 vient de sortir, avec son lot habituel d’améliorations : sitemaps XML natifs, chargement différé des images, mises à jour automatiques des extensions. Moins visible dans les notes de version, un autre changement mérite l’attention d’un intégrateur qui garde un œil sur l’éditeur de blocs : l’arrivée de trois nouveaux blocs qui ne concernent plus un article, mais le site tout entier.
Ces blocs s’appellent Titre du site, Slogan du site et Logo du site. Rien d’extraordinaire en apparence, mais leur existence même est un signal : l’éditeur de blocs commence à s’aventurer sur un terrain jusque-là réservé aux fichiers de thème PHP.
Ce que ces blocs remplacent concrètement
Dans un thème classique, afficher le titre du site suppose un appel à bloginfo( 'name' ) ou à la fonction plus moderne get_bloginfo( 'name' ), généralement dans le fichier header.php. Le slogan repose sur bloginfo( 'description' ), et le logo sur la fonction the_custom_logo(), couplée au support de thème custom-logo déclaré via add_theme_support().
Les trois nouveaux blocs — core/site-title, core/site-tagline et core/site-logo — reproduisent ce même affichage, mais depuis l’éditeur de blocs. On peut les insérer aujourd’hui dans un article ou une page, ce qui semble d’abord anecdotique : pourquoi afficher le titre du site au milieu d’un article ?
Où cela devient intéressant pour préparer l’avenir
La réponse tient dans l’intention affichée par l’équipe du projet : ces blocs sont les premières briques d’un futur système où l’en-tête et le pied de page eux-mêmes seront composés de blocs, plutôt que codés en dur en PHP. Un thème qui commence dès maintenant à s’appuyer sur des zones modifiables préparera plus facilement sa bascule le jour où l’éditeur de site complet arrivera.
Concrètement, sur un projet récent, j’ai testé l’insertion du bloc Logo du site dans un gabarit de page d’accueil personnalisé, en complément du header PHP classique restant en place pour le reste du site. Le rendu est identique à the_custom_logo(), avec en prime un réglage de taille directement dans l’inspecteur de blocs, sans avoir à toucher au CSS du thème.
Limites actuelles à ne pas sous-estimer
- Ces blocs n’ont de sens que si le thème actif déclare le support
custom-logo, comme c’était déjà le cas pour la fonction PHP historique. - Aucun mécanisme ne permet encore de rendre un en-tête entier réutilisable sur toutes les pages depuis ces blocs : chaque page reste une entité indépendante.
- Le bloc Titre du site n’affiche pas de lien de modification directe vers les réglages généraux ; il faut toujours passer par l’écran classique des réglages pour changer le titre lui-même.
Autrement dit, on est loin d’un remplacement complet du header PHP. Ces blocs restent des briques isolées, à utiliser au cas par cas, plutôt qu’une stratégie de migration à part entière.
Comment je les utilise dès aujourd’hui sur un projet classique
Sur un site vitrine récent, j’ai proposé au client un gabarit de page « À propos » entièrement composé de blocs, y compris le bloc Logo du site en ouverture, pour tester la cohérence visuelle avec le reste du thème. Le résultat convainc : le rendu est identique au pixel près à ce que produisait l’ancien header, sans code supplémentaire.
Introduire ces blocs progressivement, page par page, permet de familiariser une équipe éditoriale avec la logique de blocs de site, bien avant que cela devienne obligatoire.
En résumé
Ces trois blocs ne bouleversent rien dans l’immédiat pour un thème classique bien construit. Mais ils tracent une direction claire, et un intégrateur qui commence dès maintenant à s’y familiariser gagnera un temps précieux le jour où l’éditeur de site deviendra la norme plutôt que l’exception.
Je garde un œil attentif sur les prochaines versions pour voir si d’autres blocs de site rejoindront ce trio, notamment du côté de la navigation, encore entièrement gérée par les menus classiques à ce stade.
