It's confusing that "Block/$block" sometimes refers to the entity and sometimes to the plugin

Tagging. Thanks for opening this.

Maybe this is only partially related, but I'd like us to consider having Block plugins not depend on Block entities at all, but rather, for the entity to pass in and read back a $configuration values array only. However, even if we did that, we'd still have Block entities depending on Block plugins, so this issue might still be relevant for the sanity of that code.

The main use case for a plugin needing the entity:

BlockInterface::blockBuild() is responsible for returning the contents of a block.

A view can be configured to override the title.
Therefore, Drupal\views\Plugin\block\block\ViewsBlock::blockBuild() needs to be able to update the title dynamically, regardless of whats in the YAML file.

I'd also like to note that Views display plugins get a reference to their view, and filters and formats will do the same thing. I image that image effects and image styles will also follow suit.

I image that image effects and image styles will also follow suit.

We'll see, but I hope not. One of the nice things about plugins is their ability to be contained within larger config structures of different kinds. For example, field formatter settings can be contained in an EntityDisplay or in a View, and at different parts of those structures. Similarly, I'd like contrib modules to be able to use image effect plugins within their own config structures, not just within image styles.

Views plugins getting a reference to the View probably has enough justification for sacrificing this level of reuse, but I'd like to be careful about spreading that pattern too broadly.

Therefore, Drupal\views\Plugin\block\block\ViewsBlock::blockBuild() needs to be able to update the title dynamically, regardless of whats in the YAML file.

And have that change automatically saved back in the block entity? I wonder if there's some other way to accomplish that.

Views plugins getting a reference to the View probably has enough justification for sacrificing this level of reuse, but I'd like to be careful about spreading that pattern too broadly.

Yes this! A million times this!

Therefore, Drupal\views\Plugin\block\block\ViewsBlock::blockBuild() needs to be able to update the title dynamically, regardless of whats in the YAML file.

And have that change automatically saved back in the block entity? I wonder if there's some other way to accomplish that.

The design here was that the BlockPluginBase::configuration variable would hold all of this stuff. it's public and actually has getters and setters because we intended on configurable plugins becoming a subset of plugins that had discrete reusable parts. The render controller can most definitely parse that any way it likes and extract any key and set the label however it pleases. This is true of anything that's in the configuration. It's available at all times, and should (or at least was intended to) contain all the values from the configuration (entity or not). The entity is not necessary for the block.

Eclipse

Ideally, image effects should not assume they're used as part of something called "image styles", nor have to know anything about those - and similar patterns where applicable : filters wrt text formats, field formatters wrt entity displays or views...
Separation of concern ++.

Totally. The way I solved this in Rules 7.x for actions and conditions is introducing an array of parameter information, describing each needed parameter/variable/whatever you call it. Then the rule element gets configured with a plain array of $settings containing all the necessary configuration.
That way, stuff using the action/condition/configurable/.. knows what the required input is and can configure it as necessary for the required context, while the action/condition/configurable/.. does not need to know anything about that - it just relies on getting values for the described parameter/variable/whatever.

In d8, we already have typed data definitions which fit perfectly for describing each needed parameter/variable/whatever. We still have to build the missing parts though - what I roughly described over at #1846172: Replace the actions API. Not sure whether action/condition parameter configuration is perfect match for other "configurables" though - it's perhaps a bit more sophisticated than needed usually.

Regarding decoupling block plugin and block entity, I think we should have the block plugins, the plugin configuration and associated block configuration entities, which optionally can take care of persisting the plugin configuration via a config entity (if you need to). Thus, block plugins should not assume to work with CMI config object or config entities, they should provide us with a $configuration data structure we can manage as we want, e.g. don't persist it at all, serialize it as part of a bigger data structure (rule config, views config, ..), or persist it with an associated config entity.

Thus, block plugins should not assume to work with CMI config object or config entities, they should provide us with a $configuration data structure we can manage as we want, e.g. don't persist it at all, serialize it as part of a bigger data structure (rule config, views config, ..), or persist it with an associated config entity.

+1000000000 to this as well.

Eclipse

As long as you solve this without removing ViewsBlock ability to set the entity label on the fly, without the insane hacks that I removed, more power to you.

Is #1927608: Remove the tight coupling between Block Plugins and Block Entities a duplicate of this issue?

Most of the comments so far on this issue are more relevant for #1927608: Remove the tight coupling between Block Plugins and Block Entities, but the original issue summary here is still relevant: even if the two are decoupled, the same name for two different concepts is not ideal.

I completely agree. I think we should seriously consider moving block plugins out of the block module entirely and renaming them and just having a block entity.

Eclipse

Just to crosspost an idea I had in #1927608: Remove the tight coupling between Block Plugins and Block Entities, I suggested renaming the entity type to 'block_wrapper'. Since that's all it does, it wraps a block.

Okay, we might have some consensus on block_wrapper, but it will be a direct follow-up to #1927608: Remove the tight coupling between Block Plugins and Block Entities

I tried to rename the access hooks similar to #1927608-124: Remove the tight coupling between Block Plugins and Block Entities, but they're tied to the entity type names. Posting it here to save the work.

Retitling. An example of the confusion, even after #1927608: Remove the tight coupling between Block Plugins and Block Entities, is that hook_block_view_alter() acts on the plugin and hook_block_access() acts on the entity, but you wouldn't know that by those hook names.

wrong issue, sorry...

Okay.

This stemmed from some discussion in Prague.

That patch sort of obfuscates further what is going on. Kinda meh about it. :-(

What if we changed the block entity class to BlockConfig and just tried to make a sane pass through the code accordingly? Then we can say something like "You have a bunch of Block Configuration objects and they can return the fully configured block plugin for you." etc.

Thoughts?

Eclipse

Not actively part of the Blocks-Layouts work.

This is still very confusing, by the way. Just not part of the current work being done.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!