Un client gérant lui-même son restaurant gastronomique avait pris goût à l’éditeur de site, au point de déplacer un jour le logo du header dans le pied de page « pour essayer », cassant au passage la navigation principale du site. Le site est resté dans cet état trois jours avant qu’il ne m’appelle, pensant à un bug du thème. Le vrai problème n’était pas un bug : c’était l’absence de verrouillage sur les zones structurelles du template, censées rester stables entre deux visites du client dans l’éditeur.
Ce tutoriel détaille comment verrouiller un template ou une template part avec templateLock, au niveau du groupe de blocs qui compose la structure. Le verrouillage bloc par bloc dans l’éditeur classique de contenu, plus fin et manuel, n’est pas traité ici.
Les trois valeurs possibles de templateLock
L’attribut templateLock s’applique à un bloc conteneur (typiquement un bloc Groupe) et accepte trois valeurs, chacune avec un comportement distinct :
all: aucun bloc ne peut être ajouté, supprimé ou déplacé à l’intérieur du conteneur verrouillé. Les blocs existants restent modifiables dans leur contenu (texte, image), mais la structure est figée.insert: les blocs existants peuvent être déplacés ou supprimés, mais aucun nouveau bloc ne peut être inséré dans le conteneur.contentOnly: la structure entière est figée, mais chaque bloc enfant devient éditable uniquement dans son contenu, sans afficher les contrôles de déplacement ou de suppression au survol, ce qui simplifie considérablement l’interface pour un utilisateur non technique.
Pour le header du restaurant, contentOnly s’est révélé être le choix le plus adapté : le client peut toujours modifier le texte du slogan affiché à côté du logo, mais ne peut plus déplacer, dupliquer ou supprimer aucun bloc de la structure d’en-tête.
Appliquer le verrouillage dans un fichier de template part
Le verrouillage se déclare directement dans le HTML du template ou de la template part, en tant qu’attribut du commentaire de bloc qui délimite le groupe conteneur.
<!-- wp:group {"templateLock":"contentOnly","layout":{"type":"flex","justifyContent":"space-between"}} -->
<div class="wp-block-group">
<!-- wp:site-logo /-->
<!-- wp:paragraph -->
<p>La cuisine du marché, revisitée chaque saison</p>
<!-- /wp:paragraph -->
</div>
<!-- /wp:group -->
Ce fichier vit dans parts/header.html du thème bloc. Une fois ce verrouillage en place, l’ouverture de la template part header dans l’éditeur de site n’affiche plus les poignées de déplacement ni les options de suppression sur les blocs enfants, seul le texte du slogan reste directement cliquable pour modification.
Verrouiller au niveau du template complet plutôt que d’une seule zone
Sur un second projet, un client d’e-commerce artisanal avait tendance à modifier la structure entière du template de fiche produit, avec des conséquences plus graves : disparition du bouton d’ajout au panier. Dans ce cas, le verrouillage a été appliqué directement sur le bloc Groupe racine englobant tout le template, avec la valeur all, plus stricte, réservant les seules modifications de contenu (texte de description, images) à des blocs non conteneurs placés en dehors de toute structure verrouillée.
<!-- wp:group {"templateLock":"all","layout":{"type":"constrained"}} -->
<div class="wp-block-group">
<!-- wp:post-title /-->
<!-- wp:woocommerce/product-price /-->
<!-- wp:woocommerce/product-button /-->
</div>
<!-- /wp:group -->
Ce que le verrouillage ne bloque pas
Un point important à clarifier avec le client : templateLock ne protège que la structure de blocs du template ou de la template part concernée. Il n’empêche pas un utilisateur disposant des permissions suffisantes de modifier un autre template non verrouillé, ni de créer un template personnalisé pour une page spécifique qui contournerait entièrement le verrouillage existant. Sur le projet du restaurant, j’ai donc également retiré la capacité de créer de nouveaux templates depuis l’éditeur de site pour le rôle du client, via une restriction de capacité complémentaire, plutôt que de compter uniquement sur templateLock.
Retirer temporairement le verrouillage pour une modification légitime
Quand le client veut réellement modifier la structure d’un header verrouillé, par exemple pour ajouter durablement un nouveau lien de menu, l’intervention passe par un accès administrateur qui peut éditer le fichier parts/header.html directement en modifiant ou retirant temporairement l’attribut templateLock, avant de le remettre en place une fois le changement validé. Ce fonctionnement reproduit, à l’échelle du thème bloc, la logique d’une intervention développeur ponctuelle sur un thème classique.
Notre verdict
templateLock répond précisément au problème d’un client qui casse involontairement la structure de son site en explorant l’éditeur de site : la valeur contentOnly offre le meilleur compromis pour un header ou un pied de page, laissant le contenu éditable sans exposer la structure aux manipulations accidentelles. Sur des zones plus critiques comme une fiche produit, la valeur all reste préférable, quitte à accepter une flexibilité de contenu plus réduite pour le client final.
