Once Experience Builder is stable, it will be shipped with Drupal CMS. Additionally, 'XB themes' (e.g. with the site chrome controlled by Experience Builder) are likely to be a central component of 'site templates'.
This means we are going to have a transitional period where Drupal CMS includes three page builders - block UI (for site chrome), layout builder (for entities and sometimes other things like navigation admin UI), and XB (for both site chrome and entities). This will also be the case for any other site template that includes XB.
There will need to be a migration path from layout builder to XB, and this is being worked on, while that is a very complex task, it will mostly amount to a 1-1 swap for individual sites. Theoretically at least, layout builder could live in contrib alongside XB, while we figure out the process to move parts of XB into core, which would remove the duplication in Drupal CMS itself.
However, this is much harder with the block module. Basic site navigation only works if you have the block module installed, or a full alternative installed and configured - otherwise you don't get things like the user menu login link when you're logged out.
So.. if we want to replace block module in core, but we don't want to postpone it on XB's full site chrome editing being in core wholesale, then we need to find a solution that could work in the medium term.
Discussed this with @nod_ in slack and came up with the following:
- If we don't want block UI in core (I certainly don't), but we also don't want the full XB UI in core yet, then what would the minimum possible implementation look to remove the duplication?
- We could add the XB layout configuration entity to core, and the ability to render HTML from that configuration, without the UI to edit them.
- Core's admin theme (and maybe front end theme, but we also need to discuss what that means in the world of site templates) could ship with blocks configured, as they already do.
- Contrib modules like masquerade could be integrated into navigation rather than requiring a block configuration anyway now. Recipes could configure their themes different out of the box via shipped config/config actions.
- If you want to edit your block layout in a UI, then you install Experience Builder (or potentially another UI on top of the config entity) from contrib.
There are two big questions to answer here that need to be decided quite early up front:
1. We need product manager review and sign off of the concept that we might remove the UI for block/region configuration from core, even if that's temporary.
2. We need framework manager/front end framework manager and subsystem maintainer review (and by subsystem maintainer, this means theme, block, and experience builder at least) of whether this UI-less XB-lite approach might be feasible at a high level.
Any actual implementation will require a stable XB data model at least for the template config entity.
Active
11.0 🔥
block.module
It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).
It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.
It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.
Used to alert the fron-tend framework manager core committer(s) that a front-end focused issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.
Linking the 2017 discussion for replacing block UI with layout builder ✨ Discuss using Layout Builder to control full site layout and replace Block UI Needs work for reference. We should probably mark that as outdated now, although maybe once the approach here has been refined a bit more.