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.

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.

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.

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.

Next

Tags
contentviews