Taxonomy-backed options for repeater select sub-fields

[swissky]

Follow-up to #1657 (searchable combobox for repeater select sub-fields), whose code comment already anticipates "taxonomy-derived options".

Problem: A repeater select sub-field can only offer a static option list duplicated in the collection schema. For options that mirror a taxonomy (e.g. a services repeater picking from a treatment taxonomy), the list drifts out of sync as terms are added/renamed.

Proposal: When a select sub-field's options is the single sentinel @taxonomy:<name>, populate its (already searchable) combobox with that taxonomy's live terms via the existing GET /taxonomies/:name/terms API. Purely additive — any leading non-sentinel option keeps the current static behavior; stored values remain term labels.\n\nImplementation is minimal (admin-only, reuses fetchTerms + the existing Combobox markup). PR ready at #1704. Opening this per the Feature/Discussion policy — happy to adjust the API shape (e.g. a typed optionsTaxonomy field instead of the string sentinel) if preferred.

[ascorbic]

I'm not keen on the sentinel-based approach. It's fragile, and every other consumer of options would need special handling or they'd just see it raw. I think the better approach is a taxonomyTerm subfield type, which includes a taxonomy field. Can you propose an approach like that

[MA2153]

I like this feature.

Can we also make it possible to enforce a depth range for hierarchical taxonomies? For example:

• Europe
  • Switzerland
  • United Kingdom
• North America
  • Canada
  • United States

We should be able to prevent users from selecting Europe or North America if we expect them to select a particular country.

[swissky]

Here is a concrete taxonomyTerm proposal, following your suggestion. If the shape looks right I'll implement it and open a PR replacing #1704.

Schema

Add "taxonomyTerm" to REPEATER_SUB_FIELD_TYPES and extend RepeaterSubField:

interface RepeaterSubField {
	slug: string;
	type: "string" | ... | "select" | "image" | "taxonomyTerm";
	label: string;
	required?: boolean;
	options?: string[];   // select only (unchanged)
	taxonomy?: string;    // taxonomyTerm only (required): taxonomy name
	termDepth?: { min?: number; max?: number }; // taxonomyTerm only, optional
}

No sentinel, no special-casing in options consumers — select stays exactly as it is.

Stored value

Store the term slug (not the label): stable across label renames — which is the drift problem that motivated this — and still readable in the entry JSON. Alternative would be the term id (survives slug edits, but opaque in data and awkward for front-end queries). Happy to go either way; slug is my default.

Admin UI

Reuses the searchable Combobox path that #1657 added for select sub-fields, but with live items from the existing GET /_emdash/api/taxonomies/:name/terms, scoped to the entry's locale — the same fetchTerms pattern TaxonomySidebar already uses. Display the label, store the slug. For hierarchical taxonomies, indent items by depth like the sidebar tree.

Depth range (@MA2153's request)

Optional termDepth: { min?, max? } (root = 0) for hierarchical taxonomies. In the combobox, out-of-range levels stay visible for navigation but are disabled (e.g. continents render as non-selectable group rows when min: 1 expects a country). Depth is computed from the parentId chain, which the terms endpoint already returns.

Validation

• Schema level: taxonomy is required for taxonomyTerm sub-fields and must name an existing taxonomy.
• Save level: the value must resolve to an existing term of that taxonomy in the entry's locale (and satisfy termDepth when set, recomputed server-side). Empty is allowed unless required.

Non-goals for v1

Multi-term sub-fields, creating terms inline from the combobox, and any write-path coupling (assignments still live in content_taxonomies; this sub-field is just a value that references a term).

Purely additive; nothing changes for existing schemas. Does this shape work for you?

[rob-j-oliver]

Plus one from me!