Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Posted by xjm
Problem/Motivation
This issue is a followup for #1535868: Convert all blocks into plugins.
- Plugins define a plugin ID that is different from their class name.
- Some, but not all block plugins append the module name to the beginning of the block plugin ID.
- The menu module prefixes its block plugin derivative IDs with
menu-to avoid possible collisions with other blocks (e.g. the main menu vs. the main content block). This may or may not be necessary.
Proposed resolution
- Explore how the plugin system responds to a possible plugin ID collision (e.g., two separate modules providing a plugin with the ID
recent_comments). - If necessary, update core plugin IDs so that they are prefixed with the module name and recommend this as a best practice.
Comments
Comment #1
xjmComment #2
xjmComment #3
xjmRelated issue: #1888218: Default configuration entities provided by a module should include the module name in the machine name
Comment #4
salvisI'm very much in favor of doing this. The change record already shows it that way:
If I saw a proposed machine name like "online_block", I'd naturally feel the need to prepend the module name, which would break any custom theming tied to
id="block-online-block".A standard of prepending the module name (and appending 'block') in the plugin definition would make it much less likely that the user changes the machine name.
This is not just a question of avoiding "block plugin ID collisions." Setting a standard will help to avoid a much larger confusion.
Comment #5
tim.plunkettThis is not just about blocks, it's all plugins. Views plugins have the same problem.
We should consider (maybe not extensively but at least a bit) using a separator for this,
user.online_blockoruser__online_blocksomething, so that we can remove themodulefrom the definition.Comment #6
salvisYes, a separator would probably make sense, especially with module names that have underscores.
EDIT:
Right now core appends "block" for the id and prepends "block" for the class — "block_test" becomes<div id="block-test-block" class="block block-block-test>Maybe core should just make sure that the default machine name starts with the module name (and a suitable separator) and ends with "block" and then leave it at that?This is what core really does:
<div id="block-machinename" class="block block-module">
<div id="block-test-block" class="block block-block-test">
The machine name is derived from the block title, not the plugin ID, so this is not really relevant here.
Comment #7
tim.plunkettPlugin IDs are per plugin type, so they're ALL blocks. That part I'd love to see die.
Comment #8
pcambraOn css classes, somehow related: #1896098: Add a plugin class to the blocks to identify instances in css
Comment #9
xjmClarifying #7, since it had me squinting: A Views
user_onlinehandler will not collide with a Blockuser_onlinedefinition plugin, so the_blockis superfluous. This is out if the scope of the issue, but maybe:Comment #10
pcambraThat makes a lot of sense at least for contrib, i.e. devel has a user_switch block that could be potentially mismatched with a plugin provided by user module.
Comment #11
damiankloip CreditAttribution: damiankloip commentedI was currently working under the assumption that the implementing module could just have 'my_plugin' but then any other modules implementing a plugin for that type would do 'MODULE_my_plugin', Atleast that is what we have been doing so far. Which I am OK with, So are we saying we should always prefix this id? even for a modules own plugins?
Comment #12
sunCross-linking: #1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term)
Comment #13
effulgentsia CreditAttribution: effulgentsia commentedPer #1862600-15: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term), I'm +1 to #5. @tim.plunkett: I'm happy to see you suggesting it, since you seemed against that in #1862600-5: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term).
Comment #14
tim.plunkettFacts and evidence persuaded me :)
Comment #14.0
tim.plunkettUpdated issue summary.
Comment #15
jibranAre we going to have patch in this issue?
Comment #15.0
jibranRemoving myself from the author field so that I can unfollow the issue. --xjm
Comment #16
xjmComment #19
tim.plunkettNot actively part of the Blocks-Layouts work.
Comment #22
EclipseGc CreditAttribution: EclipseGc at Acquia commentedLong standing issue hehe:
So all 4 of the discovery mechanism in core iterate over the results that were given to them and manually set something like:
So in that sense, multiple plugins of the same id should not cause Drupal to blow up or anything, but one will silently overwrite the other. I could see introducing an exception of some sort in these cases but each discovery mechanic does this same work independently, so there's no single target for preventing that. Drupal developers are pretty good at namespacing things at this point, so I've never heard of this actually being a problem yet, but conceivably it could happen.
Do we want to prevent it?
Eclipse
Comment #27
longwaveBumping this idea, I've run into this a few times in custom code now where two plugins accidentally have the same ID, only one will win and it can be confusing to figure out. I think the idea in #22 of at least having some kind of warning that a duplicate ID has been used would be helpful.