Menus, taxonomies et zones de widgets : qui range quoi dans un site EmDash

Quelqu’un qui arrive de WordPress trouve ses articles dans l’administration d’EmDash sans difficulté. Il cherche ensuite trois choses : le menu de navigation, la colonne latérale, et les catégories. Les trois existent, sous d’autres noms — et EmDash en ajoute deux autres qui se recoupent partiellement avec elles.

La difficulté n’est donc pas d’apprendre à s’en servir : chaque mécanisme est simple pris isolément. Elle est de savoir lequel des cinq correspond au besoin du moment, parce que trois d’entre eux peuvent afficher le même encart en bas de page, avec des conséquences très différentes six mois plus tard.

Ce guide fait le tri. Les faits techniques viennent des pages de la documentation officielle du projet, nommées au fil du texte ; la façon de les articuler est notre lecture.

Les taxonomies : classer

Une taxonomie, dit la page Taxonomies de la documentation, est « une classification nommée appliquée à une ou plusieurs collections ». C’est la reprise directe du concept WordPress, avec la même distinction entre les deux formes livrées d’origine : EmDash démarre avec la taxonomie hiérarchique category et la taxonomie plate tag, toutes deux appliquées aux articles.

La suite est plus souple qu’avec WordPress. Vous pouvez déclarer vos propres taxonomies — genre, difficulte, region — et c’est la définition de la taxonomie qui décide à quelles collections elle s’applique, donc dans quels formulaires d’édition son panneau apparaît. Un détail à connaître avant de nommer : la documentation impose des noms qui « commencent par une lettre minuscule et ne contiennent que des lettres minuscules, des chiffres et des tirets bas ».

Deux points méritent une attention particulière.

Les pages d’archives ne se créent pas toutes seules. Une taxonomie classe le contenu et permet de l’interroger ; ce sont des routes Astro écrites dans le thème qui produisent les pages /category/[slug]. Rien n’apparaît tant que la route n’existe pas, et la documentation prévient qu’il faut construire les liens à partir du urlPattern réel de la collection plutôt que de supposer une forme d’URL par défaut. C’est aussi à ce moment qu’on décide ce qui doit être indexable, un arbitrage que nous détaillons dans le guide du référencement d’un site EmDash — un site qui ouvre à l’exploration une archive par étiquette produit très vite des dizaines de pages quasi vides.

Supprimer un terme n’est pas anodin. La page Taxonomies est explicite : « Supprimer un terme retire ses assignations du contenu. Cela ne supprime pas les entrées de contenu. » Vos articles restent donc en place, mais ils perdent silencieusement leur classement, et toute page qui listait ce terme se vide. Sur un site multilingue, où chaque langue porte ses propres termes, la précaution vaut double — voir notre guide des sites EmDash multilingues.

Les menus : conduire

Un menu EmDash porte « un nom stable, comme primary ou footer », et possède un jeu d’éléments distinct pour chaque traduction, selon la page Navigation Menus. L’éditeur ajoute des liens vers du contenu ou des URL libres, les réordonne, et crée un niveau d’imbrication en désignant un parent.

Le point de conception qui change tout tient en une phrase : les éléments de menu stockent des références, pas des URL finies. C’est la fonction getMenu() qui les résout au moment du rendu, à partir du motif d’URL de la collection ou des données de taxonomie, et qui renvoie pour chaque élément son libellé, sa cible éventuelle, ses classes CSS et ses enfants.

La conséquence pratique est excellente : le jour où vous décidez que vos articles vivent sous /blog/ et non plus sous /articles/, les menus suivent sans être retouchés. Elle a un corollaire moins confortable — un élément de menu pointant vers un contenu supprimé n’est plus une ligne de texte inoffensive, c’est une référence à résoudre. Ce qui rejoint la règle que nous appliquons partout : on ne supprime pas, on redirige, comme dans le tutoriel sur les redirections après migration WordPress.

Côté thème, l’exemple de la documentation rend la navigation principale avec un seul niveau d’enfants, « ce qui couvre un menu déroulant classique ». Rien n’interdit d’aller plus profond si vos composants le gèrent, mais le cas standard s’arrête là. Sur un site traduit, c’est la fonction menuHref() qui se charge du préfixe de langue.

Les zones de widgets : la colonne latérale, à l’envers

Une zone de widgets est, selon la page Widget Areas, « une position nommée dans un gabarit du site », où l’éditeur contrôle le contenu pendant que le gabarit garde la main sur l’emplacement et le style. Trois types d’éléments s’y placent : du contenu (du Portable Text saisi par un éditeur), un menu désigné par son nom, ou un composant parmi ceux fournis — articles récents, catégories, étiquettes, recherche, archives.

Le thème les affiche avec le composant WidgetArea importé depuis emdash/ui, qui récupère la zone demandée, respecte l’ordre configuré, et « ne rend rien lorsque la zone est absente ou vide ».

Et c’est là qu’il faut s’arrêter, parce que le mécanisme fonctionne dans le sens inverse de WordPress. Sous WordPress, le thème déclare une sidebar et celle-ci apparaît dans l’administration. Ici, la zone se crée dans l’administration, sous Widgets, avec un nom de requête et un libellé — mais elle ne s’affichera nulle part tant qu’un gabarit ne l’appellera pas par ce nom. Une zone remplie et invisible n’est pas un bug : c’est un gabarit qui ne la demande pas. C’est le premier réflexe à avoir quand un encart « ne sort pas », et une chose à prévoir dès la conception d’un thème, comme décrit dans le guide de création d’un thème sur mesure.

Les sections : un point de départ qu’on recopie

Les sections sont « des groupes réutilisables de blocs Portable Text ». L’éditeur les insère en tapant /section dans un champ de texte riche et en cherchant par titre, description ou mot-clé — et il en reçoit une copie indépendante, qu’il peut ensuite modifier sans toucher à l’original de la bibliothèque.

C’est exactement l’inverse d’une zone de widgets. La documentation le formule sans détour : utilisez une section « pour des points de départ répétables, comme un appel à l’action, une biographie d’auteur ou une mention standard », et une zone de widgets « lorsqu’une valeur gérée de façon centralisée doit se mettre à jour partout où elle apparaît ».

Les sections étant du Portable Text, tout ce qui vaut pour ce format vaut pour elles — leur structure reste interrogeable et transformable, ce que nous développons dans le guide du Portable Text.

Les layouts de page : laisser choisir l’éditeur

Dernier mécanisme, et le seul qui ne soit pas un objet du cœur d’EmDash. La page Page Layouts décrit une convention : on ajoute un champ select à la collection des pages, on écrit un composant Astro par variante — « Défaut », « Pleine largeur », « Page d’atterrissage » — et la route associe la valeur du champ au composant.

L’éditeur choisit alors sa mise en page dans un menu déroulant, sans toucher au code. C’est aussi le point où l’on décide qu’une variante affiche une colonne latérale et donc une zone de widgets, et l’autre non.

La règle qui permet de choisir

Cinq mécanismes, une seule question à se poser. Si je modifie cet élément dans six mois, est-ce que je veux que les pages déjà publiées changent ?

Si la réponse est oui, l’élément doit vivre à un seul endroit et être appelé partout : c’est une zone de widgets, un menu, ou une taxonomie. Si la réponse est non — chaque page garde ce qu’elle avait le jour de sa rédaction —, c’est une section.

Le reste se déduit :

un classement qui doit produire des listes, des filtres et des archives : taxonomie ;
un chemin de navigation choisi à la main, dans un ordre voulu : menu ;
un encart identique partout, modifiable sans republier les pages : zone de widgets ;
un bloc récurrent que chaque page adapte : section ;
une variante de gabarit laissée au choix de l’éditeur : layout de page.

Et un dernier cas, souvent mal rangé dans les quatre premiers : le nom du site, son logo, le nombre d’articles par page, le fuseau horaire, le séparateur de titre. Tout cela relève des réglages du site, que les gabarits lisent avec getSiteSettings(), et dont la documentation rappelle qu’ils « sont facultatifs tant qu’ils ne sont pas configurés » — un thème sérieux prévoit donc une valeur de repli pour chacun.

Ce que cela change à la migration

La page EmDash for WordPress Developers donne la table de correspondance : les types de contenu deviennent des collections, les métadonnées deviennent des champs, les catégories et étiquettes deviennent des taxonomies, wp_nav_menu() devient getMenu(), les sidebars deviennent des zones de widgets, et l’API Options devient les réglages du site.

Cette table est juste, mais elle décrit une équivalence de concepts, pas un import automatique. Ce qui traverse la migration, c’est le contenu et son classement ; ce qui ne traverse pas, c’est l’emplacement. Aucune sidebar ne se recrée toute seule à droite de vos articles, parce que sous EmDash c’est le gabarit qui décide où une zone s’affiche. Prévoyez ce travail dans le plan, au même titre que les redirections — notre dossier complet sur le départ de WordPress et le tutoriel de migration le placent à l’étape d’adaptation du thème, et c’est le bon endroit.

Si vous en êtes encore à évaluer le passage, la comparaison d’ensemble se lit dans notre guide EmDash face à WordPress. Et si vous partez d’un site neuf, le plus économique est de fixer ces cinq choix avant d’écrire le premier article : ils sont faciles à poser, pénibles à défaire une fois deux cents pages publiées.

Pour aller plus loin

Les pages citées — Taxonomies, Navigation Menus, Widget Areas, Sections, Page Layouts, Site Settings et EmDash for WordPress Developers — sont la référence qui fait foi, et elles évoluent au rythme du projet : vérifiez-y les noms de fonctions le jour où vous écrivez le code.