Query

The Query block pulls a set of posts or pages from the database and displays them, the engine behind a blog index, a portfolio, a product grid, or any list of content.

You set the query, what to fetch and in what order, then design a single Query Template, the layout for one item, which Slowly repeats for every result. Pagination blocks let visitors move through long sets.

This is dynamic content, so the layout is built once and fills itself from your posts. The look comes from the design panel.

Adding one

Select the section or container to hold the list.
Open the inserter and search "query".
Pick the Query block, then open its settings panel to choose what to fetch.

Settings

In the query's own panel. The design panel controls layout and visual treatment separately.

Setting	What it does	Reach for it when
Type	What to fetch: posts, pages, custom post types, users, comments, taxonomy terms, or a data source (an external JSON feed, see below)	Matching the query to whatever you are listing
Posts per page	How many results appear per page (default 10)	Shortening a long archive or showing a fixed number in a grid
Order	Ascending or descending	Reversing a chronological list, or showing oldest first
Order by	The field used to sort, such as date, title, menu order, or a meta key	Sorting a portfolio by a custom field, or a directory alphabetically
Offset	Skip the first N results	Showing "the rest" when the first result is already featured elsewhere
Max items	Cap the total results regardless of pagination	A "latest three" block that never grows
Exclude current	Leave out the post the visitor is currently reading	Related-posts blocks on single post pages
Sticky posts	Include, exclude, or only show posts marked sticky	Pinning announcements to the top of a blog
Taxonomy filter	Narrow by category, tag, or any custom taxonomy	Category archives, tag pages, or filtered product grids
Meta filter	Narrow by a custom field value	Filtering events by a date field, or products by a feature flag
Date filter	Restrict to a date range	Surfacing recent items or archiving old ones
Infinite scroll	Load more results as the visitor scrolls, instead of using pagination	Long feeds where you want uninterrupted browsing
Skeleton	Show a placeholder shape while results load (on by default)	Keeping the layout stable during the first paint

Querying a data source

A query can iterate a JSON array from a registered data source instead of the database. Each item in the array becomes a card, the same way each post does, so an external feed (a headless CMS, a published sheet, an n8n or Nextcloud Tables endpoint) renders as a repeating layout with per-row content.

Set the query Type to Data source, then pick a registered source and give the array path in dot notation, the key that holds the list. If the feed is { "rows": [ ... ] }, the path is rows. Per Page and Offset work as they do for posts; pagination blocks work unchanged.

Binding to a row's fields

Inside the Query Template, bind any text block to a field of the current row. In the block's dynamic content, pick Data Source Row as the source, then choose the field from the dropdown, which lists the keys read straight from the feed, so there is nothing to remember. For a nested value, choose Custom path and type the dot path (author.name).

Field names come from the live data, and both the row values and a placeholder for anything missing show in the editor canvas while you build, matching how a post query previews. The feed is fetched once, cached, and resolved on the server, so keys and headers never reach the browser.

Data sources are read with GET, and the feature is still marked experimental. Endpoints that need POST (such as a Notion database query) are not supported yet.

Styling

The query wrapper itself takes the full design panel: layout, spacing, colour, and effects, each per breakpoint. The per-item look is set on the Query Template inside it. For load-state appearance, the skeleton placeholder inherits the template's dimensions.

Accessibility

Pagination controls need descriptive labels so keyboard and screen-reader users can tell which page they are on and where each link goes. Use the Pagination block's label settings rather than leaving controls as bare numbers. If infinite scroll is on, consider whether visitors who rely on keyboard navigation or who have reduced-motion preferences can still reach all content, a "Load more" button is generally more accessible than automatic scroll-triggered loading.