Firstly I apologise if this has already been answered. I thought it would be a common problem and I'm surprised that I haven't found a general solution anywhere.

I have a large corporate website (about 8000 pages) which is currently organised in our existing CMS in a multi-level tree structure. The navigation menus, breadcrumbs and URLs are all automatically built based on the position of content nodes in the tree. This makes it particularly easy for content editors to create new content in the right place and have the menus, breadcrumbs and URLs always consistent.

We are probably going to move to Drupal 7. What is the standard approach to large, tree-structured sites like this? I don't want to have to create new tag names (taxonomy terms?) for every single section since there are hundreds of 'container' type pages that contain lists of other pages. It seems far easier to just slot the node into a tree.

I suspect there is something obvious I'm missing - I would think it is pretty normal to have a tree like structure of content. Any help much appreciated.

  • 1
    Check out the core Book module - it allows you to have tree-like structure on multiple levels. However, I'm not sure how does it work if you have too many pages grouped into one "book". What is the structure of those 8000 pages? Are they split into sections? How many pages are in each section on average? Commented Oct 17, 2013 at 5:48
  • You can just use good old menus, and build breadcrumbs based on that. That way you could even avoid the need of container pages and make lists automatic. If that's what you want, I might try to provide answer more detailed.
    – Mołot
    Commented Oct 17, 2013 at 7:57
  • @Topsitemakers the content is grouped into sections (using the global top menu), then sub-sections, then sub-sub-sections etc about 4 levels deep on average.
    – Flash
    Commented Oct 17, 2013 at 8:03
  • Although you have specifically said you do not want to use taxonomy it would be worth using it as it makes it easier in the future. The answer to the question how does drupal handle a large content hierarchy is taxonomy. The only other alternative is to create a reference in each node to the parent node but that could get too complicated Commented Oct 28, 2013 at 16:22
  • @DanielHarper I'm happy to use taxonomy as long as there's a way to automate the generation of the above 'container' pages, navigation etc rather than manually telling each which taxonomy terms to pull up (I am new to Drupal so might be using the terms wrong).
    – Flash
    Commented Oct 30, 2013 at 11:18

6 Answers 6


Good strategy is to utilize Workbench and create sections from your menu.

So you would have your main menu, lets say 3-4 levels deep and mimic those in Taxonomy. Its easier to create taxonomy first as there is a module that will create menu from taxonomy.

So you create your taxonomy that has your structure going 3-4 levels deep. Then create a menu from it.

Install Workbench and Workbench Access and Moderation modules.

Configure Access to use Taxonomy for section assignment and then configure URL parameters to pull from Taxonomy as this will take care of your URL and breadcrumbs. Use Custom Breadcrumb module to generate breadcrumbs if you need them.

Then on each content type add a new filed for Sections which will pull from your taxonomy. So when adding content you select where in the tree it should live.

For example you are adding "Help" node which needs to live in About Us > Services and About Us and Services are in the menu. Help does not need to be in menu but needs to follow the About Us > Services > Help path.

By using Workbench modules you can easily achieve that. In a sense your taxonomy acts as buckets into which content is placed. This drives URL, Breadcrumbs as well as left or right nav menu if you need one using Menu Block.

So to summarize the steps:

  1. Create taxonomy of the items you want to be in menu.
  2. Create menu from taxonomy using Taxonomy 2 Menu module.
  3. Install Workbench suite of modules.
  4. Configure workbench access to pull from Taxonomy.
  5. Adjust content types to add a fields for Taxonomy selection, make it only 1 as you don't want multiple paths for nodes.
  6. Configure URL Patterns to pull from taxonomy parents.
  7. Install and configure Custom Breadcrumbs to also use URL path.
  8. Install and configure Menu Block to use URL path.
  9. Start adding content and assigning sections.

Additional benefits of this approach is that you can also restrict which roles or users can edit content in each section so you can have HR only have access to edit content in their part of the site.

  • Thanks - are you referring to this module: drupal.org/project/taxonomy_menu? When I update the structure later will I need to manually update the taxonomy and menu separately or can I force them to match? Also, would this be the standard approach to my situation?
    – Flash
    Commented Oct 30, 2013 at 11:50
  • Yes that is the module, so what we usually do is create taxonomy first so we can convert it into menu. Going forward if you add a new item in menu you would need to add it to taxonomy only if there is content that would go into that section. For example if you just want to add one node then just add it to menu, but if you are adding a node that has children then you would add that node to menu, and do same in taxonomy. Then other nodes that need to go into that path would be added by selecting that section. This is a workflow we have used over and over and works well large sites.
    – pgrujic
    Commented Oct 30, 2013 at 12:17
  • This is what I needed to get started - thanks for the detailed answer.
    – Flash
    Commented Nov 1, 2013 at 2:43

Nothing stops you from using taxonomy, in fact you should be using taxonomy for categorization since a tree is a simplified and hierarchical form of taxonomy. So a tree is a subset of the features of taxonomy.

Since you can create taxonomies children and parents, you got essentially a tree. Drupal is all built around taxonomies so you really want to stick to using taxonomy if you go with Drupal.

there are hundreds of 'container' type pages that contain lists of other pages. It seems far easier to just slot the node into a tree

You are describing a View here, and they can be programmatically created whenever someone requests the content of a section (a taxonomy term indeed). Think of it as an index that keeps itself updated automatically. The Views module is almost mandatory for every site.

You should really take your time thinking about the design and structure of your site before getting your hands dirty. The better the design, the lower execution time, this is so true with Drupal.

Hope it helps.


I posted this some while ago: "Order as text, manage huge trees with your favourite code editor" https://groups.drupal.org/node/254588.

Maybe not exactly what you could use, but just food for thought.

The idea of this module that I put together for myself is to grab the tree as text from UI, edit it in a code editor, paste it back, and save. Drupal crunches, creates the tree and you can view the hierarchy in a view that takes care of the tree formatting.

The cool thing is that code editor can handle hundreds or thousands of rows where browser can't.


I would say you don't need taxonomy or anything else, but ONLY a menu structure.

The menu system is enough to define what is the parent and what is the child, and the order of the children.

The Book module (shipped with core) uses the same strategy, but probably you don't even need that.

Problem 1: How to edit large menus?

  • The menu configuration form will get very heavy if all menu items are loaded at once.
  • There is no convenient bulk editing. Or is there?
  • You may want a workflow that lets you build the hierarchy first, and add the nodes later.

Well, Menu editor does help you with the bulk editing. But it can only handle so many menu items at once. No hard limit, but it will slow down everything - but give it a try! There was a feature request that asked for paging, but this is naturally hard within a tree.

It also helps you to create dummy menu links that can be fleshed out (filled with nodes) later (via me_node_creation submodule).

So you could try this and help me improve this thing..

Problem 2: Display sub-page teasers

You said some of your pages are like containers for sub-pages. You probably want these to show a list of sub-pages.

One way I did this on a client side was to use Menupoly and create a custom MenuTheme that will render every link as a node teaser. Then a block via hook_menupoly to display the submenu of the current page using this MenuTheme. I think I should upload that code in a sandbox!

I am sorry, this stuff is all "needs work", and I would love some help. But I think it can all become pretty cool.


To the OP about "How to manage huge menu trees" you can try https://drupal.org/project/bigmenu which is a drop-in replacement to the Drupal (6 & 7) menu admin UI that uses AJAX to load the subtrees as needed.

So you can expand and deal with just the sections of your thousand-item menu list without the all-in-one menu UI falling over.


I'm looking at Drupal for the first time and I found the lack of hierarchy support troubling and I think constantly updating taxonomies would be too much overhead for any large site, especially with a distributed authoring base (e.g. large corporation or government agency).

I think I have found a solution using module Node Hierarchy (primarily) and some other modules.

Essentially you specify which content types are allowed to be children and/or parents, and then when editing a node you have the option to 'create child'. Once child nodes are created, the parent node will have an option to view child nodes, and ordering can be controlled from this screen.

Use module Pathauto to automatically render URL alias based on parent-child-[child] relationships.

Finally use module Menu Block to add menus based on parent-child hierarchies.

A more detailed description/instruction is here:


EDIT: Updated my answer to better conform to guidelines.

  • This is not a thread, because this site is not a forum. And links to answers are not considered answers here. Ask yourself: will your post be useful as answer if the clip you linked to will be removed? If no, you shouldn't post it. well, maybe as a comment.
    – Mołot
    Commented Nov 14, 2014 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.