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.I had asked the "block class" module developers (http://drupal.org/project/block_class) if they could get that feature into core. #438394: Add to Drupal 7 Core
Todd Nienkerk, developer of block class said, "Pending a handful of improvements -- namely, the ability to define available block classes from the theme's .info file -- this module may be a candidate for core."
Comments
Comment #1
dvessel CreditAttribution: dvessel commentedI don't agree with this. I've certainly abused the .info file in my themes but adding classes seems to hold little value. Who would this help exactly?
Comment #2
jrabeemer CreditAttribution: jrabeemer commentedI hope he can explain his motivations. I suppose there's some technical reason the module needs classes declared in .info. Ideally, any new classes would be strictly created in the GUI along with blocks.
Comment #3
JohnAlbincleaning up issue tags
Comment #4
ultimateboy CreditAttribution: ultimateboy commentedJust pointing to skinr module which allows this on a more abstracted level. I am not sold on the idea of adding this core just yet.. especially defined in .info
Comment #5
stephthegeek CreditAttribution: stephthegeek commentedWe need to not forget the needs of "generic" themers: those creating contrib themes, commercial themes, etc. With changes like:
#453080: Eliminate footer message
#240873: Move custom help settings to blocks
#428800: Convert mission statements to a region with blocks
#503810: Convert primary and secondary menus to blocks
...it is now more difficult for a theme to actually style certain menus, text, messages, and areas of the page to look a certain way, since they're now infinitely positionable by users. This freedom and removing special cases is something I'm very much in support of but we're leaving non-custom themers in the dark without a way to know what's where. The changes in the above issues without the addition of some kind of 'sub-style' system are a bit of a half measure, especially as Drupal tries to gain a better foothold in the design community.
TopNotchThemes is using Skinr for themes going forward and I was actually working on a blog post talking about this very issue. Being less development-inclined, I don't know that I can personally comment on the architectural implications or suggest alternative (to the .info file) implementation options, but we would like to discuss and assist with some such system being considered for core.
RE: #2, A theme itself needs to *provide* the classes, so having them only user-definable in the UI doesn't help much.
Comment #6
jrabeemer CreditAttribution: jrabeemer commentedThemes only provide regions, not blocks. This is about providing a unique class to a block in the GUI.
Comment #7
stephthegeek CreditAttribution: stephthegeek commentedThe purpose of the two modules being discussed here are for themes to provide a pre-defined set of classes which can be assigned to blocks. As the title says, this is currently done through the info file. I'm pointing out how this could be a powerful solution when combined with the everything-as-a-block changes that have already gone into core.
Comment #8
sun.core CreditAttribution: sun.core commentedComment #9
jhedstromFeature -> 8.1.
Comment #11
joelpittetDoing a bit of triage. This doesn't seem like it would fit well to tie blocks to the theme.info.yml file, they are quite unrelated systems. It may be something you can add to configuration for the blocks in CMI?
Feel free to re-open if you can update the issue summary with a proposal or a patch.