Listings
A listing answers a question about your records and renders the answer. The same listing definition can produce a page, a block on another page, a table, an RSS feed, a calendar or a kanban board — because what to show and how to show it are separate decisions.
Back office → Structure → Listings.
The parts
| Part | Decides |
|---|---|
| Source | Which records — content type, vocabulary, or another agenda |
| Filters | Which of them — published, in a category, above a price |
| Path filters | Filters taken from the address, so one listing serves many pages |
| Sorts | In what order |
| Fields | What is shown of each record |
| Displays | Where it appears: page, block, feed, table, calendar, board |
| Pager | How many, and how the rest is reached |
Path filters are the powerful part
A path filter takes its value from the address. One listing, one definition, serves every category page you will ever have.
Each path filter decides three things worth understanding:
- When the value is missing — show everything, show nothing, or return not-found. The right answer differs per listing and getting it wrong is how a category page becomes a list of the entire catalogue.
- Whether to validate — a value that is not a real term can be refused cleanly instead of silently matching nothing.
- Whether to include children — "under Inverters" versus "exactly Inverters".
A non-existent term is not a server error
A filter given a value that cannot be a term returns a clean not-found. If you meet an error page instead, report it.
Filters that depend on each other
An exposed term filter can be narrowed by another exposed filter through a field on its terms: the district filter narrowed by the region filter through the district's "Region" field. Once a visitor picks a region, the district select offers only that region's districts; nothing picked, and every district is offered. Switch on the form's auto-submit and the page follows the region choice on its own.
This is configuration on the filter ("Narrow by another filter" + "Through the field"), which is why it works for any two vocabularies whose terms point at each other — product groups and products, brands and models — not only for places.
One of several values
A text filter can take Is one of: a comma-separated list, each value
compared like Is equal to. One listing then spans several types — an
"All hardware" page over boards, modules, chips and devices filters the
type machine name by board, module, component, device — without a
listing per type.
Displays
One definition, several appearances:
- Page — a listing at its own address
- Block — placed on other pages through the layout
- Table — columns, sortable headers
- Feed — RSS for readers and aggregators
- Calendar — anything with a date
- Board — kanban columns from a term field, drag to change
Embedding
A listing can be placed inside a page. It is also the one place where care is needed:
A listing must not embed itself
Directly or through a chain. The platform refuses beyond a small depth and reports the refusal, because the alternative is a page that renders the same panel a thousand times. The symptom is memorable: a page that takes a minute to load while every single query is fast.
Fields, and the link that is not always wanted
Each field in a listing has a formatter, and a field can be rendered as a link to the record or as plain text. Turning the link off is a per-field setting — a title is not automatically a link just because it is a title.
A column with no formatter chosen falls back to its kind's default. For a date-and-time column that default is Date and time, which reads the platform's display clock — the timezone on the system settings screen. Set that once and every listing agrees.
If a time reads a couple of hours out, this is why
Datetimes are STORED in UTC, always, and converted for display. Until 2026-09-10 a date-and-time column with no formatter picked skipped the conversion and printed the stored value, so the same moment could read 04:14 on one screen and 06:14 on another where somebody had chosen a formatter by hand. The setting was never the problem — that path simply never asked it. Nothing needs configuring now, and a column where you did choose a formatter behaved correctly all along.
A listing belongs to a firm
Every listing belongs to one firm, or to all of them when no firm is named. That decides what its editor offers you: your content types, your fields, your relationships, your vocabularies, plus anything the platform shares with everybody. Another firm's configuration is never offered, and another firm's listing cannot be opened by address at all.
Why this reads as a fix rather than a feature
Until 2026-09-15 the field chooser offered the fields of every firm on the
installation, under machine names that read as nonsense, while a term
filter could be handed another firm's vocabulary because both firms had
called it topics. The reason was one layer deep: a field's STORAGE has no
firm by design (it is one row per content type), and the choosers asked
storage instead of asking which content types a firm actually has the field
on. They ask correctly now.
What follows from the rule, in the screen:
- the column, filter, argument, relationship, kanban-group, calendar-date and map-geo choosers list your fields, under the labels you typed;
- a term filter offers the terms of YOUR vocabulary of that name;
- the preview shows your records;
- saving refuses a content type or a field that is not yours;
- the organization selector offers only firms you work for;
- a platform operator with no firm open still sees everything, because that is the operator's surface.
AJAX
Filters, sorting and paging can update in place without a page load. Switch it on per display when the listing is a tool rather than a page.