Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Drupal core provides it's own body classes based on what blocks are enabled on block administration page. This conflicts with the way panel pages work when they disable Drupal blocks.
The following patch provides two additional settings for panel pages: ability to disable Drupal core provided body classes related to regions ('two-sidebars', 'one-sidebar sidebar-first', 'one-sidebar sidebar-second', 'no-sidebars') as well as ability to provide own body element classes.
Mukhsim.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | allow-custom-body-classes-1379538-5441668-2.patch | 4.08 KB | mukhsim |
| #14 | allow-custom-body-classes-1379538-5441668.patch | 3.86 KB | mukhsim |
| #6 | allow-custom-body-classes-1379538-5399354.patch | 3.29 KB | mukhsim |
| #1 | allow-custom-body-classes-1379538.patch | 2.79 KB | mukhsim |
Comments
Comment #1
mukhsim commentedPatch attached.
Comment #2
Letharion commentedWell merlin already said this was a worthwhile patch, so I'm assigning to him for a review.
@mukhsim if you provide more information about how/when this is helpful, I could help with the review and speed the process up.
Comment #3
merlinofchaos commentedOk, first:
I think we need this to be slightly more generic. Panelizer is likely to require this code as well, so the part that actually does the html preprocess needs to be generic and read from a static or something to make it easy, rather than just reading from the handler in order to reduce code duplication.
Second:
I'm not sure it's safe to remove body classes specifically like this. If people are using other themes, there are other classes that might be in use that won't get removed. This is going to lead to bug reports.
CSS can often be designed to work around the presence of extra classes, and it may be best that we don't try to offer this feature and instead encourage people to use CSS that uses the extra classes and does the right thing with the extra classes regardless of the original classes.
I encourage more discussion on this.
Comment #4
Letharion commentedComment #5
mukhsim commentedRegarding second part: will providing a textfield for specifying body classes to remove, instead of a wholesale removal help?
Body classes added by Drupal core mess things up when using Panels Everywhere and this really needs to be addressed on variant-by-variant case (one sidebar, two sidebars, etc), especially when using responsive themes. I run into this problem while building a starter responsive theme based on Panels Everywhere and Adaptivetheme (D7).
As for the first part: I haven't used Panelizer, so, it is hard for me to abstract this thing out from Panels module in order to be able to reuse this feature elsewhere. May need some guidance and help.
Mukhsim.
Comment #6
mukhsim commentedMerlinofchaos,
The attached patch addresses your second point. Adding/removing of body CSS classes is completely optional and selective.
I am still not sure about the first point you have raised. Any hints at what should I be looking at?
The upgrade of AT Panels Everywhere theme to Drupal 7 depends on the ability to add/remove body classes depending on layout being used by Panels Everywhere site template. For more details, please refer to: https://drupal.org/node/1148328
Thank you,
Mukhsim.
Comment #7
merlinofchaos commentedFor my first point I mean this:
That's in panels_preprocess_html
What would be better is if, when the panel is rendered, these classes are placed into a static or something, and then panels_preprocess_html looks at the static.
That way you could add this functionality to panel nodes easily because panels_preprocess_html isn't looking directly into datastructures.
Comment #8
mukhsim commentedWhere should I be setting that static var? Is it in panels.module in the following function:
And then calling that static var from panels_preprocess_html?
Should I be using drupal_static for this purpose?
Thanks for quick response, Merlin.
Mukhsim.
Comment #9
merlinofchaos commentedI believe you would set the static in panels_panel_context_render() which is the last place that you'll have direct access to the handler data before passing it off to the general panels renderer.
Comment #10
mukhsim commentedIt seems that panels_panel_context_render() is called after panels_preprocess_html() and therefore cannot pass variables to it.
Any ideas about how to overcome this?
Comment #11
merlinofchaos commentedReally? I don't see how that's possible. preprocess_html shouldn't be called until after the main page is rendered.
Comment #12
mukhsim commentedI printed time() from both functions:
1325966158 called from preprocess
1325966160 called from panels_panel_context_render
Comment #13
mukhsim commentedNevermind the previous comment, preprocess print shows on next page rendering.
Comment #14
mukhsim commentedUpdated patch to use static var.
Comment #15
Letharion commentedUn-assigning since the review should be by someone else.
Comment #16
mukhsim commentedAttached is an improved patch.
Comment #17
merlinofchaos commentedI think in an initial review, this patch looks pretty good. I'll look into it more deeply when I have more time.
Comment #18
andypostThis is a only think that stops AT Panels Everywhere from initial release
Comment #19
Jeff Burnz commentedNo it won't, its not good to rely on this feature for layout control, I built my own mechanism for that. This is handy but not required for my theme.
Comment #20
merlinofchaos commentedCommitted.