[6.x] Allow fieldtypes to have an "icon" config field - #15444
Merged
Conversation
The fieldtype selector built a single flat object containing both the fieldtype's CP icon and the defaults for each of its config fields. A fieldtype declaring a config field handled "icon" would have its default overwritten by the CP icon, and that value then followed the field into its config, through the settings form, and on to the save request. FieldTransformer worked around this by unconditionally stripping "icon" from every field config, which made an "icon" config field impossible to save at all. The icon is now kept alongside the config rather than inside it, so it can no longer collide, and the strip is no longer needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A fieldtype could not have a config field handled
icon— the value was silently destroyed.FieldtypeSelector.createField()built a single flat object containing both the fieldtype's CP icon (used for the glyph on the field row) and the default value for each of its config fields, merged withObject.assign(defaults, field). For a fieldtype declaring aniconconfig field, the CP icon won, so the config default was clobbered before the field was even created.Fields.vuethen spread that whole object intoconfig, and the bogus value followed the field through the settings form and into the save request.FieldTransformer::inlineTabField()compensated by unconditionally rejectingiconfrom every field config (#9372), which is what made aniconconfig field impossible to save.The icon is now returned alongside the config instead of inside it, so the two can no longer collide. It stays where it was already being used — the top level of the field object, which is also where
FieldTransformer::toVue()puts it when reading a blueprint back. Nothing readsconfig.icon.With the client no longer injecting it, the strip in
FieldTransformeris gone too. Aniconkey is now treated like any other unrecognised config key, which is the behaviour every other manually added key already had.Needed for #15368