« É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.
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
- Confirmer que l’entrée en statut
trashne contient aucune personnalisation à conserver, en inspectant son contenu viawp post get <ID> --field=content. - Supprimer définitivement cette entrée orpheline avec
wp post delete <ID> --force, plutôt que de la laisser en corbeille indéfiniment. - Vider le cache d’objet du site avec
wp cache flushpour 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) --forceen 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_postsavant 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.
