Addons can extend fieldtype configuration with appendConfigField(s), but there is no equivalent for the Edit Set stack inside Replicator/Bard's Manage Sets editor.
A set definition can have site-specific configuration, such as editorial guidance or metadata consumed by an addon. This belongs alongside that set's display name, instructions, icon, preview image, and hidden setting. Currently an addon must put a separate mapping on the parent field, replace editor components, or ask developers to edit YAML manually.
There is also a persistence problem with the YAML approach: Sets::preProcess() and Sets::process() enumerate the native keys, so custom set configuration is dropped when the field is edited and saved through the Control Panel. For example, an addon_note alongside a set's display and fields does not survive that round trip.
Could core provide a generic way to append native configuration fields to this stack? An API along these lines would match the existing fieldtype extension pattern:
use Statamic\Fieldtypes\Sets;
Sets::appendSetConfigField('addon_note', [
'type' => 'textarea',
'display' => 'Editorial guidance',
]);The intended scope is reusable set definitions in blueprints and fieldsets, not settings on individual blocks in an entry. The latter is discussed in #1182 and statamic/cms#11720.
I have a proposed implementation that renders native fields in Edit Set for both Replicator and Bard, runs native preprocessing/validation/processing, and preserves the values on save. It also preserves unregistered custom metadata so temporarily disabling an addon does not erase its configuration. Native set keys cannot be overridden through appended fields.
Draft implementation: statamic/cms#15422. It has PHP and Vue regression coverage and passed a browser save/reload test in a local Statamic 6.31.0 site. The PR is open for discussion of the API and persistence scope.
Addons can extend fieldtype configuration with
appendConfigField(s), but there is no equivalent for the Edit Set stack inside Replicator/Bard's Manage Sets editor.A set definition can have site-specific configuration, such as editorial guidance or metadata consumed by an addon. This belongs alongside that set's display name, instructions, icon, preview image, and hidden setting. Currently an addon must put a separate mapping on the parent field, replace editor components, or ask developers to edit YAML manually.
There is also a persistence problem with the YAML approach:
Sets::preProcess()andSets::process()enumerate the native keys, so custom set configuration is dropped when the field is edited and saved through the Control Panel. For example, anaddon_notealongside a set'sdisplayandfieldsdoes not survive that round trip.Could core provide a generic way to append native configuration fields to this stack? An API along these lines would match the existing fieldtype extension pattern:
The intended scope is reusable set definitions in blueprints and fieldsets, not settings on individual blocks in an entry. The latter is discussed in #1182 and statamic/cms#11720.
I have a proposed implementation that renders native fields in Edit Set for both Replicator and Bard, runs native preprocessing/validation/processing, and preserves the values on save. It also preserves unregistered custom metadata so temporarily disabling an addon does not erase its configuration. Native set keys cannot be overridden through appended fields.
Draft implementation: statamic/cms#15422. It has PHP and Vue regression coverage and passed a browser save/reload test in a local Statamic 6.31.0 site. The PR is open for discussion of the API and persistence scope.