Custom blocks data (built inside Drupal) builds up overtime and its gets hard to keep that list close or small without selecting to add them all.
Right now there are 3 options.
I propose we add a fourth one called:
Restrict all existing & new Custom blocks block
I only needed this fix for Custom Blocks data also called block_content, but it could be useful in other scenarios where one might not need a subset of features.
I tried using block blacklist for it but block_content:UUID does not seem to be a pattern that gets pickup and filter by it.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | 3199740-restrict-all_20.patch | 49.28 KB | mark_fullmer |
| Screen Shot 2021-02-22 at 4.00.11 PM.png | 13.34 KB | bernardm28 |
Show commandsStart 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
bernardm28 commentedI imagine is mostly adding that option into this file https://git.drupalcode.org/project/layout_builder_restrictions/-/blob/8..... I will give it a shot.
Comment #3
bernardm28 commentedComment #4
bernardm28 commentedComment #5
mark_fullmerThanks for contributing this request! Could you provide more specifics -- such as an example block list -- of what is trying to be achieved that cannot already be achieved via the options available?
Based on the proposed title of the fourth option, "Restrict all existing & new Custom blocks block," I think that if you choose "Allow specific Custom blocks blocks" and do not select any blocks, that will effectively restrict all existing & new custom blocks".
It looks like the documentation at https://www.drupal.org/docs/contributed-modules/layout-builder-restricti... is a bit outdated, so I'll update it and clarify this methodology.
Comment #6
bernardm28 commentedThe main issue is that our Custom blocks blocklist has copyright info, some imported RSS feeds blocks that we update with the migrate API, and an array of employee profiles(not drupal users).
So that makes that list large about 900 Custom blocks blocks.
We don't need any of them to show up. That said, if one leaves the elements unselected the list is still displays expanded and it pushes the page down.
The only option that keeps the list from expanding is to Allow all existing & new Custom blocks blocks but that's the opposite of what we need as we want none of them.
It's only a problem with the custom block blocks. Custom block types and everything else has lists that are small enough.
Comment #7
bernardm28 commentedBy having that fourth option one could have all of them, none of them, or either used an Allowlist or blocklist.
As of now Allowlist with the options blank does what we need but it still expands that array.
Comment #8
mark_fullmerAh, so this referring to the list of blocks showing in the administrative UI (e.g., under a content type's Manage Display tab), not the list in the settings tray as presented to a content editor?
An alternative to adding another radio button would be to put the block listing itself in a collapsible fieldset which is collapsed by default. That would require less form submit logic than an additional radio button, but the additional radio button wouldn't be too complicated, since it would effectively be the same functionality as selecting "Allow specific..." but without showing the list.
I think the implementation is really a usability question. I'd like to get more input before proceeding, but I don't see any problem with the general proposal.
That said, this should be considered lower priority for the module development, since it only affect administrators of Layout Builder Restrictions, and is really only an "annoying" thing rather than something that prevents work. Does that sound accurate?
Comment #9
mark_fullmerComment #10
bernardm28 commentedThat is correct. It's only an administrator issue. The issue is found under content type Display tab.
Either one of those solutions would work. I thought adding the radio button would be the easiest since there is an example for it, but the other approach makes sense too.
Do you have a preference? Or is there a Drupal/Web best practice preferred approach?
Comment #11
mark_fullmerI'm working on this today...!
Comment #12
mark_fullmerI thought through the UX further and feel that a separate radio button is preferable over a collapsible fieldset. The upcoming merge request is partial resolution -- the same logic needs to be applied to the sub-module Layout Builder Restrictions By Region, and test coverage needs to be added.
Comment #15
mark_fullmerI'm adding a patchfile to compare unexpected test failures from the merge requests...
Comment #16
bernardm28 commentedComment #17
bernardm28 commentedAwesome, I tested the patch and it works as expected.
Comment #18
mark_fullmerThe attached patch completes the work defined for this task, adding this same new "Restrict all blocks" option to the Layout Builder Restrictions by Region sub-module.
I'm leaving out the interdiff since this doesn't change the previous code in the patch from #15, it only supplements it.
Comment #20
mark_fullmerThis patch resolves a small logic flaw related to criteria for restricting the movement of a block. Everything else is the same!
Comment #22
mark_fullmer