Allow selection of any block

Pushing this now, as it still makes a lot of sense to not being forced to select all blocks for having them available and being forced to update the selection, when a new block or category is added.

Interestingly, if no plugin_ids are passed from configuration, the module already seems to allow all blocks and sets all checkboxes checked, when entering the field settings form:

settings:
  selection: blocks
  selection_settings:
    plugin_ids: {  }

So we should finish this as expected and super helpful functionality.

MR created, re-implemented the changes on the latest version.

Slight adjustments!

Works as expected! Steps I did to test this:

1. Create a new block field on the "Article" content type
2. Not selecting any blocks (and ignore the block section entirely, the details' wrapper is not even open)
3. Create a new content and check that all blocks are available
4. Create a new custom block
5. Create a new content and check that the new custom block is available (without manually adding it to the available selection)
6. The block is there!

RTBC!

Thanks @Grevil! Confirming RTBC. For the reasons given in #6 it would be super nice to have this merged soon and a new stable release tagged. Little change, huge improvement!

Is this really that useful with the category selection mode? This opens up the ability to use kinds of blocks, including special ones like title/messages/content that are usually not desired or could even result in errors or recursion.

The category selection mode on other one hand allows you to allow any block_content entity if you want to, or all views or any any combination of that.

The MR looks like a pretty incomplete and invalid port of an older patch, the settings form changed a lot. there's no plugin_ids anymore on that level ever, and now it's making the selection *mode* optional, not the plugins.

I don't know if this really still does work, and I won't commit it without tests.

A better approach for this might be to build on the selection mode plugin that explicitly allows everything

@Berdir thank you for looking into this.

My key (pain) point still is:

Pushing this now, as it still makes a lot of sense to not being forced to select all blocks for having them available and being forced to update the selection, when a new block or category is added.

I'll take a deeper look with @Grevil tomorrow.

Just tested the current implementation and it doesn't work anymore.

I am still fairly sure, it has its use case. But we should make sure, that the user is not able to select block, that would lead to errors / recursion. Of course, tests should be added as well.

Ok, funnily enough @Anybody's and mine request is already covered by the module's functionality. Through selecting all blocks, any newly added blocks will be automatically available (and checked on the settings page).
This is quite unusual for Drupal, as generally the logic for these kinds of form elements is, that if everything is unchecked, all given blocks will be available.

Meaning we would have two approaches to fix this issue:

• Make the block selection not required, allowing the user to have all blocks available through either selecting all or none blocks on the settings page.
• Document the selection behavior on the settings page.

Great @Grevil! Thanks for your investigations. So I'd be in favor of both. Technically (config-wise) it already works and no changes are needed, just removing the required and adding documentation will fix this misunderstanding / irritation.
Perfect!

@Berdir are you fine with that proposal?

@Anybody unfortunately documenting only won't fix the problem, when using "categories". We can only support any future category, when allowing no value checked.

Alright all done!

Are tests still needed? The functionality didn't really change THAT much, but I can understand if you still desire some.

I'd still vote for the approach in "2973129-allow-none-any-block-selection", because the current behavior, that selecting all blocks leading to $this->getConfiguration()['plugin_ids'] being empty seems not being intentional and a weird behavior of the "tableselect" form element.

Please readd the tag "Needs tests" if any are still needed.

+1 for MR!11 - I think it's clearer and similar to other implementations in Drupal. As checking all has the same effect as leaving all empty and we have no real functionality change here, more UX / SX improvements, I'm setting this RTBC for @Berdir to decide if he's fine with MR!11 and if it needs further tests or if it's fine like that.

Thank you @Grevil!

grevil → changed the visibility of the branch 2973129-better-document to hidden.

Hiding !MR21 as both @Anybody and I agree on !MR11

From #15 ✨ Allow selection of any block RTBC :

[...]
Meaning we would have two approaches to fix this issue:

• Make the block selection not required, allowing the user to have all blocks available through either selecting all or none blocks on the settings page.
• Document the selection behavior on the settings page.

@Anybody and I feel like the first approach would be the more common for Drupal, as often setting no value leads to all being available in the Drupal world.