Gallery Field (PRO)

Many files in one field, ordered by dragging. Each gets its own title and description, and is edited separately.

Settings: source and file path as for a file, and the filename strategy as for an image. Nothing else is needed — uploaded pictures go through the same automatic conversion an image field uses.

Thumbnails and Groups are leftovers that do nothing in 3.0

The field editor still shows a Thumbnails box with a JSON example in its hint, and a collapsible Groups fieldset. Neither is wired to anything: the JSON is saved and never read, the fieldset is empty, and the per-file group picker is switched off, so groups always comes out blank. Thumbnails for the manager grid are generated on the fly by Glide at a fixed 100×80 WebP; for the page, size the pictures in your own template.

Deleting a file

Two separate row actions, and the difference matters:

Action	What it does
Remove from list	Drops the row only — the file stays in the media source
Delete file	Drops the row and deletes the file from disk

Both work on a selection as well as on one row. There is no system setting behind this — the choice is made per deletion.

Output is an array; each item carries the same keys a file does, plus type, preview and groups:

<div class="gallery">
    {foreach $images as $image}
        {if $image.type === 'image'}
            <img src="/{$image.url}" alt="{$image.title ?: $image.name}">
        {/if}
    {/foreach}
</div>

A gallery holds any files, not only pictures

A video, a PDF and a photograph can live side by side; type tells them apart, and a video can be given a poster of its own in Preview. That is what makes branching on type in the loop worth the trouble.

Rows live in their own table, and that has consequences

Files are stored separately from the record, not inside its value. Hence "required" is hidden for this type — there is nothing on the record to check — and a gallery is skipped when resource and user section values are saved.