# « Échec de la mise à jour du modèle » après un conflit d’ID de template en base > Diagnostic d'un conflit d'identifiant entre deux entrées wp_template en base de données, à l'origine d'une erreur de sauvegarde dans l'éditeur de site. - Auteur : WordPress Développement - Publié le : 2024-02-08 - Mis à jour le : 2024-02-08 - Catégorie : Éditeur de site (FSE) - URL : https://www.wpmoderne.fr/fse/conflit-id-template-base-donnees/ ## L’essentiel - L'erreur apparaît uniquement sur un seul template précis - Deux entrées wp_template partagent le même post_name - Résolution par fusion ou suppression de l'entrée en doublon « Échec de la mise à jour du modèle ». Ce message, apparu dans l'éditeur de site d'un site associatif au moment de sauvegarder une modification pourtant mineure sur le template d'archive d'événements, ne donnait aucune indication supplémentaire. Le bouton d'enregistrement restait actif, la modification semblait acceptée, puis l'erreur s'affichait systématiquement au clic suivant sur « Enregistrer ». Ce billet retrace le diagnostic d'un conflit d'identifiant entre deux entrées `wp_template` en base de données, cause peu documentée de ce message d'erreur, et la procédure de résolution appliquée. La migration de contenu complète et les extensions tierces installées sur ce site ne sont pas en cause ici et ne sont pas traitées dans ce billet. ## Un message d'erreur qui n'affecte qu'un seul template Les autres templates du site — page d'accueil, page standard, archive d'articles — s'enregistraient sans problème. Seul le template `archive-evenement.html`, personnalisé quelques mois plus tôt pour ajouter un filtre de date, déclenchait systématiquement l'erreur. Cette spécificité orientait vers une donnée propre à ce template plutôt qu'un problème global de configuration du site. L'inspection du réseau dans les outils de développement du navigateur a montré que la requête REST `PUT /wp-json/wp/v2/templates/{id}` renvoyait une réponse 500, sans détail exploitable côté client au-delà du code d'erreur générique. ## Diagnostic : deux entrées pour un même identifiant L'activation temporaire de `WP_DEBUG` et la consultation du journal d'erreurs PHP ont révélé la cause exacte : une violation de contrainte d'unicité sur la table `wp_posts`, provoquée par une tentative d'insertion d'un `post_name` déjà existant. La commande WP-CLI suivante a permis de confirmer l'anomalie. > L'essentiel à retenir : L'erreur apparaît uniquement sur un seul template précis ; Deux entrées wp_template partagent le même post_name ; Résolution par fusion ou suppression de l'entrée en doublon ``` wp post list --post_type=wp_template --post_status=any \ --fields=ID,post_name,post_status,post_modified ``` Deux entrées `wp_template` distinctes partageaient exactement le même `post_name`, `theme-bloc-asso//archive-evenement` : l'une avec le statut `publish`, correctement affichée et modifiée depuis des mois, l'autre avec le statut `trash`, un résidu d'une tentative de suppression incomplète survenue lors d'un ancien test de personnalisation, jamais réellement purgé de la corbeille. ## Pourquoi ce doublon bloquait la sauvegarde WordPress s'appuie sur le `post_name` pour résoudre un template personnalisé associé à un thème donné, mais la table `wp_posts` n'impose pas nativement une contrainte stricte empêchant deux entrées `wp_template` de même `post_name` tant que leurs statuts diffèrent. Lors de la sauvegarde, un mécanisme interne de résolution tentait de mettre à jour l'entrée active, mais entrait en conflit avec l'entrée en corbeille lors d'une vérification d'unicité déclenchée par un identifiant unique généré côté REST, provoquant l'échec de la requête. ## Résolution : purger l'entrée orpheline 1. Confirmer que l'entrée en statut `trash` ne contient aucune personnalisation à conserver, en inspectant son contenu via `wp post get --field=content`. 2. Supprimer définitivement cette entrée orpheline avec `wp post delete --force`, plutôt que de la laisser en corbeille indéfiniment. 3. Vider le cache d'objet du site avec `wp cache flush` pour s'assurer qu'aucune version mise en cache du template ne référence encore l'entrée supprimée. Après cette purge, la sauvegarde du template `archive-evenement.html` a fonctionné normalement, sans qu'aucune autre modification n'ait été nécessaire côté thème ou contenu. ## Prévention pour éviter la récidive - Vider régulièrement la corbeille des templates, tout comme celle des articles, via `wp post delete $(wp post list --post_type=wp_template --post_status=trash --field=ID) --force` en environnement de recette avant une passe de nettoyage en production. - Éviter de supprimer un template personnalisé directement depuis l'interface sans vérifier ensuite que la corbeille a bien été vidée, en particulier sur des sites où plusieurs personnes interviennent sur l'éditeur de site. - Documenter ce type d'incident dans un journal de maintenance interne, ce genre de conflit restant rare mais difficile à diagnostiquer sans connaître ce précédent. > Une erreur générique côté éditeur de site mérite presque toujours une vérification de la table `wp_posts` avant de chercher plus loin. ## Notre verdict Ce type de conflit reste rare, mais illustre une limite de l'architecture des templates personnalisés : leur résolution par convention de nommage plutôt que par contrainte stricte de base de données peut, dans des cas marginaux, produire des états incohérents difficiles à diagnostiquer sans une inspection directe de la base. Un contrôle périodique de la corbeille des templates reste une précaution simple pour éviter ce scénario.