More than 9 banner positions?

Currently only 10 positions are supported. For the 4.6 release I plan to modify this logic to let you have an arbitrary number of positions. And to refer to them by name, rather than a meaningless number.

That's good news. The NHPR.org site I'm working on needed "name" functionality.

I forked the 4.6 version of the module without this change. I still intend to implement it in the cvs version, and will update this issue when it is ready.

I've attached a patch that:

* allows banner groups to be named
* allows an infinite number of groups.

This is actually quite a small patch, because I utilize the theme system to provide the customization. The idea is that since the template person has to modify the templates already (to place the banner_display properly), then he is also the one "closest" to the proper naming of the banner groups, as well as deciding how many he actually needs. Thus, this patch creates a new theme_banner_groups function that the template designer can override, like so:

function phptemplate_banner_groups() {
  return array_merge(array(0 => 'header'), range(1,9);
}

Here, the template designer is using the default 9 positions, but is giving the first position, 0, the name of 'header'. This name is used in dropdowns and in stats display. The banner administrator still has the 9 other (unnamed) banner locations to use. In the following example, three names have been created, and these are the ONLY positions available:

function phptemplate_banner_groups() {
  return array(0 => 'header', 1 => 'footer', 2 => 'sidebar');
}

Banner administrators will ONLY be able to choose one of those locations. Finally, this last sample shows three named positions and an extra 20 (or so) unnamed ones:

function phptemplate_banner_groups() {
  return array_merge(array(0 => 'header', 1 => 'footer', 2 => 'sidebar'), range(3,23);
}

Please consider this patch - it's small and quick.

Bah! Better one attached.

My apologies. Here is the correct patch.

These additions were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute code they feel the community will benefit from. Questions about this code should be directed to morbus@disobey.com.

Interesting idea. I had intended to make it possible to add/edit/delete groups via an administrative interface, but I like how lean this patch is.

Ufortunately I'm currently unable to test this patch, until after the 6'th of June. However, at that time I will test this on my dev server, and possibly merge it into the CVS release.

Thanks a lot for the patch! :)

For what it's worth, +100 for this patch. ;)

I was given the task to install the banner module on a 4.6.3 site and set banners to only show in certain pages, and within either a top or bottom region on each page (for example, Home, Products, Events, etc.). My first inclination had been to use the CVS version of this module with taxonomy support, and then have the site admin define something like group 1 for top, group 2 for bottom, select the taxonomy, and then do some crazy logic against the path to determine what should go where. As I delved further down that path, I realized I was basically going to have to duplicate the banner_display() code but adding taxonomy filtering and was generally getting really frustrated trying to get the code in general to work with 4.6

Luckily, I talked to Morbus during one of these hair-ripping-out moments, who pointed me to this patch. Now I've been able to define user-friendly groups for each page (home-top, home-bottom, events-top, events-bottom, etc.) and the path logic, though still pretty messy, is at least more managable now.

Thank you, Morbus!!

Closing this since dopry's patch (http://drupal.org/node/82587) will give us this functionality with a wellknown interface.