Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
As I write this though, it just occurred to me that maybe creating a new menu called nav_footer, (and one for nav_header and nav_masthead) would simply "work" and get picked up by the page.tpl.php print statements? (I'm not totally sure about how such variables even like $primary_links are created under the covers).
But this seems to impose upon people to learn and pickup a new convention, rather than using typical Drupal best practices and existing menu systems provided by Drupal out of the box. In other words, "You want a masthead, don't use primary_links, create a custom menu called nav_masthead". "You want some footer links, dont create a menu called 'footer_links', and enable its block in the footer region, create one called 'nav_footer', and it will just work".
This question boils down to: Is this theme for d.o only, or is it going to be flexible enough for other people to download and use? The later seems to embrace the open source model as well as the existing tendency in Contrib towards generalized reusable components as much as possible, erring on the side of flexibility rather than imposing new and opinionated conventions.
I feel like some users actually might consider this theme as a base theme for its nifty default screen elements and use of the 960.gs, so if this is the case, the theme would benefit from making at least a header and footer region available.
I'll also argue here that good use of "regions" would be that the homepage-style (larger header) layout could be the layout that is dynamically chosen if someone puts a block (like that homepage content) in a header region. As a side note here, I've been toying with the idea of a dynamically resizable header (whose height is based on the size of its contents, not a fixed pixel height). I have a working local prototype of this already on my machine. It requires some non-standard theme trickery to get a single header background image gradient that 'scales' depending on the height of the header. I was waiting on feedback about how the 'drop-down' advanced search form is being designed to work (#653746: advanced search form) on interior pages, before I check in my code into my sandbox, because I'd really like to see how this dynamic resizing would work in combination with some smooth js 'strech' effect to extend down the entire header. <-- sorry for side rant, but if i get a response on the search module, it would be cool to see if people think it might be a helpful addition to the theme, in which case a header region would be useful.
Comments
Comment #1
gábor hojtsySo far, we have been able to fit in blocks within the existing regions. Where do you see we are missing regions?
Comment #2
lisarex commentedMoving to the Blue Cheese project.
Comment #3
jwilson3Before I knew about this thread, I had already created an issue #652192: add nav_footer as a block region for footer elements (and provided a patch) that makes the nav_footer available as a region. Scouring the theme contents, I didn't see or understand the logic for how calling
print $nav_footerwould work in page.tpl.php. The same goes for nav_masthead and nav_header, as noted here #652172: replace nav_header with primary_links, and nav_masthead with secondary_links .As I write this though, it just occurred to me that maybe creating a new menu called
nav_footer, (and one for nav_header and nav_masthead) would simply "work" and get picked up by the page.tpl.php print statements? (I'm not totally sure about how such variables even like $primary_links are created under the covers).But this seems to impose upon people to learn and pickup a new convention, rather than using typical Drupal best practices and existing menu systems provided by Drupal out of the box. In other words, "You want a masthead, don't use primary_links, create a custom menu called nav_masthead". "You want some footer links, dont create a menu called 'footer_links', and enable its block in the footer region, create one called 'nav_footer', and it will just work".
This question boils down to: Is this theme for d.o only, or is it going to be flexible enough for other people to download and use? The later seems to embrace the open source model as well as the existing tendency in Contrib towards generalized reusable components as much as possible, erring on the side of flexibility rather than imposing new and opinionated conventions.
I feel like some users actually might consider this theme as a base theme for its nifty default screen elements and use of the 960.gs, so if this is the case, the theme would benefit from making at least a header and footer region available.
I'll also argue here that good use of "regions" would be that the homepage-style (larger header) layout could be the layout that is dynamically chosen if someone puts a block (like that homepage content) in a header region. As a side note here, I've been toying with the idea of a dynamically resizable header (whose height is based on the size of its contents, not a fixed pixel height). I have a working local prototype of this already on my machine. It requires some non-standard theme trickery to get a single header background image gradient that 'scales' depending on the height of the header. I was waiting on feedback about how the 'drop-down' advanced search form is being designed to work (#653746: advanced search form) on interior pages, before I check in my code into my sandbox, because I'd really like to see how this dynamic resizing would work in combination with some smooth js 'strech' effect to extend down the entire header. <-- sorry for side rant, but if i get a response on the search module, it would be cool to see if people think it might be a helpful addition to the theme, in which case a header region would be useful.
Comment #4
drummThe theme is for d.o only.