Landing page layouts: Regions vs. raw tpl code vs. Panels

smacphail - February 27, 2009 - 21:07

Hi guys/gals,

I'm trying to wrap my head around what the best practice is for creating a section landing page. By this, I mean a top level page that has various blocks of content pulled from lower sections, grouped together under a header. Probably a main "hero" story, some secondary stories and then a list of everything else, etc. Basically a collection of Views (http://drupal.org/project/views) and Nodequeues (http://drupal.org/project/nodequeue). Standard stuff I think, and doable as I see it all over other Drupal sites.

First off, seems like a job for Panels, but we don't have it for D6 yet. Also, it seems to be the opinion that themeing solves all (http://drupal.org/node/261535) and only use Panels if you need a visual interface.

So when it comes to theming this kind of stuff, what's the approach?

1. Do you use regions? Do you define a new region in your theme, create your views/nodequeue blocks, style them, put them into your new region and use CSS to get your layout working right? I thought this would ungainly/inelegant after awhile, having all these regions showing up on the blocks page that are really specific to only one page on the site, but in some screen casts I've seen some sites that seem to have dozens of regions.

2. Or do you dig into the tpl code, load your views and queues and whatever else programatically (http://beyrent.net/2007/10/11/calling-views-in-code/ and http://drupal.org/node/342132) in the theme?

And what exactly is the "thing" that will live at the URL to your landing page? Create a custom content type which basically does nothing except provide a target for a URL alias to forward to and a target for a tpl file that contains the "content", your views and such? I don't know what the alternative is...

Thanks in advance for your insight!

I would argue against doing

nevets - February 27, 2009 - 22:35

I would argue against doing this at the tpl level because you loose the separation of content an layout.

I would argue that either panels or regions is the way to go as both let you abstract out the concept of content (views also helps in this regard). With both panels and regions (and composite layout) you can specify where content can go and what goes there separately.

Panels (which there is a D6 version of) has features that make bringing together related content (particularly by vocabulary) relatively straightforward. The visual interface makes it easy to change the placement of content and well as add or remove content. Panels are a better choice over regions if you have several (or many) different page layouts that would require a large number of regions. In the end though either can work.

As for 'what exactly is the "thing"', it can actually be as simple as a custom page.tpl.php that does not use $content (and possibly other variables). So it your path was www.example.com/somepath you could use page-somepath.tpl.php. While I recommend not using this approach if you do I strongly recommend implementing hook_preprocess_page() and setting up variables there to use in page-somepath.tpl.php (instead of doing the heavy lifting in the tpl file).

Panels still in alpha though?

smacphail - March 2, 2009 - 18:03

re: Panels....it's out for D6, but it's still in alpha, right? From the project page: "Druapl 6: Alpha stage. Code is working but unstable, and should NOT be run on production sites." I'm working on a site that will probably be live before Panels gets to beta, so it's not really an option.

So maybe regions + phptemplate_preprocess_page() or _node() is the way to go?

_

WorldFallz - March 2, 2009 - 18:08

Another option might be the http://drupal.org/project/composite module.

_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.

Thanks for the link to that

smacphail - March 4, 2009 - 18:15

Thanks for the link to that module!

I already started down the regions/preprocess path, but I'll have a look at that module at a later date and see if I should add it to the mix.

Performance impact? Defining regions but not using them

smacphail - April 8, 2009 - 19:11

Not sure if anybody's still tracking along on this thread, but I'm a few weeks into my dev on this site I'm working on, and just using regions and creating preprocess functions seems to have done the trick for me when it comes to these multi-piece layouts.

One thing I've noticed though is that region contents are loaded and processing time is spent on them, even though I'm not using them in the final output.

While using the excellent Drupal for Firebug module, I found that there were bunches of nodes that were being loaded on a page that had no reason for being there. I couldn't figure out why they were being loaded, and then it clicked: I had defined a region for my homepage which contained a View that was showing a list of nodes (specifically a View of a Nodequeue of lead stories). The region is only used on the homepage, but because it's a region defined in my [theme].info file, it gets loaded any and every time that I request a page, even if I'm not displaying that region.

So...maybe defining a bunch of regions for specific pages is *not* the best way to go? Especially when you're going to be defining multiple regions for all your landing pages? Every time a page gets loaded, all that content (Views, static code, whatever) will be gathered from the database and stuffed into the variables[] array, etc. and all for nothing in the end because it won't be displayed. (for the beginners reading this, learn more about the variables[] array and preprocess functions)

So...instead of defining regions, should I be using the preprocess_page() function to figure out if I'm showing a landing page or something else, and if a landing page, figure out *what* landing page, and then manually assemble my blocks?

Con: completely bypasses the Blocks page, no nice 'n user friendly method of re-ordering blocks, adding new blocks to regions, creating custom blocks, etc.

Pro: does not needlessly query the database if the content of the region is not going to be used.

Thoughts? Is my understanding incorrect, or does it even matter to Drupal in the end 'cuz the cacheing is so good?

EDIT: Ok, found a pseudo work around. For the blocks that are in my custom regions, I can configure them so they only show up on the pages that those regions are called in. Ex. for two regions I'm using on my homepage, I make sure all the blocks in those regions are only available on "<front>". Not perfect, but it will stop Drupal from unnecessarily processing those blocks.

Edited by WorldFallz - added code tags.
Edited by smacphail, fixed typos

_

WorldFallz - April 8, 2009 - 20:42

Did you try using a page-front.tpl.php and only printing those regions in there?

_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.

...

Jeff Burnz - April 8, 2009 - 21:01

I make sure all the blocks in those regions are only available on "<front>".

Yep, thats precisely how you do it, otherwise it can be a huge performance drain.

I try never to allow allow blocks to be shown globally (on all pages), especially if there are thousands of free tags or other generated pages such as from view args. You may not even realise the bots are finding these pages but your server sure does:)

@WordFallz...yea, it doesn't

smacphail - April 9, 2009 - 21:32

@WordFallz...yea, it doesn't make a difference whether you use your defined region or not, the block is still "firing" and being prepared for display, but it's wasted effort because you never use the display code.

@jmburnz...thanks for the confirmation! :)

Still not sure this is the best way to approach this layout issue - my Blocks page is pretty massive (I have over 30 regions now) and slow to load and make changes (jQuery chugs a little trying to parse all those table rows/forms every time I move a block around). Will investigate other solutions like Composite, or Panels when it comes out of alpha.

_

WorldFallz - April 9, 2009 - 23:03

You may want to checkout the http://drupal.org/project/bpv and http://drupal.org/project/bpv modules.

_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.

Thanks!

smacphail - April 15, 2009 - 16:05

Great, thanks for the link! I'll have to look into it later, see what "dev" means for this project. ;)

_

WorldFallz - April 15, 2009 - 16:37

Obviously I messed up one of the links, lol. The other link should have been: http://drupal.org/project/block_assign

_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.

Regions/Blocks definitely not the route...

smacphail - April 15, 2009 - 16:17

...I should have gone down. My blocks page is massive now that I have all the section landing page blocks in there and I'm getting "Unresponsive Script" errors when trying to load the page. (jQuery basically trying to tear through every table row and add the draggable functionality.)

For a smaller site, maybe, but not for this one. Next time I'll try Panels or Composite. :P

Thanks for everyone's help.

 
 

Drupal is a registered trademark of Dries Buytaert.