Le WordPress d'aujourd'hui, décodé pour les développeurs

Éditeur de site (FSE)

« Aucun modèle disponible » : un thème rendu hybride sans ses gabarits

L'éditeur de gabarits expérimental affiche une liste vide sur un thème classique tout juste rendu compatible. Le diagnostic tient en quelques fichiers manquants.

Par WordPress Développement • 10 août 2020 • 4 min de lecture • Aucun commentaire
« Aucun modèle disponible » : un thème rendu hybride sans ses gabarits

« Aucun modèle disponible. » C’est le seul message que renvoie l’éditeur de gabarits expérimental, fraîchement activé sur un thème classique auquel un fichier theme.json minimal venait d’être ajouté pour tester la nouvelle vague de fonctionnalités du plugin Gutenberg. Aucune erreur PHP, aucune trace dans les journaux, juste un panneau vide et une interface qui ne propose rien à modifier.

Ce genre de message laconique est caractéristique des fonctionnalités encore jeunes : l’interface a été codée pour un cas nominal, celui d’un vrai thème de blocs, et gère mal les situations intermédiaires comme celle d’un thème classique auquel on ajoute une compatibilité partielle. Comprendre pourquoi demande de revenir sur ce que le mot « hybride » recouvre réellement à ce stade du développement.

Le symptôme observé

Le thème en question restait un thème classique ordinaire : fichiers header.php, footer.php, page.php inchangés, aucune structure de dossier block-templates. Seul un fichier theme.json réduit à une déclaration de palette de couleurs avait été ajouté, dans l’espoir de profiter du nouveau panneau de styles globaux. L’activation du plugin Gutenberg en version de développement a fait apparaître un nouvel élément de menu, « Éditeur de gabarits », qui une fois ouvert affichait une liste totalement vide.

Comprendre ce que cherche l’éditeur de gabarits

À ce stade expérimental, l’éditeur ne lit ni header.php ni aucun fichier PHP du thème : il cherche exclusivement des fichiers HTML rangés dans un dossier dédié, généralement nommé block-templates, chacun correspondant à un gabarit précis (page d’accueil, page générique, article). Sans ce dossier, ou avec un dossier vide, il n’y a tout simplement rien à afficher, quelle que soit la richesse du thème classique existant par ailleurs.

  • La présence d’un fichier theme.json ne suffit pas à transformer un thème classique en thème de blocs complet.
  • Le dossier attendu par le plugin, à ce stade de développement, doit contenir au minimum un fichier index.html.
  • Aucun message d’erreur explicite ne signale l’absence de ce dossier : l’interface se contente d’afficher une liste vide.
L'essentiel à retenir : Comprendre pourquoi la liste des gabarits reste vide ; Vérifier la déclaration du support des blocs dans le thème ; Distinguer thème classique enrichi et vrai thème de blocs

Le correctif appliqué

La solution a consisté à créer un dossier block-templates à la racine du thème, contenant un unique fichier index.html minimal, servant de gabarit de secours pour l’ensemble du site.

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Après ce simple ajout, l’éditeur de gabarits a immédiatement affiché ce fichier index.html comme unique entrée disponible. Restait ensuite à créer les deux fichiers de parties de gabarit référencés, header.html et footer.html, dans le sous-dossier attendu par le plugin, faute de quoi les deux zones restaient désespérément vides à l’affichage.

Prévention pour la suite du projet

  • Ne pas annoncer un thème comme « compatible éditeur de site » tant que le dossier de gabarits n’existe pas, même partiellement.
  • Garder une trace écrite, à ce stade encore mouvant, des noms de dossiers attendus par chaque version du plugin testée.
  • Continuer à maintenir en parallèle les fichiers PHP classiques, qui restent le mode de rendu réel tant que la fonctionnalité n’est pas stabilisée.

Ce que ce cas révèle sur l’état de la fonctionnalité

Ce diagnostic illustre bien à quel point le mot « hybride » est encore flou à ce stade : ajouter un theme.json ne crée aucune passerelle automatique entre le monde PHP classique et le monde des gabarits en blocs. Les deux systèmes coexistent sans réellement communiquer, et c’est justement cette coexistence partielle qui produit des messages d’interface aussi peu parlants qu’« aucun modèle disponible ».

Une interface qui affiche un état vide sans expliquer pourquoi n’est pas forcément cassée : elle peut simplement attendre une structure de fichiers que rien, dans le thème existant, ne suggère encore.

En résumé

Sur un thème classique fraîchement enrichi d’un theme.json, la liste vide de l’éditeur de gabarits ne signale pas un bug du plugin mais l’absence pure et simple de fichiers HTML de gabarits. Le correctif reste modeste, mais il rappelle qu’à ce stade de développement, chaque brique de l’éditeur de site doit être ajoutée explicitement, sans magie ni rétrocompatibilité automatique avec l’existant PHP du thème.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi