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.
Just updated to 4.0 - congrats on the stable release :)
My subtheme's custom layout is now a little wonky though as it was using the body classes for .no-sidebars, .one-sidebar & .two-sidebars which now seem to not get rendered.
I can see an argument for why these might be removed (markup prescribing too much of the layout) but I'd like to know for the record whether these were removed intentionally or by accident and whether they'll be coming back.
Cheers!
Comment | File | Size | Author |
---|---|---|---|
#27 | my layout for omega.zip | 3.42 KB | Patsient |
Comments
Comment #1
dddbbb CreditAttribution: dddbbb commentedActually - isn't this functionality provided by core? If that's correct then I guess Omega is now preventing or stripping it out. The more I think about it, the more it seems like a good idea.
However, it would be cool if this functionality could be added back in on a per subtheme basis - I'm guessing this would be a function for template.php or similar? Any pointers in this area would be greatly appreciated.
Comment #2
dddbbb CreditAttribution: dddbbb commentedOk, for anyone else looking for a quick way to bring this functionality back until we figure out a better way to write our layouts...
Attempting to bring the exact core generated body classes back results in no body classes still (I'm guessing Omega's having the last say here somehow). However, if you use different classes it seems to work. All I've done here is substitute the hyphens in the classes for underscores. Put the following function in your subtheme's template.php and clear caches:
Don't forget to replace YOURTHEME in the function name with the actual machine name of your theme.
Now all you have to do is update your Sass/CSS to use the slightly modified class names (remember: underscores instead of hyphens in this case).
Comment #3
dddbbb CreditAttribution: dddbbb commentedJust found the following in html.preprocess.inc so I guess that answers my question about whether these classes were intentionally removed or not.
Comment #4
mistergabs CreditAttribution: mistergabs commentedGreat, thanks. I nearly had a heart attack when I saw my sidebars stopped working after updating. All seems to be working fine with this fix :)
Comment #5
dddbbb CreditAttribution: dddbbb commented@mistergabs No worries. I also nearly had a heart attack too.
Maintainers: Can you clear up why these core classes were removed for the benefit of anyone visiting this thread looking for answers?
Comment #6
fubhy CreditAttribution: fubhy commentedRight... So we removed these classes because they are bullshit :P. template_preprocess_html() absolutely blindly adds them without checking if your theme even has sidebars. And if it doesn't it still prints them ('.no-sidebars' in that case). They are being removed from Core too in Drupal 8. I added a much saner way for these classes to be added in a new function called '_omega_preprocess_default_layout_variables'. However, this preprocessor only runs for layouts, not for plain page.tpl.php. BUT, you can implement THEME_preprocess_html() in your theme and invoke that function from there... Or, even better, just implement your own logic for this in your THEME_preprocess_html().
Here's the issue where we are removing this from Core: #1982256: Clean up html.html.twig markup
Comment #7
dddbbb CreditAttribution: dddbbb commentedGreat, thanks for the insight and agreed regarding the view that core is blindly adding bullshit classes.
Where can I get more info on _omega_preprocess_default_layout_variables so that I can do this a better way? I am using layouts so I'd like to take advantage of this if possible.
Comment #8
samwillc CreditAttribution: samwillc commentedIs this not subjective, the 'bullshit classes' argument? I was using those, my site was about to go live, update theme, and boom! Extra work.
@danbohea, thanks for the fix, that helped resume normality :)
Comment #9
dddbbb CreditAttribution: dddbbb commented@samwillc Yeah, the same pretty much happened to me and it did suck quite a lot until I figured out what was going on. Glad the solution helped you too.
The core bullshit classes argument isn't subjective though. Core shouldn't be (and soon won't be) declaring anything about your site's layout, that's the theme's job. All we're doing here is shifting that particular part of preprocess_html to your theme where it can be well informed and under control (rather than assumed and possibly incorrect and/or unwanted).
So then, how do we use _omega_preprocess_default_layout_variables to do this in a much saner way (see #6)?
Comment #10
samwillc CreditAttribution: samwillc commentedNo idea, it was suggested 'sans explanation'.
Comment #11
ebenfarnworth CreditAttribution: ebenfarnworth commentedGreat to see a full release of omega 4. However I had the same problem after upgrading, my side bars were gone!
For a quick fix I just commented out the code shown in reply #3 in: /omega/omega/preprocess/html.preprocess.inc on line 54.
Changing it to:
Not great as I will have to do this every time I update the theme but I needed it to work as before.
Comment #12
flocondetoileAfter upgrading, i met the same problem.
But you have to just change the first line of your layout template
<div<?php print $attributes; ?>>
instead of
<div class="l-page">
And change the class name in your layout scss.
.has-one-sidebar
instead of
.one-sidebar
.has-sidebar-first
instead of
.sidebar-first
etc.
And everything works fine
Comment #14
kclarkson CreditAttribution: kclarkson commentedI upgraded and subthemed on 10.23.13 and am a little confused from this post.
Is there a patch that is going to be committed to fix this ?
Or if this has been fixed by @fubhy then what classes should we use to theme ?
Comment #15
fubhy CreditAttribution: fubhy commentedThere is nothing to be 'fixed' here. We basically 'fixed' it by removing these sidebar classes. The bug *was* that the sidebar classes would always be added to the body even if the theme did not even have sidebars resulting in a weird "no-sidebar" class on themes that don't even support them whatsoever.
If you want to bring them back, all you have to do is take a look at
template_preprocess_html()
and implement similiar logic for adding sidebar classes in your subtheme.Note: These (automagic) sidebar classes have been removed in D8 as well and they shouldn't have existed in D7 either. Core should never assume any layout classes based on your theme region names. So, yes, if you need a class switch based on the existence of a given set of regions (which is fine) then you have to add that yourself with a little preprocess function.
Comment #16
kclarkson CreditAttribution: kclarkson commented@fubhy,
Thanks for the quick reply.
So I would like to theme sites using new / innovative techniques that are going to be used with D8.
With this said, how would you suggest theming the Grid's correctly that would automatically change width depending on blocks being added to the sidebar?
For my homepage for example I do not have any sidebars and want the body class to expand across the whole page, starting (12, 1). But for other pages if there are sidebars I want the grid to change to obviously change the width.
Are you saying the only way to get this functionality with Omega 4 and with D8 is that I have to create a prepprocess function each time ?
Thank again,
K
Comment #17
fubhy CreditAttribution: fubhy commentedYou make that sound like it's a bad thing ;). It's actually a good thing! More control at your fingertips and less garbage being rendered in your HTML by default.
Your use-case (a class switch based on whether or not there is a sidebar region on the page) is very common though. Implementing that switch in a preprocess function is very simple though!
(pre-)process functions are very powerful and should be something you shouldn't be afraid of. Using them is the only way to produce clean and maintainable HTML and CSS. When working on your theme you should always try to optimize your HTML first (be it with a module that helps you to configure the output to your needs or through a custom (pre-)process function for tweaking the classes or whatever). Otherwise you quickly end up hacking your way through CSS trying to cover up / compensate for errors / problems with your HTML. Fight the cause, not the symptom :)
You don't *have* to use a preprocess function in this case though. You could also implement this directly in your page.tpl.php file with some in-line PHP. A preprocessor is nicer and cleaner though.
Comment #18
kclarkson CreditAttribution: kclarkson commented@fuby,
WOW !! GREAT CUSTOMER SERVICE :)
I really appreciate you taking the time to answer questions so quickly. As I am trying to shift from "site builder" to more of "themer" your explanation is EXTREMELY helpful in my quest.
I wish more maintainers were like you :)
OMEGA 4 for PRESIDENT
Comment #19
fubhy CreditAttribution: fubhy commented@kclarkson Thanks ;).
In that case you might be interested in the screencast we recorded a couple of days ago: http://www.youtube.com/watch?v=CmTuvzbPduI
It's 3 hours long and I am not sure if it covers preprocess functions in detail (it was such a long screencast so I really don't remember) but it does cover Theming, Sitebuilding, Omega, Sass, etc.
Comment #20
GuyRus CreditAttribution: GuyRus commentedFor anyone stumbling across this to save some mild head-scratching;
At the time of this writing in Omega 4 if you add the .no-sidebars class in a preprocess_html function (as per #17) it still gets stripped by Omega. Change to .has-no-sidebars or something similar, mod your subtheme layout to match and it will render out fine.
Thanks to Fubhy for the help on this one!
Comment #21
dddbbb CreditAttribution: dddbbb commentedSo basically, see #2.
Comment #22
fubhy CreditAttribution: fubhy commentedSo... I just tried #17 with "no-sidebars" myself. It works flawlessly. Not sure what problems you were running into... The hook from Omega core that removes those classes is invoked *before* this custom one.
So:
1. Core adds classes
2. Omega removes them
3. We add our custom specific classes
I am not sure why "no-sidebars" doesn't work for you. It works flawlessly for me. Please check if the invocation order is correct (core => omega => subtheme). If it's not, then that's the problem (which I don't have).
Comment #24
dddbbb CreditAttribution: dddbbb commented@fubhy I just had to do this again on a new project and I still have issues when trying to add the classes that core used in the first place (e.g. 'no-sidebars'). As per #2 & #20, it works just fine if I use any other class name (e.g. 'no_sidebars').
From your comment in #22, how would I go about checking the invocation order?
Comment #25
caponey CreditAttribution: caponey commentedReally glad I found this post. I was also confused at the lack of sidebar classes, but have fixed it using #17, and the explanation of their removal actually makes a lot of sense. And @fubhy, your response, and attitude toward us who don't know as much is both admirable and very much appreciated. Please keep that spirit! Omega has quite the learning curve, but every step is worth it. Thanks again.
Comment #26
bradallenfisher CreditAttribution: bradallenfisher commentedI can confirm that using no-sidebars does not add a class to the body. I just changed the class to empty-sidebars... works.
Comment #27
Patsient CreditAttribution: Patsient commenteduse of omega theme.
I want to make a laiout for panels based on this idea . I write this code but it is always assigned to the class "panel--g3-no-sidebars"
please help to solve the problem.
best regards!
Comment #28
thmohd CreditAttribution: thmohd commentedFor Drupal 8
Comment #29
GuyPaddock CreditAttribution: GuyPaddock at RedBottle Design, LLC for Inveniem commentedFor anyone using Omega 4 with layouts, you should be getting these classes automatically in your
-layout.tpl.php
file for the layout. If you are not, it may be because you created your-layout.tpl.php
file by copying Omega'spage.tpl.php
which doesn't render attributes.To fix this, change the following line in your
-layout.tpl.php
:To:
Comment #30
Nathan Tsai CreditAttribution: Nathan Tsai commentedI had to use
$variables['page']['content']['content']
for it to work for me.