Complete the reference field: collection picker in schema editor + content picker in content editor

[Pouf5]

Current state

The reference field type exists throughout the codebase as a recognized type, but the admin UI was never built out. The scaffolding is all there — the type is defined, the DB column type is mapped, the manifest correctly surfaces kind: "reference" for DB-backed fields — but neither the schema editor nor the content editor has the UI to make it usable.

What's missing

1. No collection picker when creating a reference field

FieldEditor (the dialog for adding fields to a collection) has type-specific configuration UI for select/multiSelect (options list), string/text (min/max length, pattern), and number/integer (min/max value). For reference, there is no step to select which collection the field points to.

FieldWidgetOptions already has collection?: string with the comment "For reference - which collection to reference", but it's never populated because the UI to collect it doesn't exist.

2. Plain text input instead of a content picker when editing content

ContentEditor's FieldRenderer has a switch (field.kind) with cases for all the common types. There is no case "reference":. It falls through to default:, which renders a plain <Input> — so editors currently see a free-text box and would have to type a raw content ID by hand.

ContentPickerModal already exists (it's wired up in MenuEditor for picking menu items) and is fully capable of browsing collections with search and pagination. It just isn't wired into ContentEditor for reference fields.

3. isReference marker missing in the static field helper

fields/reference.ts returns a plain z.string() schema with no isReference flag. The manifest handler in api/handlers/manifest.ts checks schema.isReference to detect reference fields in the static live.config.ts path — but since the flag is never set, that check never fires. Fields defined statically via reference() would get kind: "string" in the manifest instead of kind: "reference". (The DB-backed path is unaffected — it uses FIELD_TYPE_TO_KIND directly and correctly maps to "reference".)

Design questions that need answers before implementation

• Can the target collection be changed after field creation? Field slugs are immutable; it's worth deciding whether the options.collection pointer should be too.
• Should the content picker filter to published items, draft items, or all? The current ContentPickerModal shows all statuses.
• Reverse links / link-back? Should EmDash track "which items reference this item"? There's currently no indexing or query support for it.
• allowMultiple? FieldWidgetOptions already has allowMultiple?: boolean for reference fields. Should multi-reference be in scope here or deferred?

What a complete implementation would involve

1. Add a collection selector step to FieldEditor when selectedType === "reference", persisting the chosen collection to options.collection.
2. Add case "reference": to ContentEditor's FieldRenderer, opening ContentPickerModal (or a similar picker) filtered to the collection stored in field.options.collection.
3. Fix fields/reference.ts to tag the schema with isReference: true so the static manifest path works correctly.

[einfachai]

I would vote a implementation like this: Target collection should not be immutable. The content picker should show all status. Reverse links are useful but not needed in the first implementation. Multiple references should be supported in the future at least.

[Pouf5]

Thank you for sharing. Some questions:

• Could you explain why the target collection should be immutable? I don't think that's even a thing.
• I think multiple references could in theory be implemented using the repeater field but worth double checking.

[einfachai]

"Could you explain why the target collection should be immutable? I don't think that's even a thing."
Since existing fields can't be assigned to other post types, I just thought they should be immutable, but after thinking about it, I think it's not a good decision, since you would need a lot of duplicated fields if you have a lot of post types that share a field with the same functionality and name. So I will edit my post and say they shouldn't be immutable, so it can be later implemented that you can assign the same field to multiple post types.

[rob-j-oliver]

Coming from this as a content editor, rather than a developer, I'd love to see something like Voxel's (WP) implementation of their Reference Field, as a future goal. https://docs.getvoxel.io/articles/post-relation-field-2/