Set menu
A set menu is a fixed-price menu where the guest chooses: a starter from this list, a main from that one, a dessert from a third. Fenómenus models it as one record for the menu, plus a separate pool of dishes the blocks can offer.
Two things to maintain
| What | Where |
|---|---|
| The menu itself — its blocks, its price, its footer | Set menu → All items |
| The dishes guests choose between | Set menu → Set menu dishes |
The dishes live in their own content type with its own categories, reachable as Set menu dishes and Set menu dishes category under the Set menu entry. They exist so that the same dish can be offered inside several blocks and several menus without being copied.
How the menu record is built
| Field | Purpose |
|---|---|
| Title | The menu name — Menu of the day, Weekend menu |
| Subtítulo | A short qualifier — the days it runs |
| Descripción | The introduction |
| Título del bloque "Entrantes" and Platos en "Entrantes" | The starters block and the dishes it offers |
| Título del bloque 1, 2, 3, each with its Platos en el bloque | The remaining choice blocks |
| Nota al pie | The footer note |
| Precio menú | The fixed price of the menu |
Each Platos en… field selects records from the set-menu dish pool. That is the difference from a tasting menu: a tasting menu block tells the guest what arrives, a set menu block offers a choice.
Set menus have no pairing price. That field belongs to tasting menus.
Building one
- Create the dishes first, under Set menu dishes, with their categories.
- Create the menu record under All items.
- Name each block — Starters, Main course, Dessert.
- In each block, select the dishes that block offers.
- Enter the menu price.
- Write the footer note.
- Publish.
Naming a block but leaving its dish selection empty produces a block with nothing to choose from. Leave unused blocks entirely empty instead.
The daily menu problem
A menu of the day changes every day, and there are two supported ways to run it:
One permanent record, edited daily. Keep a single Menu of the day record and change the dishes selected in each block every morning. Guests always use the same URL and the same QR code. This is the practical choice for most restaurants.
One record per menu. Keep several set menus published at once — a weekday menu, a weekend menu, a group menu — each with its own address. Use this when the menus coexist rather than replace each other.
Whichever you choose, keep the dish pool tidy: dishes that come back every few weeks stay in the pool, so building tomorrow's menu is a selection rather than typing.
Prices
The set menu carries one price: Precio menú. The dishes inside it carry no prices of their own, because the guest is not buying them individually.
If a block offers a dish with a supplement, say so in the block title or the footer note. There is no per-choice supplement field.
The footer note
Use Nota al pie for what a fixed-price menu legally and practically needs: whether VAT is included, which days and services it is available, whether bread and drinks are included, and where allergen information can be requested.
Public design
Set menus use Menu design 1 or Menu design 2, chosen when the menu type is enabled. The item layouts are not offered, because a set menu is read as one document.
The dish pool has its own presentation inside those designs; it is not published as a separate browsable archive for guests.
Allergens
Allergen information is enabled for both the set menu and its dish pool. Assign allergens on the dishes themselves — that is where the information is precise — and keep a general line in the footer note.
Translations
The menu title, subtitle, description, block titles and footer note are translated per language. The dishes are separate records and are translated as such. Prices and the dish selection are shared, so a translated menu offers exactly the same choices.