- Issue created by @longwave
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
How will that be conveyed in the UI? How will the user be informed that more/different choices become available depending on the context they're editing a component tree for?
@lauriii: Is this in scope for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active ?
- 🇫🇮Finland lauriii Finland
Would it be possible to provide a list of blocks that this impacts and what are the contexts they depend on? This would help me understand the impact of this and would make this more actionable for design.
Is there some existing UX for this in the Block module or Layout Builder?
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Would it be possible to provide a list of blocks that this impacts and what are the contexts they depend on? This would help me understand the impact of this and would make this more actionable for design.
Grep for
context_definitions: [("block" attribute),context_definitions = {("block" annotation) orcontext_definitions'](in block plugin derivers).That surfaces the following (derived) block plugins in core:
\Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver\Drupal\layout_builder\Plugin\Derivative\ExtraFieldBlockDeriver\Drupal\views\Plugin\Derivative\ViewsBlock
Is there some existing UX for this in the Block module or Layout Builder?
AFAICT there is not. It's "magic"; it's precisely the much more narrow constraints of the Layout Builder UX that mean that there wasn't a need for a generic UX for this in core. Views similarly provided a narrower UX when configuring Views blocks (and the Block UI then didn't visualize it, nor provided affordances).
It's precisely the lack of properly informing the end user that makes the Block UI so bad, and which XB should do better.
P.S.: I'm totally fine with saying: XB does not support any block plugins that have optional or required contexts defined. But we'll need to figure this out before we can migrate/upgrade Layout Builder to XB.
