Le passage au Full Site Editing redistribue les responsabilités techniques sur un projet WordPress. Les fichiers de template PHP ne pilotent plus la structure : c’est le theme.json qui centralise les décisions de rendu, des palettes de couleurs aux règles typographiques, en un point unique. Pour les équipes habituées à intervenir directement dans le code du thème, le changement de paradigme touche autant l’architecture que les workflows de production.
Lire également : Connexion à Arkevia impossible : les solutions pour récupérer l'accès à vos documents
Theme.json et héritage CSS : ce que le FSE modifie dans la cascade
Le fichier theme.json ne se contente pas de remplacer le Customizer. Il introduit une couche de styles qui s’insère dans la cascade CSS avec une spécificité propre, souvent supérieure à celle des feuilles de style classiques chargées via functions.php. Nous observons régulièrement des conflits lorsqu’un thème enfant ou un plugin injecte du CSS personnalisé sans tenir compte de cette nouvelle hiérarchie.
En pratique, les propriétés définies dans theme.json (espacements, tailles de police, couleurs) sont compilées en variables CSS custom et appliquées au niveau du body. Toute règle CSS écrite manuellement avec une spécificité équivalente ou inférieure sera ignorée. Les développeurs qui maintenaient des feuilles de style volumineuses doivent revoir leur approche : soit migrer les déclarations dans theme.json, soit augmenter la spécificité de leurs sélecteurs, ce qui va à rebours des bonnes pratiques.
A découvrir également : Fin de support : que faire de vos projets basés sur Silverlight Silverlight ?
Un article détaillé sur le blog de Globalis décrit cette mécanique et ses implications pour les thèmes sur mesure.
Blocs verrouillés et rôles utilisateurs : contrôler ce que chaque profil peut modifier
Le FSE donne accès à la totalité de la structure du site depuis l’éditeur. Un contributeur qui dispose du rôle Éditeur peut, par défaut, modifier le header, le footer et les templates de pages. Sur un site multi-rédacteurs, c’est un risque concret de casse involontaire.
WordPress propose un mécanisme de verrouillage de blocs (lock) avec deux niveaux : empêcher le déplacement, empêcher la suppression. Ces verrous se posent directement dans le template ou via l’attribut lock dans le markup du bloc. La documentation du support officiel WordPress fournit les spécifications à jour sur la compatibilité entre les API classiques et le système de blocs.
Nous recommandons de verrouiller systématiquement les blocs structurels (groupe header, navigation, colonnes de footer) avant de confier l’accès à des profils non techniques.
La granularité reste limitée. Il n’existe pas encore de système natif pour restreindre l’accès à l’éditeur de site par rôle sans plugin tiers. Les solutions comme les capabilities custom ou les filtres sur edit_theme_options restent nécessaires pour un contrôle fin.
Points de vigilance sur la sécurité des templates
- Un utilisateur avec le rôle Éditeur peut créer de nouveaux templates et modifier ceux existants, y compris le template d’archive ou de page 404.
- Les blocs réutilisables (synced patterns) modifiés par un profil propagent le changement sur toutes les pages où ils apparaissent, sans confirmation supplémentaire.
- Certains plugins de sécurité ne filtrent pas encore les modifications effectuées via l’éditeur de site, contrairement aux modifications de fichiers de thème qu’ils surveillent depuis longtemps.
FSE et performances WordPress : impact sur le rendu côté serveur
Les templates basés sur des blocs génèrent leur HTML via le moteur de rendu de Gutenberg côté serveur. Chaque bloc exécute sa fonction render_callback au moment du chargement de la page. Sur des pages à forte densité de blocs imbriqués (colonnes dans des groupes, dans des cover, dans des query loops), le temps de génération côté serveur augmente de façon mesurable.
Le bloc Query Loop mérite une attention particulière. Il exécute une WP_Query complète à chaque instance. Deux ou trois boucles de requêtes sur une même page d’accueil suffisent à multiplier les appels en base de données. Un cache objet (Redis, Memcached) devient alors moins optionnel qu’avant.
En revanche, le FSE réduit la dépendance aux page builders tiers qui chargent leurs propres frameworks CSS et JavaScript. Sur un site migré depuis Elementor ou Divi vers un thème bloc natif, le volume de ressources front-end diminue sensiblement, ce qui compense en partie le surcoût serveur.
Migrer un thème classique vers un thème bloc : arbitrages concrets
La migration ne se résume pas à activer un thème bloc et recréer les templates. Plusieurs arbitrages techniques conditionnent la réussite du projet.
- Les hooks d’action classiques (wp_head, wp_footer, template_redirect) continuent de fonctionner, mais les hooks liés aux templates de la hiérarchie PHP (get_header, get_footer) ne se déclenchent plus dans un thème bloc. Les plugins qui s’y accrochent cesseront de fonctionner silencieusement.
- Les widgets disparaissent. Toute logique métier placée dans un widget custom doit être convertie en bloc personnalisé ou en shortcode encapsulé dans un bloc HTML.
- Les menus enregistrés via register_nav_menus ne sont plus utilisés par le bloc Navigation, qui gère ses propres entités. La migration des menus existants demande une recréation manuelle ou un script d’import.
Quand la migration ne se justifie pas
Un thème classique stable, performant et maintenu par une équipe qui maîtrise sa base de code n’a pas besoin d’être migré pour le principe. Le FSE apporte un gain réel quand l’équipe éditoriale a besoin d’autonomie sur la structure des pages, ou quand le thème actuel accumule des dépendances lourdes (builder, framework CSS tiers, plugins de mise en page).
Sur un site e-commerce complexe avec WooCommerce, les templates bloc pour les pages produit et le tunnel d’achat restent en cours de maturation. Nous observons encore des incompatibilités avec certains plugins de paiement et de gestion de stock qui n’ont pas adapté leur rendu au système de blocs.
Le Full Site Editing transforme WordPress en outil de conception structurelle, pas seulement rédactionnel. Cette bascule déplace la frontière entre le travail du développeur et celui de l’intégrateur ou du webdesigner. Les projets qui en tirent le meilleur parti sont ceux qui repensent leurs workflows en amont, plutôt que de plaquer l’ancien fonctionnement sur la nouvelle architecture.
