Allow selection of any block

Created on 15 May 2018, about 6 years ago
Updated 13 June 2024, 13 days ago

I have a client need like so:
1. Client places a block in a region
2. Client then wants to reference that new block from a paragraph

Currently, the config makes you select any new blocks. I would like to select a newly-created block without a config change.

✨ Feature request
Status

Needs review

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States glass.dimly

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    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.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update about 1 year ago
    PHPLint Failed
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update about 1 year ago
    7 pass
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update about 1 year ago
    7 pass
  • Status changed to Needs review about 1 year ago
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update about 1 year ago
    Patch Failed to Apply
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

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

  • First commit to issue fork.
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 5.7
    last update 12 months ago
    7 pass
  • Status changed to RTBC 12 months ago
  • πŸ‡©πŸ‡ͺGermany Grevil

    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!

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    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!

  • Status changed to Needs work 15 days ago
  • πŸ‡¨πŸ‡­Switzerland Berdir Switzerland

    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

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    @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.

  • πŸ‡©πŸ‡ͺGermany Grevil

    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.

  • πŸ‡©πŸ‡ͺGermany Grevil

    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.
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    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?

  • πŸ‡©πŸ‡ͺGermany Grevil

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

  • Pipeline finished with Success
    13 days ago
    Total: 221s
    #197953
  • Status changed to Needs review 13 days ago
  • πŸ‡©πŸ‡ͺGermany Grevil

    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.

  • Pipeline finished with Success
    13 days ago
    Total: 185s
    #197960
Production build 0.69.0 2024