[2.0.0-beta1] Blocks implementing PluginFormInterface don't work with BlockSource

i proposed something to tackle this issue.
instead of discarding all blocks having blockSubmit (almost all blocks have it..)
i proposed to be a little more precise.
we whitelist some blocks based on their id (system_menu_block...) or their provider (views, layout_builder, ui_patterns_blocks..)
and then we remove the other ones which have implementation of blockSubmit.

still not perfect but allows to use the source with a set of blocks, which are supposed to work.

let's review and test please

interesting. So, we do like Layout Builder is doing?

// @todo Add a way to alter this list properly (hook, event, etc).

indeed :)

    $whitelisted_blocks = [
      "id" => ["search_form_block", "system_menu_block"],
      "provider" => ["layout_builder", "ui_patterns", "ui_patterns_blocks", "views"],
    ];

do we whitelist ui_patterns & ui_patterns_blocks's blocks now we have ComponentSource?

to answer your questions,
i think layout_builder blocks are not shown here... so we can remove it safely from the whitelist.

about "ui_patterns", "ui_patterns_blocks" blocks, maybe you are right, we could remove them.

the only reason i see now to desire a block VS a component, would be to have the "title" of the block or a specific template associated to it..

i think layout_builder blocks are not shown here... so we can remove it safely from the whitelist.

I was not talking about layout_builder blocks. I was just telling this whitelist idea seems to look like what LAyout Builder is doing.

about "ui_patterns", "ui_patterns_blocks" blocks, maybe you are right, we could remove them.

the only reason i see now to desire a block VS a component, would be to have the "title" of the block or a specific template associated to it..

We don't care about specific block template. One of the long term goal of UI Suite is to get rid of node.html.twig, user.html.twig, field.html.twig, block.html.twig, views.html.twig...

So, let's remove them from the whitelist.

yes i agree with you, i was just raising questions :)
the code is not perfect yet, but we have now more confidence in the fact it will work,
but not with all possible blocks.
what about custom blocks which would have a blockSubmit but without breaking the config structure VS blockForm structure.
do we introduce a mechanism to allow blocks to be whitelisted?
or an advanced option where the user has access to the full list without our recent filtering?

what about custom blocks which would have a blockSubmit but without breaking the config structure VS blockForm structure.

Custom blocks as content entity ? We are not supporting them because embedding such a block in a config entity will create a dependency from config to content, which is something to avoid in Drupal.

Maybe we can add a comment in the code to tell about this decision? And also why we are not supporting BlockSource?

Also, do you plan to do this:

   // @todo Add a way to alter this list properly (hook, event, etc).

ok, i found a real better way to handle the filtering.

Part of the filtering "job" was already done in. ui_patterns.module in the ui_patterns_plugin_filter_block__ui_patterns_alter function.
Indeed, we use the consumer "ui_patterns" in the BlockSource source plugin to gather the list of blocks.

In ui_patterns_plugin_filter_block__ui_patterns_alter, we place a boolean marker inside each block plugin definition :
'_ui_patterns_compatible' (similar to '_block_ui_hidden' ?).
This marker is used in BlockSource plugin to filter the block definitions when the marker is false.

The idea of the marker is to allow other modules to interact with the decision placed inside the marker.
If one wants a block to be blacklisted or whitelisted, it should implement the hook hook_plugin_filter_TYPE__CONSUMER_alter()
with 'block' as TYPE and 'ui_patterns' as CONSUMER and do the following thing :
- case 1 : the hook implementation is called before our hook implementation in ui_patterns.
A module can place a value '_ui_patterns_compatible' inside some block definitions (before ui_patterns place its value). It will force the value, as ui_patterns won't touch the value decided. It will force the blacklist of the whilelist of those marked blocks.

- case 2 : the hook implementation is called after our hook implementation in ui_patterns.
The module simply override the value '_ui_patterns_compatible' on the desired blocks. I will therefore blacklist or whilelist those blocks based on the value written.

please review :)

i rebased the MR and i removed the "required" plugin_id to ease removal (allow to fix https://www.drupal.org/project/ui_patterns/issues/3462502 🐛 [2.0.0-beta1] No way to remove Content Active )

Automatically closed - issue fixed for 2 weeks with no activity.