[Policy] Research about best way to limit the selectable blocks on dashboards

This might be easier than expected.

My first idea was creating our own plugin extending blocks, but layout_builder is quite tied to blocks themselves. So we might hit some blocker on the way. Also, this implies that people providing blocks in core/contrib/custom need to actually think about the dashboard. Even if "DashboardBlock" implementation would probably be as simple as extending the already provided block, they need to actually do that, which is not a good DX.

My second idea would be using the existing block, but adding some new property to the annotation. That means that people providing blocks in core/contrib/custom might need to think about the dashboard, but it's just adding a property in their existing annotation. Sounds good. Cons: we need to alter the block annotation to provide that.

But even better is that we don't even need to alter the block annotation, as that is not purged (even probably we want to do that in the long run).

Attached a PoC:

1. We alter all block definitions and set that we don't want to allow them on dashboards.
2. We keep an allowlist that sets those that we want from core in the dashboards.
3. Then we can filter those and display only those with the property.

Pros:
1. We can add a setting e.g. allow all blocks in the dashboard, false by default. So people can add any blocks to a dashboard if they want.
2. We can add a setting e.g. allow all views blocks in the dashboard, false by default. So people can ignore other blocks, but still allow any views provided blocks.
3. People providing blocks can specify a property on their blocks to explicitly allow them in dashboards (our goal).

Cons:
1. We rely (for now) on an undocumented property (not in the annotation definition).

To Consider:
When editing my article layout I would be able to add any dashboard-specific blocks. That is not a con per-se, and could definitely be considered in follow-ups after inclusion.

Added related core issue.

Created ✨ Provide a way to opt-out of inline blocks in layout builder based on context Needs work in core.

Thank you for your research on this topic.

Read your post and I agree this can be a simple and effective way to filter the block we want to make available for the dashboard.

Just adding an extra question about how would you envision the integration of Views based blocks. Should we globally add all the blocks provided by Views, or should we create a specific Views display type "Dashboard" or similar to have a more granular control?

The former would open the gates for a big number of blocks, some of them unsuitable for dashboard. The latter would make harder to include blocks already provided by core.

Thanks!

I didn't consider yet that problem. Adding a specific Views display type "Dashboard" might be worth it. The pros and cons are similar to block plugins themselves, but in this case as they can be easily created by sitebuilders cloning a block (and we can still provide defaults) might be worth.

I wouldn't like to override the core block display class, as that would require more integration efforts from contrib (e.g. ctools). But we might be able to add a setting (third party settings?) to the existing block display.

Adding ✨ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active as related, maybe a good one to rely on, since it seems to be getting to a final decision state, and will limit the set of blocks.
Said that, it may be still needed to complement that here, so definitely not a duplicate.

Thanks @marvil07, wasn't aware of that one.

To be discussed in Lille.

Since the arrival of 📌 Use PHP attributes instead of doctrine annotations Fixed adding a new arbitrary property to Block attributes is not allowed.

I'm getting this error when adding the new property to attributes:
Error: Unknown named parameter $allow_in_dashboard in ReflectionAttribute->newInstance() (line 13 of modules/contrib/dashboard/src/Plugin/Block/DashboardTextBlock.php).

Read issues comments and there are some mentions about how to alter them, but most of them leads to use and alter_hook, so defining blocks as dashboard-allowed from the attributes section does not seem to be an option, at least for not.

What do you think?

Navigation will face the same issue: 📌 Provide a way for other modules to flag block plugin implementations as 'navigation safe' Active . So definitely not a dashboard issue, but a LB one that we need to explore together.

Imho the key question is: Should the "tag" be alter-able.
If not, a MarkerInterface or Atrtribute does well.
If yes, extending the plugin definition with some kind of tags property springs to mind.

+1 for the latter from me.

So the attribute based concept is technically the official way of doing this in core for the moment. See 📌 Provide a way for other modules to flag block plugin implementations as 'navigation safe' Active

This might change in ✨ Allow attribute-based plugins to discover supplemental attributes from other modules Active