Custom Menus (tabs)

The menus module in Drupal core allows you to manipulate the system menus through the admin GUI interface (admin >> build >> menus)

However, it does not give you control over at least two key aspects of the menu:

  1. Access control - does not allow any specification of who can access the menu item;
  2. Tabbed menu - not possible to add or edit tab-style (local task) menu items;

These can be controlled if the menu is built programmatically.  For these reasons, I created a custom lasqueti menu module (lasqueti_menu).  This module does the following:

  • Creates the menu items for this Design Notes book, and restricts access to only those who have 'access administration pages' privleges.   Otherwise the Design Notes can either not be placed on a menu, or will show up to authenticated users on the site (in their personal menu - the Navigation menu). 
    An alternative would be to use the "menu-per-role" module, but this seemed overkill for hiding one book, and the module requires a core "hack", so not nicely maintainable.
  • Creates the "tabbed" menu pages under the Primary Menu tabs.  The module does two things of interest:
    1. creates the basic structure of the tabbed menu system;
    2. handle display of single node pages that appear on tabs, where required.
    3. handle display of teaser views that appear on tabs, where required.

See the following pages for more information about working with and maintaining these tabbed menus.

 

Conceptual Overview

The idea behind tabbed navigation is to provide the user with a spatial orientation to the context of the page they are viewing.  The tabbed layout creates its own, implicit "breadcrumb" by always showing the user exactly where they are in the structure.  Thus, you'll notice that the breadcrumb has been removed from these pages.

The tabbed menus only present information that is available elsewhere on the site.  It is meant as a seperate navigational structure, primarily aimed at users who are new to the site, and simply want to browse around.  Thus, the tabs are organized into "categories of interest" - so users can view all content on the site related to their interests.

To this end, tabs "pull-in" two distinct kinds of data:

  • Individual pages - where relevant, single pages exist, these are displayed in their full form on the tab;
  • View of related teasers - where there are multiple pages on the topic, a view of teasers is presented.

The teaser lists are almost all generated by a single view named "by_category".  This view simply lists teasers for all nodes, using a "Taxonomy:term id" as an argument.  The tabbed menu code supplies the relevant taxonomy terms for the Views argument  when the view is built, to pull-in all the related nodes.   In this way, whenever a new node is added or a the categories of a node are modified, it will automatically show up on the right tabbed page.

When a list of teasers is presented, there is always a "heading" node placed at the top of the list (simply by tagging it with the right categories and making it "sticky").  Although this "heading node" is just a normal node with the title set to the tab title and the body containing an overview of the tab's contents, it is not used as a normal node, and should not appear in any other displays (I hope!).   Some special logic was added to template.php and node.tpl.php to handle this node, but ultimately, these may need to be stored in a special node type so their display in other lists can be contolled more easily.  An alternate implementation would be to display the heading node explicitly during _display_view in the custom tabs module.  This way those nodes could be controlled very precisely.