Rename plugin.core.block CMI prefix to block.block

Yes please.

How would this work if block module wanted to store extra settings? Wouldn't a config in block.settings be automatically loaded? I think having two levels for the plugin storage still might be good.

Views does views.view.* and views.settings.

Marking this postponed on the main issue.

Re-postponing on #1871696: Convert block instances to configuration entities to resolve architectural issues.

Quoting myself from #1826602-87: Allow all configuration entities to be enabled/disabled:

[The problem of this issue here] is much rather that the new config files of the new block system are not namespaced + owned + supplied by each module, and instead, collected by a single service. Therefore, the service has to manually check whether the configuration is actually valid, and it also has to maintain the configuration on behalf of the actual modules.

Instead of plugin.core.block.ID config names, the block system should actually use $module.plugin.core.block.ID.

I wanted to raise this concern in the block plugin conversion issue already, but didn't want to block that monster patch on it.

On the question of block.plugin.$module.ID vs. $module.plugin.block.block.ID, the actual questions need to be:

1) Who owns the config object? Block module or the $module? ("owns" means responsibility. Think of maintenance, update.php.)

2) Also: Are block plugins applicable to Block module only? Or can they be re-used by other services/modules? (What about SuperPanels³-NG 8.x-2.x in contrib? And also, wasn't the plan to blockify the entire system in the end...?)

This was postponed on the ConfigEntity issue for a reason, because it will mean we should follow the lead of every other ConfigEntity and make it block.block.

#1884758: Remove testing profile default blocks removed some of them.

minimal profile's blocks need converting as well.

Missed the ones from #1891324: Minimal lost its blocks

This looks completely sane if testbot is happy.

Eclipse

Hm. What about #9 though?

My larger review in #1871696-43: Convert block instances to configuration entities to resolve architectural issues contained some more details:

Also, the theme name as prefix was very unexpected — given that these config objects are the canonical representations of plugin instances, and given that every plugin instance is of a certain type, which in turn is provided by a certain module/extension, I would have expected config object names of:

block.block.$extension.$plugin_base_id.$machine_name

That would inherently solve a couple of problems that are apparent in the current code:

• A module gets uninstalled?

  No problem: config()->listAll("block.block.$module."); Process the limited subset. Done.

• A plugin ID ceases to exist or a derivative is deleted?

  No problem: config()->listAll("block.block.$module.$plugin_base_id"); Process the limited subset. Done.

The existing hook implementation for deleted menu blocks would be vastly simplified. And perhaps I'm wrong, but I think it is safe to expect that we'll actually have a lot of derivative plugin implementations + instances in D8, so architecturally + storage-wise, we should be prepared for that.

If I get it right, then the theme name was chosen as prefix, since we need to load all block instances for a theme. But frankly, I'd much rather solve that use-case through a cache (or even state?) of block entity IDs per theme. The storage/identifiers should be optimized for handling CRUD operations.

Alternatively/additionally, I could also offer to extend listAll(), so that it is possible to use wildcards within config names to find; e.g., listAll("block.block.*.*.$theme."), and we'd use config object names of

block.block.$extension.$plugin_base_id.$theme.$machine_name

(which would limit the machine_name length to 250 - 65 - 65 - 65 - 12 == 43 characters, but that should be sufficient).

Anyway, point taken. I think the config object names in this patch require some more architectural design considerations.

None of that is this issue's problem to solve. This merely brings Block inline with everything else. There are other issues for that.

Committed and pushed to 8.x. Thanks! Don't think this needs a change notice, since it's D8 only.

Would you be able to cross-link those issues for where follow-up discussion is happening?