Menu de saison par service, en Query Loop, pour un restaurant

Deux pages entièrement distinctes pour un seul et même catalogue de plats : voilà à quoi ressemble, dans bien des cas, le site d’un établissement qui sert une formule le midi et une carte plus élaborée le soir. Une pour le déjeuner, une pour le dîner, sans lien entre les deux. Résultat concret : un plat retiré de la carte le midi reste parfois affiché le soir par oubli, et inversement.

Le constat technique est simple : les plats ne changent pas de nature entre midi et soir, seule leur disponibilité change. Cela suggère une architecture à source unique — un seul type de contenu pour tous les plats — avec un filtrage différent selon le gabarit consulté.

Un type de contenu « plat » avec une taxonomie « service »

Chaque plat est un article du type personnalisé plat, classé dans une taxonomie service qui compte exactement deux termes : midi et soir. Un plat peut appartenir aux deux termes à la fois s’il est servi toute la journée, ce qui règle élégamment le cas des plats permanents comme la salade du chef.

register_taxonomy( 'service', 'plat', array(
    'label'        => 'Service',
    'hierarchical' => false,
    'show_in_rest' => true,
) );

Chaque plat porte également une métadonnée plat_prix et éventuellement plat_allergenes, exposées en REST comme n’importe quel champ personnalisé destiné à s’afficher dans le bloc Post Template.

Deux gabarits, une seule Query Loop réutilisée

Dans l’éditeur de site, deux gabarits de page personnalisés sont créés : « Menu midi » et « Menu soir ». Chacun contient une Query Loop identique dans sa structure d’affichage (les mêmes blocs pour le nom, le prix, la description), mais avec un filtre de taxonomie différent réglé dans le panneau latéral du bloc :

• Le gabarit « Menu midi » filtre la Query Loop sur le terme midi de la taxonomie service.
• Le gabarit « Menu soir » filtre sur le terme soir.

Comme les deux Query Loop pointent vers le même type de contenu plat, la mise à jour d’un plat (nouveau prix, nouvelle description) se fait à un seul endroit et se répercute instantanément sur le gabarit concerné, sans double saisie.

Réutiliser la structure d’affichage sans dupliquer le travail

Pour éviter de reconstruire deux fois la mise en forme du bloc Post Template (typographie du nom du plat, alignement du prix, icônes d’allergènes), la structure interne de la Query Loop peut être extraite sous forme de motif synchronisé, inséré dans les deux gabarits. Une modification de la mise en forme du motif se répercute alors simultanément sur le menu midi et le menu soir, sans reprise manuelle des deux Query Loop.

Gérer les plats saisonniers avec une seconde taxonomie

Un plat n’est pas toujours disponible toute l’année. Une seconde taxonomie, saison, avec des termes comme hiver ou ete, permet de croiser les deux filtres. Le réglage du bloc Query Loop autorise un filtrage cumulé sur deux taxonomies distinctes, ce qui évite d’avoir à retirer manuellement les plats d’été de la carte chaque automne : il suffit de changer le statut de publication ou le terme de saison sur la fiche du plat concerné.

<!-- wp:query {"query":{"taxQuery":{"service":["midi"],"saison":["hiver"]}}} -->
<!-- wp:post-template -->
<!-- wp:post-title /-->
<!-- wp:post-excerpt /-->
<!-- /wp:post-template -->
<!-- /wp:query -->

Ce que cette architecture ne couvre pas

La réservation de table, la gestion des allergènes sous forme de filtre interactif côté visiteur, ou l’affichage d’un menu en plusieurs langues restent hors périmètre de cette solution, qui se concentre uniquement sur la centralisation de la carte et sa déclinaison par service.

Situation	Terme service
Plat uniquement au déjeuner	midi
Plat uniquement au dîner	soir
Plat servi toute la journée	midi et soir

Un menu affiché en double, sans source commune, finit toujours par se désynchroniser : c’est une question de temps, pas de rigueur du personnel.

En résumé

Un seul type de contenu, une taxonomie à deux termes et deux gabarits qui réutilisent la même logique d’affichage suffisent à remplacer deux pages de menu maintenues séparément. Le gain n’est pas seulement technique : il élimine un risque d’erreur qui touche directement la satisfaction des clients du restaurant.