Problem
Plugin resource fields currently support only:
text
longtext
number
date
boolean
This makes it difficult for plugin authors to create structured admin forms using host-owned resource pages. Values such as date-times, URLs, media references, and tags must currently be encoded as loosely formatted text.
Some plugins also need structured or repeatable values. For example, an event series may contain recurrence settings and per-occurrence exceptions. Encoding these as text weakens validation, while separate custom admin forms require editor.code.
The alternative is to build a custom admin app, which requires editor.code and runs unsandboxed in the admin window.
Proposed solution
Extend resources[].fields with additional declarative field types and metadata, including:
dateTime, preferably with timezone support
url and email
media or image
select, multiSelect, or tags
- default values
- descriptions, help text, and placeholders
- validation constraints such as min/max, pattern, and URL validation
- validated structured values, such as JSON objects/arrays or repeatable field groups
The same schema should ideally be enforced by both the host-provided admin UI and the plugin storage/API boundary.
Aligning this with the existing CMS content field types where practical would reduce duplication and make the plugin SDK easier to learn.
Alternatives considered
Plugins can store structured values as text or request editor.code and implement their own admin UI. These approaches either reduce data quality or require a higher-trust permission than should be necessary for ordinary resource management.
Area
Plugins
Problem
Plugin resource fields currently support only:
textlongtextnumberdatebooleanThis makes it difficult for plugin authors to create structured admin forms using host-owned resource pages. Values such as date-times, URLs, media references, and tags must currently be encoded as loosely formatted text.
Some plugins also need structured or repeatable values. For example, an event series may contain recurrence settings and per-occurrence exceptions. Encoding these as text weakens validation, while separate custom admin forms require
editor.code.The alternative is to build a custom admin app, which requires
editor.codeand runs unsandboxed in the admin window.Proposed solution
Extend
resources[].fieldswith additional declarative field types and metadata, including:dateTime, preferably with timezone supporturlandemailmediaorimageselect,multiSelect, or tagsThe same schema should ideally be enforced by both the host-provided admin UI and the plugin storage/API boundary.
Aligning this with the existing CMS content field types where practical would reduce duplication and make the plugin SDK easier to learn.
Alternatives considered
Plugins can store structured values as text or request
editor.codeand implement their own admin UI. These approaches either reduce data quality or require a higher-trust permission than should be necessary for ordinary resource management.Area
Plugins