Problem/Motivation

To meet the intention of the Strategy doc and Drupal CMS is taking over the 'default UI install' experience from Drupal core.

There is discussion in #3555047: Add a way to ship block placement statically (will be useful when block UI is removed)

Steps to reproduce

Proposed resolution

Remove the Block UI.

Remaining tasks

Decide if this mean removing the Block module completely.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

quietone created an issue. See original summary.

larowlan’s picture

+1 from my point of view as a framework maintainer. Leaving tag to give other FMs the change to respond too

catch’s picture

This will have a hard dependency on #3555047: Add a way to ship block placement statically (will be useful when block UI is removed) which has an outline of an idea but no code yet. I think once we have that, then we have a way to run a site without a layout builder (someone could do the same with blocks in their front end theme as we do in core for the admin theme) and we can point people to the various contrib solutions that provide a UI to control page-level layout amongst other things.

I'm not sure if our final state should be that core doesn't have any layout solution in it, but I think removing block module will make it easier to think about how to move a method back in, and that method would never be block module again. Leaving the FM/RM tags on partly because I think I proposed this in the first place at some point.

godotislate’s picture

Mentioned this in #3555047-11: Add a way to ship block placement statically (will be useful when block UI is removed), but we might need to keep block config entities in order to account for plugin dependencies. Or managing dependencies would need to be part of whatever the replacement is.