Un an après le retrait du label « bêta » avec WordPress 6.2, l’éditeur de site tourne en production sur une bonne partie de mes projets. La stabilité générale a nettement progressé, mais certains comportements continuent de surprendre, y compris des développeurs expérimentés qui découvrent le FSE. Ce ne sont pas des bugs à proprement parler : ce sont des pièges, des comportements qui ont une explication logique une fois qu’on la connaît, mais qui coûtent facilement une heure de débogage la première fois qu’on les rencontre.
Voici cinq pièges rencontrés sur des projets clients réels cette année, avec à chaque fois l’explication du problème et la solution que j’applique désormais systématiquement.
1. Le cache de navigateur qui affiche un ancien template
Le symptôme classique : vous modifiez un template dans l’éditeur de site, vous enregistrez, et le site public continue d’afficher l’ancienne version. Panique, on recommence, toujours rien. Dans la majorité des cas, le coupable n’est ni WordPress ni l’hébergeur, mais le cache navigateur combiné à un plugin de cache agressif côté serveur qui met en cache les templates rendus côté front.
Solution : videz systématiquement le cache du plugin de cache (WP Rocket, W3 Total Cache, ou l’équivalent maison de l’hébergeur) après chaque modification de template en environnement de recette, et testez en navigation privée pour écarter le cache navigateur. Sur les projets où je gère l’hébergement, j’exclus désormais les pages en cours d’édition FSE du cache automatique tant que le site n’est pas passé en production finale.
2. Template part verrouillée contre bloc Query Loop
Ce piège est plus insidieux. Une template part d’en-tête verrouillée (via l’option templateLock) contenant un bloc Query Loop peut, dans certaines configurations, empêcher la mise à jour normale de la requête du bloc lorsqu’on modifie ses paramètres depuis une page qui utilise cette template part. Le verrouillage, pensé pour empêcher un client de casser la structure, finit par bloquer aussi des réglages légitimes.
Solution : évitez de placer un Query Loop dans une template part globale verrouillée. Préférez un verrouillage partiel, en limitant templateLock aux blocs de structure (colonnes, groupes) et en laissant le Query Loop et ses réglages de requête totalement libres, quitte à le protéger autrement, par exemple via les rôles utilisateurs.
3. Des styles globaux qui écrasent un CSS personnalisé
Les styles globaux définis dans theme.json ont une spécificité CSS étonnamment élevée, portée par des variables et des sélecteurs générés automatiquement par WordPress. Résultat : un CSS personnalisé ajouté via wp_enqueue_style() avec une spécificité plus faible se fait purement et simplement écraser, sans message d’erreur, ce qui rend le diagnostic particulièrement frustrant pour qui découvre ce comportement.
Solution : privilégiez, autant que possible, les réglages via theme.json plutôt qu’un CSS personnalisé qui vient combattre les styles globaux. Quand un CSS additionnel reste nécessaire, augmentez sa spécificité en conséquence, ou passez par le champ styles.blocks du theme.json pour cibler un bloc précis proprement, plutôt que de lutter contre le mécanisme en place.
4. La confusion entre template et template part à l’export
Quand on exporte un thème depuis l’éditeur de site (menu Outils → Exporter), WordPress génère les fichiers HTML correspondants dans les dossiers templates/ et parts/ du thème. Le piège apparaît quand un développeur modifie ensuite ces fichiers directement dans le code, sans comprendre que l’éditeur, lui, continue de lire en priorité les versions enregistrées en base de données si le thème a déjà été personnalisé côté client. Le code source et la base divergent silencieusement, et les modifications faites en local n’apparaissent jamais en ligne.
Solution : avant toute modification de fichier de template en code, vérifiez si une version personnalisée existe en base via le type de contenu wp_template ou wp_template_part (visible dans l’écran Apparence → Éditeur → Gérer tous les templates). Le cas échéant, réinitialisez le template à sa version du thème avant de reprendre la main en code, pour repartir sur une base saine.
5. Des rôles utilisateurs mal calibrés face à l’éditeur de site
Par défaut, seuls les administrateurs ont accès à l’éditeur de site. Mais dès qu’un client demande un accès éditeur pour un collaborateur non-administrateur, le réflexe consiste souvent à lui attribuer directement le rôle Administrateur, faute de solution plus fine évidente. Résultat : un utilisateur qui devait seulement modifier du contenu se retrouve avec un accès complet aux extensions, aux réglages et à la structure du thème.
Solution : utilisez les capacités spécifiques à l’éditeur de site (edit_theme_options notamment) pour construire un rôle intermédiaire avec un plugin de gestion des rôles, plutôt que de distribuer des comptes Administrateur par facilité. Cette précaution évite bien des mauvaises surprises quand un client modifie une template part sans en mesurer la portée sur l’ensemble du site.
Mon conseil maison : documentez ces pièges dans un mémo interne partagé avec toute l’équipe. La majorité du temps perdu dessus vient du fait qu’un seul développeur a la solution en tête, et que ses collègues redécouvrent le problème à chaque nouveau projet.
En résumé
Aucun de ces cinq pièges n’est un bug au sens strict : ce sont des comportements cohérents avec l’architecture de l’éditeur de site, mais rarement documentés clairement, et donc rarement anticipés. Cache navigateur, verrouillage de template part, spécificité des styles globaux, confusion template et template part, rôles utilisateurs mal calibrés : cinq points qui, une fois connus, se règlent en quelques minutes plutôt qu’en heures de débogage.
Le point commun à toutes ces solutions : mieux comprendre où WordPress stocke réellement l’information, entre base de données et fichiers du thème, et rester rigoureux sur la gestion des accès. C’est ce qui distingue un projet FSE qui tourne sereinement d’un projet qui accumule les tickets de support.
