Le post type wp_template : ce que WordPress stocke en base pour un gabarit

Pourquoi WordPress choisit-il de stocker un gabarit dans la même table que les articles, plutôt que de créer une structure dédiée ? La question se pose légitimement en observant les premières expérimentations du plugin Gutenberg autour de l’édition complète de site. La réponse tient à un principe ancien du projet : réutiliser les mécanismes existants plutôt qu’en inventer de nouveaux.

Ce billet ne traite pas du contenu sérialisé stocké à l’intérieur du champ post_content — cela mériterait un billet à part entière. Il s’agit ici de comprendre l’enveloppe : le post type wp_template lui-même, ses champs, et ce qu’ils signifient.

Un post type comme un autre, presque

Le plugin Gutenberg enregistre wp_template via la fonction register_post_type(), exactement comme n’importe quelle extension enregistrerait un type de contenu personnalisé. Il en hérite donc naturellement des révisions, d’un statut de publication, d’un auteur, et de toutes les métadonnées classiques d’un article.

register_post_type( 'wp_template', array(
    'labels'        => array(
        'name' => __( 'Templates' ),
    ),
    'public'        => false,
    'has_archive'   => false,
    'show_ui'       => false,
    'supports'      => array( 'title', 'editor', 'revisions' ),
) );

Le paramètre public à false mérite d’être noté : un gabarit n’est pas censé avoir sa propre URL publique consultable directement, contrairement à une page. Il est chargé en coulisses, au moment où WordPress décide quel affichage utiliser pour une requête donnée.

Le slug comme identifiant fonctionnel

Le champ le plus important d’une entrée wp_template n’est pas son titre, lisible par un humain, mais son slug. C’est lui qui fait le lien avec la hiérarchie de gabarits : un slug single, archive ou 404 reprend directement les noms que les développeurs de thèmes classiques connaissent déjà depuis des années.

Cette continuité n’est pas un hasard : elle permet à un développeur habitué à la hiérarchie de fichiers PHP de retrouver ses repères, même si le gabarit vit désormais comme une ligne de base de données plutôt que comme un fichier sur le disque.

Un statut publish qui ne veut pas dire la même chose

Pour un article, le statut publish signifie « visible publiquement ». Pour une entrée wp_template, il signifie simplement « ce gabarit est actif et remplace la version fournie par le thème ». Il n’y a pas de notion de mise en ligne au sens habituel : un gabarit publié n’apparaît nulle part tant qu’aucune requête ne correspond à son slug.

• Un gabarit à l’état draft est ignoré, comme s’il n’existait pas.
• Un gabarit à l’état publish prend le pas sur le fichier équivalent fourni par le thème.
• La suppression d’une entrée wp_template fait automatiquement retomber WordPress sur le fichier du thème, sans configuration supplémentaire.

Ce que cela change pour un développeur curieux

Comprendre ce modèle de données permet de dédramatiser ce qui, vu de l’interface, ressemble à de la magie. Un gabarit modifié depuis l’éditeur de site expérimental n’est jamais qu’un article de plus dans la table wp_posts, avec un type particulier. On peut l’interroger avec WP_Query, le sauvegarder avec wp_insert_post(), ou le supprimer avec wp_delete_post(), exactement comme n’importe quel contenu.

Rien n’est plus rassurant, pour aborder une fonctionnalité expérimentale, que de découvrir qu’elle repose sur des mécanismes vieux de plus de quinze ans.

Une prudence à garder

Ce modèle reste, à cette date, propre au plugin Gutenberg et non encore intégré au cœur de WordPress. Son enregistrement précis, ses arguments et son comportement pourraient évoluer avant une éventuelle fusion officielle. Un développeur qui construit dès maintenant des outils autour de ce post type doit garder cette réserve à l’esprit, et prévoir que certains détails changent d’une version du plugin à l’autre.

En résumé

Le post type wp_template ne réinvente rien : il applique le modèle de données déjà connu des articles à un nouvel usage, celui des gabarits d’affichage. Cette continuité technique explique en grande partie pourquoi ce système, malgré son caractère expérimental, s’intègre déjà si naturellement au reste de WordPress.