Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Layout Builder currently provides all field blocks, and all blocks, as placeable items via the Settings Tray. On most sites, content builders will not want to place most of the Drupal-provided meta fields, and on many sites, a curated list of placeable blocks would be preferable. Illustration, using the "Article" node type:
Current UI:
Desired (configurable) UI:
Proposed resolution
Developers should use the new hooks provide in New hooks available for filtering plugins at runtime to alter the list of blocks.
Previous options
While the "right" way to curate this list might be permissions-based, Drupal 8 core does not have per-block-type permissions, nor does it have per-field-type permissions.
1. The recommended solution for developers could be to use an event subscriber to extend the base Drupal\layout_builder\Controller\ChooseBlockController to fit their site's needs. If this is the case, we should create documentation of how to do this.
2. Another option would be to add a hook that allows modules to manipulate the list of blocks created by Drupal\layout_builder\Controller\ChooseBlockController
3. Alternatively, Layout Builder's implementation of the "Manage Display" form for each entity type could provide a selectable list of what fields should be allowed to be placed via the Layout UI, and a similar admin UI could be provided for curating which block types should be placeable.
Remaining tasks
- Determine recommended resolution (see above)
- Implement recommended resolution
Comments
Comment #2
mark_fullmerComment #3
mark_fullmerComment #4
mark_fullmerThe attached patch provides a new hook to Layout Builder which allows modules to adjust the list of blocks that will be available in the settings tray.
Manual testing would involve copying the example hook from
layout_builder.api.phpand verifying that the 'Help' block is removed, along with Drupal-provided field_block elements.Comment #5
tim.plunkettGreat suggestion!
I think it'd be a bit cleaner to do the filtering before blocks are grouped and processed, like this.
(interdiff is a bit messy, but it's there)
Comment #6
mark_fullmerI fully agree that the hook should happen before the grouping/processing (since that part is really only doing formatting).
Testing of 2946227-layout_blocks-5.patch works as expected, & a double-check of coding standards all checks out.
This has my nominal RTBC! (I'll let the Layout Builder folks take it from there.)
Comment #7
tim.plunkettThe Usability tag is misleading, but accurate. This does not improve usability at all; it allows other modules to improve the usability.
This hook would be key to building a UI to facilitate this sort of selecting/deselecting blocks.
I think it deserves some test coverage to prove that it actually affects the UI correctly.
Comment #8
mark_fullmerAttached is a test to prove that the added API hook affects the UI.
Scope:
- Adds
tests/modules/layout_builder_test, which implementshook_layout_builder_choose_blocks_alter().- Adds LayoutBuilderAPITest, which enables
layout_builder_test, and verifies that the UI is affected:- "Sticky at top of lists" link is not present
- "Help" block is not present
- "Powered by Drupal" block is present
- "Default revision" is present
Comment #9
samuel.mortensonReally happy to see this issue - we have a similar hook in Panels IPE,
hook_panels_ipe_blocks_alter. Two thoughts:1. I wonder if a similar hook for Layouts would also be helpful - a few themes and modules provide Layouts by default and there are usually a few duplicates. For example if I'm using Layout Builder and Bootstrap, I would only want to show Bootstrap's two-column Layout, not what core provides.
2. Should we make the Section Storage available to the hook implementers? It may be useful to have different blocks per Content Type, or if an Entity has a specific field value, for instance.
Comment #10
mark_fullmer+1 to this feature. This very thing is part of my team's acceptance criteria for being able to use Layout Builder as the layout solution in our distribution.
Comment #11
caspervoogt CreditAttribution: caspervoogt at Plethora commentedAlso +1 to samuel.mortenson's notion of a similar hook to hook_panels_ipe_blocks_alter for Layout Builder.
Comment #12
PanchoComment #13
tim.plunkettSee also #2949177: Introduce a service that returns filtered plugin definitions, a more holistic approach
Comment #14
bkosborne+1 to this. Even if LB doesn't provide the UI, a contrib module could do it and it could eventually be merged into core.
Comment #15
swentel CreditAttribution: swentel as a volunteer commentedI like the hook approach, because it's easier for a (base) theme or themers to implement this. It would for instance also allow themes to use theme settings to expose some configuration to alter the list of blocks.
Comment #16
mark_fullmerOnce https://www.drupal.org/project/drupal/issues/2949177 has been committed, we have the ability to pretty easily curate things in the Layout Builder UI. I've attached a proof-of-concept (which assumes https://www.drupal.org/files/issues/2018-04-17/2949177-plugin_filter-26.... is merged).
Conceptualization
1. Add a per entity-type + view mode -level third-party setting that lists all blocks available in the system & allows choosing which should be displayed.
2. Leverage the new plugin filter hook so that this list, itself, can be curated by sites as needed.
3. Only affect the listing of items in ChooseBlockController, so that if items are added to a layout, and the list is *subsequently* curated, the list is non-destructive to the existing layout.
Obviously, there are some big questions related to UI (the list of blocks could easily become enormous), and even whether this would better go in contrib, so I'd love to get feedback from the Layout Initiative folks, but am happy to continue working on this if it seems like the right direction.
Comment #18
tim.plunkettTook this and tried to see how hard it would be to do from contrib.
Turns out, it's doable with one straightforward addition: adding third party settings support to defaults section storage (which just passes it along to the config entity).
This also has tests now.
The -do-not-test patch is just the code for this issue, -combined contains #2949177: Introduce a service that returns filtered plugin definitions
Comment #19
tim.plunkett#2962248: Layout Builder defaults should support third party settings contains the code needed to accomplish this from contrib.
Comment #21
zuernBernhard CreditAttribution: zuernBernhard at UEBERBIT GmbH commentedSo this one can be committed ?
Comment #22
tedbow@zuernBernhard I think what @tim.plunkett's code in #18 proves is now that #2949177: Introduce a service that returns filtered plugin definitions has been committed it would be very easy to accomplish what this patch is trying to do in contrib module.
@see core/lib/Drupal/Core/Plugin/plugin.api.php and core/modules/layout_builder/tests/modules/layout_builder_test/layout_builder_test.module function
layout_builder_test_plugin_filter_block__layout_builder_alterAlso see the change record here: New hooks available for filtering plugins at runtime
It probably makes more sense to do this contrib. This was to Provide ability to alter blocks presented in ChooseBlockController which the new hooks do.
Comment #23
zuernBernhard CreditAttribution: zuernBernhard at UEBERBIT GmbH commentedOk, the new hooks are commited to 8.6. Right now in 8.5 i use the atteched "dirty hack patch" in the ChooseBlockController. Otherwise I can't see all the Blocks I need in /admin/structure/types/manage//display
Perhaps it would be nice to be able to configure the available contexts somethere or to expose them as "filter" to the user above the list of available blocks.
Comment #24
tedbowThis fixed by #2949177: Introduce a service that returns filtered plugin definitions