By pommac on

Hi!

I'm not super happy with the way theming works in Drupal. I really like the concept of regions and I really like the concept of blocks, but I really wish there was some kind of page templating system available. My problem is this: it's really easy to define a page by adding blocks to the various regions. Left sidebar gets the left menu, header region gets the top menu, etc. The problem is: not all pages have a left menu. Some pages have an article listing there. Some articles include a calendar-booking block in the right sidebar, some don't, and my client has literally hundreds of articles so entering them in the comma-separated list isn't really viable.

Is there a module that adds page templating to Drupal? I'm looking for something that would enable several configurations of the "Site building -> Blocks" part of the administration. For instance, I'd like to create an "Article page without calendar" template, an "Article page with calendar", and put them on the site easily. The Panels module is close, but not exactly what I'm looking for since every time you want to create an Article page you have to add every block (header, article, image, calendar) and as I said, it's hundreds of articles. Is there a clever way to do this? A module that implements something like it?

⋅ Categories: Drupal 5.x

Comments

dman’s picture

dman commented

Is there absolutely no pattern or logic at all to what articles have which blocks next to them?
If there was any trigger you could identify (eg 3 levels deep in the heirachy, tagged with a certain term, or contains a key phrase in the content) it would be straightfoward to do it using the php code visibility region on the block.

Otherwise, you really do need to list the pages one by one, and thus there's no 'easy' way to do that. An interface you could use on the node edit page - checkboxes for each optional (not each and every) block would be handy for you.

Page templating as you define it - article with/without calendar - is currently done as content types, tho that would feel like overkill for this.
I've worked around this before now by implimenting a 'page type' vocabulary that simply lists a few of the special cases I needed to support (normal page, page with pullquote, FAQ page) that refine the base 'page' type without changing its definition, then tuned my template to hinge on that. You could do something similar.

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards