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.Adding several instances of the same block with different ids might end in not being able to group them and apply the same css.
Let's say I add the recent comments block twice, one with the id "recent_comments" and other with "latest_comments", the resultant blocks will have css ids "block-recent-comments" and "block-latest-comments", and will share css classes "block" and "block-comment", to add common styles I need to add another preprocess call to make them share a class or use the generic "block-comment" class that might affect other blocks if comment module provided more
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1896098_block_add_common_css_class-12.patch | 1.77 KB | Antti J. Salminen |
| #3 | 1896098_block_add_common_css_class-3.patch | 1.85 KB | pcambra |
Comments
Comment #1
pcambraPatch attached adds a new class based in plugin so we have a block-recent-comments class.
Comment #3
pcambraTests updated, hopefully now is green
Comment #4
pcambraCrossposting #1880646: [meta] Update block HTML IDs now that they're plugins
Comment #5
salvisIndeed, the block's css ID is derived from the machine name, and the proposed machine name is derived from the block title, which is initially set by the subject line in the @Plugin section. The block's css class attribute has only "block block-module". The class is useless for a module that defines more than one block, and the ID is not fixed.
I'm not sure how it will work with translation, but if I have a block with a title of "Switch user" and I change this into "Benutzer wechseln" at block-creation time, then the proposed machine name changes from 'switch_user' to 'benutzer_wechseln', and the block's css ID becomes 'block-benutzer-wechseln'.
The user can change the machine name to anything he wants — personally, I'd be tempted to prepend the name of the defining module.
There's no way for a module to provide any css to its blocks.
pcambra's patch adds a "block-pluginid" class, turning
<div id="block-machinename" class="block block-module">
into
<div id="block-machinename" class="block block-module block-pluginid">
Comment #6
tim.plunkett+1 on the RTBC. I'm so glad I added those renderTests()!
Comment #7
sunre: #5: The machine name is not supposed to be translated. If that happens in HEAD currently and you're able to cleanly reproduce it, then we need to file a major bug, please.
Aside from that, this patch looks good to me. That said:
block-$moduleclass remains to be of any value. I don't really see the point of it from a themer perspective.block-$base_pluginin the same way. Let's create an issue for that.Comment #8
salvisNo, this does not currently happen. However, when you do "Add Block", the block title and the machine name are pre-set. Any changes you make to the block title are immediately (!) carried over to the machine name.
The block title is taken from the "subject" line (http://drupal.org/node/1880620):
The
@Translation()syntax seems to indicate that "Who's online" will be translated, i.e. it will show up in the UI language and will presumably be carried over into the machine name. Any other behavior would be, well, unexpected...While the example in the change record shows a plugin ID that starts with the module name, it is unclear whether that's an error, a coincidence, a recommendation, or a requirement. There's some additional discussion here:
#1879496: Do we need to worry about plugin ID collisions?
#1880646: [meta] Update block HTML IDs now that they're plugins
If we don't have
block-$moduleand we don't have an enforced requirement to put the module name (and probably a separator) into the plugin ID, then we cannot reliably select the block. The selector isdiv.block-$module.block-$pluginid(e.g.div.block-devel.block-switch-userordiv.block-user.block-user-online-block), nothing less.Comment #9
catchLooks like this needs more discussion. I'd quite like to kill off the block-$module class if we can too. If there's plugin ID collisions then the class added here is going to be prone to error - that could happen at any time just by enabling a new module.
Comment #10
benjy CreditAttribution: benjy commentedbumping this to try and get some more discussion happening as catch suggests.
Comment #11
klonosComment #12
Antti J. Salminen CreditAttribution: Antti J. Salminen commentedHere's a rerolled patch that moves to replacing the current block-$provider class with block-$provider-$pluginid. I understood this to be sun's suggestion in #1880646-59: [meta] Update block HTML IDs now that they're plugins. The plan he outlined there would be a clear way forward and seems worth discussing. Marking to needs review to see what the testbot thinks about it...
In my opinion dropping the "block-" prefix as redundant like Fidelix proposed in that issue's comments might also be a good idea.
Comment #13
sunComment #14
alexpottWe also need to review all the css and js...
eg: bartik's style.css
Comment #15
dawehnerAccording to #1880646-59: [meta] Update block HTML IDs now that they're plugins we have to apply some special replacement for derivative IDs. This for sure also has to be tested.
Here is a list of css files, which needs updates:
Comment #18
tim.plunkettNot actively part of the Blocks-Layouts work.
Comment #30
quietone CreditAttribution: quietone at PreviousNext commentedIt has been 10 years since there was discussion on this issue.
Is this still relevant to Drupal 10?
Since we need more information to move forward with this issue, I am setting the status to 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!