# « Le modèle actuel ne peut pas être modifié » : un template verrouillé > L'éditeur de site refuse d'ouvrir un template en modification, sans explication détaillée. Diagnostic des trois causes possibles avant de crier au bug de l'éditeur. - Auteur : WordPress Développement - Publié le : 2021-11-07 - Mis à jour le : 2021-11-07 - Catégorie : Éditeur de site (FSE) - URL : https://www.wpmoderne.fr/fse/modele-actuel-ne-peut-pas-etre-modifie-template-verrouille/ ## L’essentiel - Trois causes distinctes à distinguer - Vérifier les capacités utilisateur en premier - Le thème parent peut aussi verrouiller un template « Le modèle actuel ne peut pas être modifié » : ce message, affiché en haut de l'écran du Site Editor à la place du bouton d'enregistrement habituel, ne donne aucune indication sur la cause réelle du blocage. Sur ce projet, un contributeur venait de signaler qu'il ne parvenait plus à éditer le template d'archive du site, alors que la veille encore, la modification fonctionnait sans problème. Ce type de blocage a plusieurs origines possibles, et confondre l'une avec l'autre fait perdre un temps précieux. Trois causes distinctes ont été identifiées au fil de plusieurs diagnostics similaires : le verrouillage explicite d'un bloc ou d'un template, une capacité utilisateur manquante, et un conflit de précédence entre thème enfant et thème parent. ## Symptôme : un message générique, sans détail exploitable Le message affiché ne précise ni la capacité manquante, ni le bloc concerné par un éventuel verrouillage. Il apparaît identique quelle que soit la cause réelle, ce qui oblige à procéder par élimination plutôt que par lecture directe de l'erreur. ## Diagnostic : distinguer les trois causes possibles La première piste à vérifier concerne les capacités de l'utilisateur connecté. Le Site Editor exige la capacité `edit_theme_options`, généralement réservée au rôle Administrateur. Un contributeur ou un éditeur, même avec des droits étendus sur le contenu, ne possède pas cette capacité par défaut, et se voit donc refuser l'accès en modification aux templates, tout en pouvant parfois consulter l'écran en lecture seule. > L'essentiel à retenir : Trois causes distinctes à distinguer ; Vérifier les capacités utilisateur en premier ; Le thème parent peut aussi verrouiller un template ``` $ wp user list --role=editeur --field=user_login marie.dupont julien.martin $ wp user meta get marie.dupont wp_capabilities a:1:{s:7:"editor";b:1;} ``` Sur ce projet précis, l'utilisateur bloqué avait bien le rôle Éditeur, sans capacité additionnelle liée au thème : la cause était donc, dans ce cas, un simple problème de permissions, résolu en ajoutant temporairement la capacité `edit_theme_options` via un filtre dédié, plutôt qu'en promouvant l'utilisateur au rôle Administrateur, trop large pour ce besoin ponctuel. ## Deuxième cause : un verrouillage explicite du bloc ou du template Quand l'utilisateur bloqué dispose bien des bonnes capacités, la deuxième piste concerne le verrouillage natif des blocs, introduit dans Gutenberg pour empêcher la suppression ou le déplacement accidentel d'éléments structurants d'un template. Un bloc ou un groupe de blocs verrouillé en modification (`lock: { edit: true }` dans ses attributs) peut, selon la configuration, bloquer l'ensemble du template plutôt qu'un seul bloc isolé. ### Retrouver le verrouillage dans le code du template L'inspection du contenu HTML du template, via l'écran d'édition du code (options des trois points en haut à droite de l'éditeur), permet de repérer l'attribut `lock` éventuellement présent sur un bloc parent englobant l'ensemble de la structure. ## Troisième cause : la précédence entre thème enfant et thème parent Sur un site utilisant un thème enfant construit par-dessus un thème bloc parent, un template portant le même nom de fichier peut exister dans les deux thèmes. Selon la logique de précédence de résolution des templates, WordPress privilégie normalement le thème enfant ; mais un template marqué comme appartenant au thème parent, sans équivalent correctement enregistré côté enfant, peut se retrouver en lecture seule, l'éditeur refusant de créer une copie modifiable sans intervention explicite de l'utilisateur. - Vérifier la capacité `edit_theme_options` de l'utilisateur concerné. - Inspecter le code du template à la recherche d'un attribut `lock` sur un bloc englobant. - Comparer les noms de fichiers de templates entre thème enfant et thème parent. > Face à ce type de message générique, on résiste à la tentation de tout réessayer au hasard : mieux vaut vérifier les trois causes dans l'ordre, une à une, en notant ce qui a été exclu à chaque étape. ## Correctif retenu et procédure de déverrouillage Sur ce projet, la cause s'est révélée être la première : une capacité manquante. La procédure de déverrouillage a consisté à ajouter un filtre temporaire sur `user_has_cap`, accordant la capacité `edit_theme_options` à ce contributeur spécifique, plutôt que de modifier son rôle global, afin de garder un contrôle précis sur qui peut toucher aux templates du site. ## Ce que ce billet ne couvre pas La gestion complète des rôles WordPress et la création de capacités personnalisées plus larges ne sont pas traitées ici : ce billet se concentre strictement sur le diagnostic de ce message d'erreur précis, sans entrer dans la conception d'une politique de permissions globale pour l'ensemble du site. ## En résumé Le message « Le modèle actuel ne peut pas être modifié » recouvre trois causes bien distinctes : une capacité utilisateur manquante, un verrouillage explicite de bloc, ou un conflit de précédence entre thème enfant et parent. Les vérifier dans cet ordre, méthodiquement, évite de perdre du temps à chercher un bug dans l'éditeur là où le problème vient, le plus souvent, d'une simple question de permissions.