Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When you choose to display a field in views, using a field formatter from ui_patterns, the entire list of source plugins are available for props and slots (without restricting the entity type to the entity type listed in the view, and without restricting the field to be the current field to be displayed). This bug is due to a problem in context matching between context injected to the source plugin manager, and the contexts declared in context_definition of all ui_pattern_field_formatters source plugins.
Indeed, what is special here is that, in the particular case, the display formatter settings form is called for the entity type and field name but without any bundle in the gathered "context" (there is no bundle by construction here).
Steps to reproduce
Enable UI patterns field formatters
Create views with field
Select ui patterns field formatter
Select a component
All props and slots, have lot of sources available by mistake as explained above.
Proposed resolution
- Being able to tackle the situation where no bundle is available, with a small rework of ui patterns source plugin derivers and play with the context_definition of generated plugins.
- Some source plugins have the actual context (entity_type_id, bundle, field_name) and they will not be used in field formatters inside views
- Some source plugins won't have the bundle in context (there will be one plugin per entity type and field_name), so we would be able to find them in the context of field formatter inside views
- This will require some modifications in the plugin deriver to be able to remove the bundle context, also add mechanism to restrict by bundle when you map inside display entity/layout builder case
- Ui patterns field formatter version 1.0x : the context seems to be based on the entire field storage :
$field_storage_definition = $this->fieldDefinition->getFieldStorageDefinition(); $context = [ 'storageDefinition' => $field_storage_definition, 'limit' => $field_storage_definition->getPropertyNames(), ]; // Some modifications to make 'variant' default value working. $configuration = $this->getSettings(); $this->buildPatternDisplayForm($form, 'field_properties', $context, $configuration);
Also we can explore the API of context provider to help to resolve this issue :
https://api.drupal.org/api/drupal/core%21modules%21node%21src%21ContextP...
https://drupalsun.com/philipnorton42/2023/01/22/drupal-10-creating-custo...
Issue fork ui_patterns-3440278
Show commands
Start 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
musa.thomasComment #3
musa.thomasComment #4
musa.thomasComment #6
just_like_good_vibesComment #7
pdureau commentedSame MR as #3440319: [2.0.0-alpha2] Formatters: functional feedbacks from alpha1
Comment #8
pdureau commentedTested with a node's title field:
Comment #9
just_like_good_vibesFor each: ❌ the form doesn't load
-> this is true when the field formatter "for each" is not applicable, when the cardinality of the storage is 1 at most.
if you select a field with cardinality superior or equal to 2, the for each will work in views.
i have checked the code, i am not 100% sure, but the list of formatters which is proposed in the views field option form, does not reflect the result of the method "isApplicable" inside each field formatter in the list.
according to what i have seen in the following line in the "getOptions" of the class "Drupal\views\Plugin\views\field\EntityField" from views module.
$formatters = $this->formatterPluginManager->getOptions($field->getType());so what do we do?
Comment #10
pdureau commentedComment #11
pdureau commentedComment #12
pdureau commentedA little update with my new batch of tests
Before fixing "For each on a single value field" let's talk about those 2 formatters.
Why do we have field properties source on "for all" ? It make sense when "For all" is applied to a single value field, but what is expected in a multivalued field?
Proposal
"Component (For all)" is renamed 'Component wrapper" (or something like that...) and has those sources:
"Component (For each)"is simply renamed 'Component", is available for both single value and multivalued fields, a has those sources:
Both are available for multivalues & single value fields.
Comment #13
just_like_good_vibesAbout for each and for All,
why not just use the terms "Components"
(for each), and "Component"?
Comment #14
pdureau commentedComment #15
just_like_good_vibesi take this one
Comment #17
just_like_good_vibesHello,
as we discussed during the camp, i made the changes to allow better field formatter naming and working.
i think this MR is one of the toughest i have made during the last weeks, but it brings so much goodness :
+ better source plugins management for slots and props, through a better handling of contexts. Especially custom contexts which are
specified by ui patterns sources and have constraints (views source plugins, field prop source plugins...etc). The magic really happens now
The modification allowed also to clean the ".module" of ui_patterns_views and put the right code at the right place inside each ui patterns views ' source plugins ;)
+ some bugfixes on ui_patterns_field_formatters, which were appearing during nesting. the nested field formatter was not handling correction the field definition..
+ some renaming of the two field formatters which are "Single component" and "Component per item", to allow better understanding of what's happening when you render a field and its items with ui patterns.
+ renaming of field formatter PHP classes for better homogeneity
please review
Comment #18
pdureau commentedComment #20
pdureau commentedMerged