Skip to content

[6.x] Allow addons to extend Replicator/Bard set configuration - #15422

Open
eminos wants to merge 1 commit into
statamic:6.xfrom
eminos:feature/extend-set-config
Open

[6.x] Allow addons to extend Replicator/Bard set configuration#15422
eminos wants to merge 1 commit into
statamic:6.xfrom
eminos:feature/extend-set-config

Conversation

@eminos

@eminos eminos commented Sep 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Addons can append fieldtype configuration, but cannot add fields to the Edit Set stack in Replicator or Bard. Custom set metadata added in YAML is also discarded when a field is saved through the blueprint editor.

This adds Sets::appendSetConfigField() and Sets::appendSetConfigFields() for native fields in that stack. Values are stored alongside the set's existing configuration and pass through native preprocessing, validation, metadata loading, and processing. Nested fields are supported. Unregistered custom metadata survives a round trip, including when its addon is temporarily disabled. Reserved native keys cannot be registered or overwritten through the extra configuration values.

use Statamic\Fieldtypes\Sets;

Sets::appendSetConfigFields([
    'addon_note' => [
        'type' => 'textarea',
        'display' => 'Editorial guidance',
    ],
]);

Addresses statamic/ideas#1484. Documentation tracking: statamic/docs#1983. This is configuration on reusable set definitions, separate from content-instance settings discussed in #11720. The core change contains no addon-specific fields.

Validation:

  • 74 PHP tests passed, including new Replicator/Bard field-editor endpoint tests, nested validation, defaults, metadata preservation, rename/reorder/duplicate, and existing Sets/FieldTransformer/Fieldtype coverage.
  • Four Vue tests passed for Cancel, Confirm, isolated defaults, and ordinary blueprint sections.
  • Control Panel production builds passed for current 6.x and a patch applied to v6.31.0.
  • Browser-tested the patch in a local 6.31.0 site with an addon's group containing textarea, list, and YAML fields. Existing guidance loaded, Cancel discarded changes, and Confirm followed by field/fieldset Save persisted the edit through a full reload. The site's original test data was restored afterward.

Draft for discussion of the API and persistence scope, and for further local hands-on testing. Compiled assets are omitted per the contribution guide.

This was referenced Sep 8, 2026
Open
Open
@jasonvarga

jasonvarga commented Sep 29, 2026

Copy link
Copy Markdown
Member

Don't really understand the use case. Can you show a screenshot of how you're actually using this?

@eminos

eminos commented Sep 30, 2026

Copy link
Copy Markdown
Contributor Author

Hey @jasonvarga

I'm working on an addon that needs a bit more context on the Sets of a Replicator.

An addon can already add it's own "config fields" with appendConfigFields() to any Fieldtype, and we have a nice UI when editing a Set (a Stack), but there is no way to add any config fields to it. This PR adds that possibility.

Here's a screenshot.

image

@eminos
eminos marked this pull request as ready for review September 30, 2026 12:05
@jasonvarga

jasonvarga commented Sep 30, 2026

Copy link
Copy Markdown
Member

And what do you do with the editorial settings once you've filled them out?

@eminos

eminos commented Sep 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Could one not ask the same for the Fieldtype "config fields" that we already have?
Whatever an addon wants to do with them, I guess.

The "Editorial settings" was just an example for the screenshot. To keep that example going, the addon in this case could be some UI extending the Replicator/Sets. Could also be something that's run on the server where it just needs more context for the Sets. I guess it could just be some "hidden fields" inside the Set itself, but that's not as clean for this use case.

Essentially just a way to add some arbitrary "meta data" to Sets, that's also editable from the CP.

@jasonvarga

jasonvarga commented Sep 30, 2026

Copy link
Copy Markdown
Member

Could one not ask the same for the Fieldtype "config fields" that we already have?

I've seen it used for:

  • customizing front-end form field templates so the new config values can influence how they are rendered
  • custom php code to pull config values out programmatically to mark fields as a/b testable, for example

This to me looks like you just want to put information FOR the content authors. Why not just put stuff into the instructions of a set config and plop an info field in the set itself. Then you'll see some text in the set picker and output more detail in the set.

CleanShot 2026-09-30 at 3 30 50 PM CleanShot 2026-09-30 at 3 31 32 PM

@eminos

eminos commented Oct 1, 2026

Copy link
Copy Markdown
Contributor Author

The two examples you're mentioning, of how config fields are being used, are both for "custom behavior". An addon can create any custom fields it needs for any Fieldtype, for whatever reason it needs.

Your suggested replacement for Sets with instructions and info field, is not it, in my mind.

Maybe my screenshot example was bad.

Imagine you have a "page builder" with a Replicator with many Sets (page sections). Very common I guess.
Now you want an addon to do something with those sets (scheduled in the backend, or frontend) and the addon needs much more structured data for each Set. This data shouldn't be visible in the Entry edit (like instructions and info field), only in the Blueprint editor. Just as "config fields" are.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@eminos @jasonvarga