The SDC field formatter allows rendering fields in SDC slots, but limits props to static values. This dramatically limits the usefulness of SDCs as a display option. Consider the following:
The field markup is relatively simple:
<a href="{{ url }}" class="button" aria-describedby="link-desc">{{ text }}</a>
<p id="link-desc">{{ description }}</p>
But this simple setup is not currently possible with custom_field's SDC display format.
I propose adding token support to SDC props, similar to what is available to the custom template formatter.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2026-04-30 at 9.16.21 AM.png | 61.09 KB | andy-blum |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
apmsooner commentedI'm not opposed to this as long as we probably limit the widgets that can allow token support like: https://git.drupalcode.org/project/custom_field/-/blob/4.0.x/src/Plugin/...
I think if we're reasonable with where they are allowed, then it's just a matter of replacing tokens in https://git.drupalcode.org/project/custom_field/-/blob/4.0.x/src/Trait/S... while keeping in mind any text limits and such defined in the component.
I would want to also follow pattern of the template formatter to check for token_browser module as preferred token selection since the depth of custom_field values will likely be deeper than the default 3.
Comment #4
andy-blumThis issue is waaay outside my normal comfort zone, and I used AI to generate MR 227. Hopefully I've not embarrassed myself with what it's created, but for my limited use case the patch applied cleanly and worked just fine locally.
Comment #5
apmsooner commentedIt's okay, I understand where you wanna go with it. I'm gonna want to get this issue https://www.drupal.org/project/custom_field/issues/3585475 in first however as there are some important changes to make my displays compatible with UI patterns and probably canvas at some point. I ultimately need to move our settings into a process function to have knowledge of other modules element parent structure or else the ajax callbacks just fail. I'm probably gonna have to break some of this up into smaller iterations and expand test coverage to ensure we definitely don't break anything ;)
Comment #6
apmsooner commentedI'll look into this more when I get a chance but the solution provided is not gonna be one I can align with.
Comment #9
apmsooner commented