The problem

One of Drupal's biggest wekanesses, at this point in time, is its lack of support for a basic hierarchical site structure. At the moment, there are two main modules that handle the structuring and classification of content on a Drupal site: the Book module, which organises content into a nested hierarchical structure; and the Taxonomy module, which classifies content according to terms from various vocabularies.

But these two modules are totally separate. The book module works purely at the node level: one node is the child of another node, which is in turn the child of another node, etc. The taxonomy module works somewhat differently: one node is assigned a number of terms, which belong to one or more vocabularies. However, neither a taxonomy term nor a vocabulary is a node.

This means that you cannot create content for a particular term, to use as its description (unless you use taxonomy context), and it means that you cannot perform other operations on a taxonomy term, such as commenting, versioning, workflow, input filtering, etc (unless you use taxonomy associations). More importantly, though, it means that you cannot make a taxonomy term part of a book hierarchy, because a term is not a node (although you can assign terms to a book node, as to any other node).

Example scenario

John wants to create a web site for his new travel agency business, and has decided to build the site using Drupal. John wants the following structure for his site:

Home (short blurb, and latest articles)
--Travel info
----Holiday packages
----Promotional offers
--News and articles
----By region
----By topic
--About us
----Our team
----Work for us
--Contact us

John posts a new topic on the forums, giving the above structure, and asking what he should use to implement it (I'm sure many of you have seen countless such forum posts!). He explains that:

  • The 'travel info' page will be a static page with general stuff about why customers should choose his agency to plan their next holiday.
  • The 'holiday packages' and 'promotional offers' pages will both be static pages, but new packages and offers will be added beneath them regularly. Some packages will also be offers (and vice versa), and will need to be listed in both sections.
  • The 'news and articles' page will be a static page, as will the 'by region' and 'by topic' pages. However, every new article should be listed under 'news and articles', and will also be listed under various subcategories in the 'by region' and 'by topic' sections.
  • The 'about us' and 'contact us' sections will be all static pages.

Various people reply with various suggestions:

  • Make all the pages part of one big taxonomy hierarchy, using one vocabulary. Use taxonomy context to give the terms descriptions and make them look like static pages. Drupal won't represent the hierarchy accurately in its menu blocks and breadcrumbs, because taxonomy is not really for hierarchical pages, but oh well.
  • Make the top level pages part of one vocabulary, and use other vocabularies for the sub-sections. Drupal won't recognise that the sub-sections are part of the hierarchy (unless you use distant parent), but oh well, at least you'll be able to categorise everything nicely.
  • Use taxonomy for the dynamic sections of your site, and the book module for the static sections. If you ever decide you want to post dynamic articles in a static book hierarchy, you can't, but oh well, you should have thought about that earlier on.
  • Make the whole thing a book hierarchy. Don't use taxonomy - it's hopeless at hierarchical structures. You won't be able to put one article in more than one section, but oh well, at least your menu blocks and your breadcrumbs will all look good.
  • Make all the main sections a book hierarchy, and make the 'packages', 'by region', 'by topic' things taxonomy terms. Those terms won't be treated as part of the hierarchy, but oh well, you can't have everything.

None of these suggestions are perfect - John expected that for something simple like how to structure the pages on his site, someone would reply with a simple, straightforward answer. What's all this stuff about 'taxonomy terms' and 'book hierarchies'? He's not creating any terminologies, and he's not writing a book, either! All he wants to do is create some simple sections for his site. He considers ditching Drupal altogether - if it can't even do something this basic, maybe it's not worth bothering with after all.


Merge the taxonomy module and the book module together into a single module. The name of such a module is open to debate: I suggest calling it the 'category' module.

This module will define two new node types called 'category' (what is now called a 'term') and 'vocabulary'. As with the existing taxonomy module, terms can be applied to other nodes, and a term's page will list all nodes that are assigned to it (underneath the content of the term itself). Since terms are now nodes, it will also be possible (although I can't see the applications of it) to assign one term to another term. Vocabulary pages will show the node's content, and will be able to show a list of terms (possibly the whole tree?) within that vocabulary.

The 'outline' feature of the book module will be retained in this module. There will be a 'category' tab, which will allow users to quickly transform a node into a category, and to make it the child of another node that is already a term or a vocabulary. This is the same as the way that a node can currently be made the child of an existing page in a book hierarchy.

It will be possible to create a new vocabulary, and to make it the child of an existing term or vocabulary. This will be an improved version of the functionality currently possible with the distant parent module. There will also be an option to 'exclude this vocabulary from the category hierarchy', if for example you create some top-level structural categories under the 'sections' vocabulary, but you want nav blocks and breadcrumbs to display 'home -> about -> mission' rather than 'home -> sections -> about -> mission'.

The 'categories' administration page will be largely the same as the one that is displayed by the existing taxonomy module. Categories will be grouped by vocabulary. Selecting 'add vocabulary' or 'add term' will direct the user to the node creation / editing form for those nodes. All options currently available on the 'create vocabulary / term' forms (e.g. hierarchy, related, synonyms, weight, etc) will instead be shown on the node editing form for these node types. Free tagging will still be possible (and just as intuitive) in this module.

Target audience

This module will be aimed primarily at 'corporate' Drupal sites, where there is a strong need for a way to create a simple hierarchical site structure that can support both static and dynamic content. The lack of an obvious way to manage the structure and navigation of a site is currently making many corporate users reluctant to choose Drupal. However, this module is something that almost every type of Drupal site (e.g. blog, community, media-based) could benefit from.

I also hope for this to be the 'dream module' for my own personal use. I created the distant parent and taxonomy assoc modules as attempts to make some of this functionality possible using the current taxonomy module. However, an overhaul of the whole category system in Drupal is needed in order to do this properly and effectively.

If we go back to the example of John and his Travel Agency web site, we can see just how useful a 'category' module would be in a corporate or small business situation:

Home (short blurb, and latest articles)
--Travel info (category/term node)
----Holiday packages (category/term node)
----Promotional offers (category/term node)
--News and articles (category/term node)
----By region (category/vocab node)
----By topic (category/vocab node)
--About us (category/term node)
----Our team (category/term node)
----Work for us (category/term node)
--Contact us (static page or category/term node)

Possible criticisms

Taxonomy terms (in the current taxonomy module) are tags that are supposed to define a node's classification. A term itself is not content. It's wrong to turn a taxonomy term into a node type.

True - this is what taxonomy is currently designed to do, and in the situation of most Drupal blog sites, this is exactly what it is used for - tagging nodes, and nothing more. Many Drupal users won't see the need to turn terms into nodes, nor will they see the need to arrange them hierarchically, book-module style. But just because a term is a node, doesn't mean you have to give it any content! Even as a node type, a term can still be nothing more than a tag that you apply to other nodes. So you will still be able to use taxonomy in the same way using this new system. And, should you ever decide that you need to give your terms a description (and the raw text description offered by taxonomy context is insufficient), and that you want them to form the structure of your site, you will be able to do so with incredible ease.

Won't this impose a rigid hierarchical structure on all sites that choose to use taxonomy? Isn't taxonomy designed to be flexible and to support more complex, non-hierarchical classifications?

As with the point above, it will be possible to use the category module in exactly the same way as the taxonomy module is currently (designed to be) used. That is, your site can still have a non-structured heap of blog entries and articles and what-have-you, and they can still be classified non-hierarchically according to taxonomy terms drawn from one or more vocabularies. The inherent power and flexibility of taxonomy will not be compromised - rather, it will be complemented by the straight-forwardness and simplicity of structure, hierarchy, and navigability (should you choose to configure it like that).

This module will only confuse users who are trying to create a hierarchy of pages, and who currently have the simple and easy-to-use book module at their disposal.

For those users that only need a hierarchy of pages, and that don't use taxonomy at all, I admit that this module may be seen as pointless. The whole purpose of this module is to bridge the gap between the book and taxonomy modules, and to eliminate the problems that currently exist in getting them to co-operate in structuring your site. It is a very likely danger that users will be confused as to the difference between creating a new 'category' node and outlining it in a hierarchy (book-style), and assigning a category (a term) to other nodes (taxonomy-style). However, I see no way to merge these two features together, and indeed I think that they should both remain as separate functionalities in their own right. I guess that the best way to explain the difference (by way of documentation - e.g. in the handbook) would be to suggest: making each static content node a category and including it in the hierarchy; and assigning categories to each dynamic content node.

Taking it from here

This is just a proposal: no code has been written yet, and nothing has been implemented. It would be great if you could give your comments here, and if we could get some discussion going to guide the future development of this module. The more discussion we have on this topic, the better we will be able to build a module that reflects the needs and desires of the community as a whole.

I am volunteering as the lead developer for this module, but I am also calling for any other interested developers to put their hands up and show their interest in helping when the time comes for coding. As with your comments, the more people there are involved in developing this, the more it will be shaped by the will of 'the majority'. If and when this happens, it is going to be big. Don't miss out on shaping the future of the Drupal platform!

Jeremy Epstein - GreenAsh


lennart’s picture

Jeremy I think your proposal is good.

I am myself in the process of setting up the structure of a site and have been going through many of the speculations that you mention. I currently use both the taxonomy system and books.

But when using a sitemap like sitemenu or sitemap it is clear that they do not take into consideration the book hierarchies. For now I have solved this by having direct handcoded links to about and 'press room' sections in books at the top over the sitemap itself, where as individual nodes will appear in the sitemap because the are also termed.

Best regards,

Best regards,

moshe weitzman’s picture

at first glance this sounds like a proposal worth exploring. this category module (il like that name too) can happily live in Contrib while it matures. taxonomy.module is not special, any other module can use the nodeapi hooks that it uses.

you will likely need to modify a theme in order to display category links, but thats easy to do. just include a suggested node.tpl.php along with your module.

your writing indicates that you've thought (and coded) about these problems for a while. I appreciate that, and look forward to your contributions.

venkat-rk’s picture

Hello Jaza,

I am surprised that such a useful proposal has received very few comments, but I think you can be very encouraged by Moshe's reply.

Having spent the last several months in trial and error to get this kind of functionality, I want this so badly that I am even willing to donate a bit of money- this and testing the would-be module are the only ways I can help.

All the best.

Bèr Kessels’s picture

This is what clipper.module wants to become when it grows up.
My plans for this was to make it a "general outlines" for drupal. The newt step, nideed was to add book paths (prev next) to them. Feel free to send in patches for that module!

Next time, please consider filing a support request.

[Bèr Kessels | Drupal services]

Jaza’s picture

I tried out clipper.module, Bèr, but: firstly, I got a whole heap of errors when trying to use it (tried it on 4.5, with flexinode, followed all instructions); and secondly, I don't really see what it does, apart from using a special 'clipper vocabulary' to group certain nodes together.

Unlike clipper.module, category.module is going to redefine the whole taxonomy system, rather than 'working around it'. Having all terms and vocabs as nodes is going to be fundamentally different to the way it is now.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

FabriceV’s picture

Dear Mr,

Jaza pointed out that it is possible to use different modules and solution to create hierarchies. He shows that these answers are ofen partial. As a novice user, I can add that they really create a lot of confusions because a novice user can not represent the difference, the limit, choice between them, and implement it correctly. Furthemore, they add complexity and transform a simple publication process into a useless cognitive exercise. I have just spent 3 monthes of testing and learning just to approach your applied conclusions.

Thus :
1) thanks to your explanation. It merits to be added to the handbook and completed.
2) your proposal could not only resolve a problem but add coherence to an overall "pudding".
3) it could answer to a major weakness of drupal.

I will be pleased to translate your module, test it... let me inform. Sincerely.

Hosting Geek’s picture

Also as a newbie I was confused in between all these things... esp. with the weird names...

+1 to this propsal.

jasonwhat’s picture

Is it becoming something new? Moving to 4.6? It does create a term as a node which is great and has lots of possibility for maturing. I'm using it and would like to update to 4.6, but nothing yet. Node relativity has lots of possible uses for more dynamic structure as well, and the directory module. There is much going on, it just all needs to be combined and ordered to prevent replication and promote some uniformity.

lekei’s picture

I have been struggling off-and-on for 2 months (virtually full time this last week) trying to understand how to make a real-world, working web site using Drupal. Not being a newbie to CMS, PHP, web site development, mySQL, etc., I recognized the power of Drupal (after looking at over 50 CMS choices) but just couldn't get it!

Without your article series "Making Taxonomy Work My Way" and your helpful post to another perplexed user explaining that the whole "categories" vs. "taxonomy" terminology debacle is just an attempt at making things less confusing that went horribly wrong, I might still be lost.

This proposal would make Drupal work the way I presumed that it did. I don't care who writes the code as long as it works, but I hope YOU write the documentation so it doesn't take a month to figure out how to GET it to work.

It is that presumption, that makes Drupal so hard to use. Every web site that I have ever developed, or have on the books uses the structure you show. I was beginning to think that I needed to make two web separate sites that link to each other!


andrew404’s picture


This is a fantastic proposal, imho. You've very well explained something I've been trying to verbalise for awhile. I've been looking for awhile for a project or piece of work on Drupal to put my hat in and lend a hand. I'd like to help out with this in any way, I think it's a great idea and will be of great use toeveryone who uses Drupal.

Let me know how I can help,

venkat-rk’s picture

Hi Jeremy,

It seems there is a strong support for your ideas- I bet many more have been hurt from the RSI that figuring out drupal's taxonomy and hierarchical system gave them;-)

Let us know if and when you plan to start coding or if there is anything we can do to help you.

Jaza’s picture

Thanks very much to all of you who have given your feedback so far. All the comments so far have been amazingly positive - I'm really excited to see that so many of you share my enthusiasm about this important project!

I don't plan to start coding for another few weeks, as I'm quite busy with other work at the moment. I would also like to publish some specs and design documents before getting into the development phase. That means that there's still plenty of time for you, the community, to voice your comments, and to shape the outcome of the category module.

Although the feedback so far has been very praiseworthy (and I'm flattered by it!), there hasn't been much so far in the way of suggestions and feature requests. I know I've put quite a lot of features into the proposal already, but if there are any more you'd like to see in the eventual module, then now is the time to suggest them.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

venkat-rk’s picture

there's still plenty of time for you, the community, to voice your comments, and to shape the outcome of the category module.

Here we go, for the most basic type of hierarchical site:

1.) Being able to define three or four or five (or six!) primary links that are actually the vocabularies. Clicking on the vocabulary link takes to an index page for the vocabulary, which has a list of nodes associated with all terms of the vocabulary. This list should not just be a node list with the count in parentheses, but display the teasers with the read more links.

2.) Ability to display a block on the left or right of this index page that will contain a navigation menu for that vocab. This menu should contain links to the taxonomy terms for that vocabulary and should be built automatically, instead of the current manual way of linking taxo terms to a menu

jaharmi’s picture

I think point #1 here would go a long way towards replacing what I currently do with the metadata module (ala John van Dyk) for Userland Manila. Having primary links that go to vocabulary links would be much like having saved searches.

As an example of what I have done with the Metadata Manila plugin, look at this static-rendered (i.e. published to flat files) page that uses Metadata’s fields (something akin to taxonomy) to build a list that links to relevant pages:

This page shows that I’m able, with the Metadata plugin for Manila, to create a list that provides:

  • links to original stories on separate pages
  • replacement text for each link
  • pre- and post-item formatting (i.e. inserting the list item tags), and other text for each link either the before or after spots (i.e. the questions-and-answer and line formatting)
  • pre- and post-list formatting (i.e. inserting the list tags)

I’m not sure how to re-create this in Drupal with my limited experience yet — I’m not really to convert my personal site over, although I’d like to, until I can at least get Manila data migrated to Drupal.


lennart’s picture

Jeremy thanks for giving us the opportunity to influence the development of the category.module.

Probably you already thought about these things since I remember you wrote those great tutorials about breadcrumbs.

It is possible to get to a certain (content-) node from many directions if it has been ascribed more than one term, and if it has one or more parents, but allowing the weight system to influence which breadcrumb will actually be displayed when you have finally arrived at the node and displayed it in its full length - would be really great!

Consider the following example:

We have three vocabularies: Language, Topic and Type
Each vocabulary contains a number of terms; e.g.

Danish, English and German for Language
Pollution, Crime and Taxes for Topic
Article, Petition and Essay for Type

As it works now, if any node is assigned one term from each vocabulary the final breadcrumb shown when displaying the full view node will simply depend on which term is alphabetically closer to A.

But by using the weight system it would be possible to decide which vocabulary the breadcrumb should follow in full view mode.

I should note that it is already possible to do this now - indirectly. It just requires a bit more work, because it has to be done at the term level, e.g.

Setting all terms individually in vocabulary 'topic' to a lesser weight than all terms in vocabulary 'type' will make the breadcrumb follow 'topic'.

From a usability point of view it would be even better if the breadcrumb would follow weight of vocabulary first, and only the weight of terms when those are unequal.

Which would have higher priority in deciding the 'final' breadcrumb; child-parent relationship, or term weight, alphabet, or maybe - somehow - the path taken to arrive at the particular node.

Further, you should consider how category.module would work together with pathauto.module to create consistent URLs that would follow the breadcrumbstructure based upon the above mentioned concerns.

Finally consider how to make to module fully multi-language ready and configurable.

Best regards,

Best regards,

Prarie’s picture

I put a kludge together to deal with this problem for a few sites. I called the module sections (I know there is another one called that), which could have content assigned to each section (base on node types, vocabularies, terms or actual nodes as well as paths).

It was a pain to program, but it does what I needed. (You can see it in action at

I wish I had had your insight when I began development with that module. Your idea would have been much much more elegant.

When it came to remaking my own site ( I didn't want to use the sections module since I wasn't really happy with the way the menu fits with the sections module. I wanted something that would be easier to manage and would use only "standard" drupal functions. I found it quite challenging to make it do what I wanted (which was sooooo simple).

Sounds like your idea would suit my site perfectly. I would be happy to help develop this change if you'd have me.

sepeck’s picture

Drupal let's you do a lot. I can build your proposed site with Page, Menu, Story, Path and taxonomy modules. In fact, I used blog module instead of story module for a school project that is remarkably similiar.

This is not to say that your solution or others won't help, I am just saying that the solution is not always more code :), perhaps more effort on setup guides. I wish I had time to have this already written up, but I haven't. Maybe in a week I will have something for you. Then again, maybe you will have a module finsihed by then.

Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

bomarmonk’s picture

I believe taxonomy should be able to work powerfully with every content type within a Drupal site. Your proposal sounds like it will only allow for more options on how users implement their taxonomy--- and more flexibility is always a good thing.

This certainly sounds like a plus for sites like the one I've been working on-- where hierarchy is foremost! Thanks for your contributions!

eferraiuolo’s picture


To start I really like the way you presented your proposal. It's like you have taken my jumbled thinking about creating a back-end structure for Drupal and translated it into this proposal.

After testing Drupal and other CMSs for several months I have really started to like the way Drupal does things compared to the other open-source solutions out there. The two main packages I have been working with, Drupal and Xaraya both have confusing, abstract, and partially incomplete ways of creating a back-end structure for a website. Recently I have dropped consideration for Xaraya because of its way of categorizing content, and navigating through the classification. With Xaraya I wasn't able to navigate through my categories the way I wanted because their navigation allows for 1 content type. I would have to add a navigation block for each content-type. Also Xaraya is so abstract in its design that the learning curve is too steep for people other than full-time web developers.

Getting Xaraya out of the picture, I came back to Drupal. Drupal is alot easier to start learning, and easy for non-web-developers to use. But when actually sitting down and thinking of how to structure a site I was jumbling between the book and taxonomy modules as the way to structure my content. Realizing that I needed functionality from both.

Your module is what drupal needs, and if it works like you presented, then it should be considered as a core module. But before we get to that part, a lot needs to be done and I am willing to help with development/testing in anyway I can.

Somethings I would like to see:
When selecting a category it will show a list of sub-categories (if any) then a list of all content under the category which would include content tagged with the sub-categories. This way when a user clicks on a sub-category it would filter out all other content leaving what was tagged with the sub-category.

Also block navigation. I like the way the admin menu and book navigation works in Drupal and the breadcumbs produced. I would like to be able to navigate through my categories in a hieracial structured form with the ability to apply weights to vocabs and terms to control their position in the block navigation. I know this sounds just like the book navigation, but with using categories you could tag content with mulitple terms so you could get to the same content with multiple routes through the navigation without the need for redundant content.

Good work so far!

Jaza’s picture

Hi Eric,

Thanks very much for your feedback on the proposal - there's nothing I welcome MORE in this thread than constructive criticism!

Regarding the ability to filter out content in a sub-category, what you're really asking for is a setup where, on a category's node listing, it displays not just content tagged with that category, but also content tagged with any sub-categories. I already intended to make it so that a sub-category only displays its own content - indeed, this is how the taxonomy module already works.

This is not something that I've thought about before, but I like the sound of it (as an option that can be enabled/disabled, at any rate), and I welcome your help in developing it. You can basically get the same result by using multiple vocabularies, but that may not be how everyone wants to structure their site, so the more flexibility, the better.

About your block navigation suggestion, since this is something already offered by the book module, it will be included in the category module. The idea is that the category module will have more features than the book or taxonomy modules (i.e. all features currently available, + additional ones), not less!

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

styro’s picture

I have just hacked taxonomy context to do something kinda like this, but kinda different at the same time.

What I've done is added the ability to specify for any given vocabulary whether you want another vocabulary to be a second level filter on the /taxonomy/term page.

For instance say you have a Subject vocab (eg dogs, cats, horses etc) and a Purpose vocab (eg training, feeding, caring etc), when you select the taxonomy page for a Subject term you will get a filter menu to filter further by Purpose terms (just the top level ones at this stage).

The links in the menu just use the /taxonomy/term/x,y syntax to specify an AND query. It also uses the settings page for taxonomy context to allow the admin to enable or disable it and specify which vocabs get filtered by which other vocabs.

It's my first attempt at module hacking, so it probably doesn't fully do things the correct Drupal way yet. I've yet to decide what to do with it - eg upload it as a patch to taxonomy_context (and hopefully get it merged in) or somehow turn it into a standalone module than can work over the top of either the taxonomy or taxonomy_context modules.

toddgator’s picture


I nearly abandoned Drupal because I need this functionality. Please let us know when it is ready.

Our fate is in your hands!


bilgehan’s picture


I am quite new in Drupal and still in the process of learning how it works. I have some suggestions and maybe a new feature request about filtering the content acording to the terms chosen in vocabulary.

What my dream feature is being able to filter out nodes from more than one vocabulary.

Let me explain this using the Jaza's example of John's Travel Agency.

Lets say we have the following vocabularies and terms in the News and Article section:

By region

By topic
--historical places
---5 star
---4 star
---3 star

So if an user needs to see a list of 4 star hotels in Madrid than the module should be able to filter the nodes from both vocabularies.

To achive this my first idea is that there should be 2 breadcrumps to chose through.
For example:
List of 4 star hotels in madrid and in its subcategories
By region:Europe->Spain->Madrid
By topic:accomodations->hotels->4 stars

Example 2:
List of all hotels in spain and in its subcategories
By region:Europe->Spain
By topic:accomodations->hotels

I don't know if this can already be done with the existed modules or if I'm asking something completely new.

Waiting for the module to come out soon.
Best regards

Jaza’s picture

It is already possible to get a list of nodes that are tagged with one term AND another term AND another, etc, using this feature of the taxonomy module:


The above example would list all nodes that are classified under all those three terms. This feature will still be available in the category module - except that containers/vocabularies will also be able to be used in this way.

Having multiple sets of breadcrumbs sounds like a pretty cool idea, but I have no plans to implement it in the category module. There are many things that would need consideration if this ever became a feature. E.g. How would you determine the points in a category tree at which the breadcrumbs can 'branch off'? And how would the URL's look? I imagine something like this:


Where the 'cat_branch' values are the endpoints of the tree to which breadcrumbs would lead. But hey, much easier to say that in English than in Code. ;-)

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

jasonwhat’s picture

Drupal does allow for good filtering by taxonomy and even node type with some modules added in, the problem is that admin has to manually create all the links. There is no feature for a user choose one term and have links to the filtering terms suddenly appear. I have a site that has the vocabularies, "Regions," and "Topics." If a user chooses the region "Africa" and wants to see all content about "Human Rights" in Africa, I have to create a block on the Africa overview page with manually constructed links to the the other tid's. If I also want them to filter by node types, i.e. blog entries dealing with human rights in Africa, there are even more links to create. Will this type of situation be dealt with in an automatic way in the Category module?

styro’s picture

Hi Jason,

I've got a customised taxonomy_context module (mentioned in an earlier reply) to do the taxonomy filtering you're asking for. I hadn't submitted any patches yet because I haven't got around to deciding how to implement it better.

But if you're willing to have a play with it, contact me via my user page and I could send it to you.

ChrisM’s picture

I've been trying out Drupal as a possible replacement for my current website...which is primarily static pages in a hierarchical structure.

My goals in using some sort of CMS are:
- wiki-like way to write simple pages (e.g. textile module)
- easier to manage navigation by defining some categories and placing pages into those categories - i.e. hierarchical structure
- access control for some pages
- allow visitors to post comments on pages
- make L&F changes in one place (themes)
- upload images and easily place links/thumbnails in pages with links to page with full-size image
- "what's new" pages for some sections with blog-like (chronological) listings of pages
- friendly URLs

From what I've read, Drupal seems to fit the bill. Unfortunately, everything thing I try results in blog-like pages. I've read that Drupal can do evernthing I want, but needs to be wrestled out of the blog-centric default configuration.

Your article sounds like it will do most of what I want. I look forward to giving it a try!

Your comments about corporate sites really hit home, too. As I've been looking at Drupal, I've been wondering if it would make sense for our corporate site. Without an easy way to define the hiearchy, I doubt I could sell it. But with it, and some time from a themes guru to get emulate our current look, I think they might buy into it!

nielses’s picture

I am currently considering what content management system to use for my site, which currently consists of static HTML. I heard that Drupal was the best open source CMS out there, so I installed it on localhost to try it out. I am very impressed by its elegancy and completeness.

However, I wanted to do a simple hierarchy of pages with friendly URLs and breadcrumbs. I read about taxonomies and books, but it just seemed very complicated. I thought about looking elsewhere, but then I found your suggestion. I am convinced that it will cover my needs perfectly.

If you and other PHP-gurus code this, Drupal will definitely be my choice. I look forward to see a beta.


ergophobe’s picture


While you wait for this module, try installing taxonomy_context (which will give your breadcrumbs) and pathauto (which will do a pretty good job with your URLs).

It's still up to you to handle the menus, but if you have the articles module, that helps, or site_menu.

Drupal is like PERL: if you've found one way to do something, it's because you haven't been looking very hard!

Yosemite Explorer - hiking and climbing in Yosemite (drupal)

nielses’s picture

Thank you for your suggestion.

I'll try out the taxonomy thing to get a feel for how Drupal works. Though, in the long run I'm sure that the category module will be the most elegant solution for what I want to do.


Jaza’s picture

I agree with rick's advice that users still stick with taxonomy while they're waiting for the category module to be released. Don't be too concerned about having to later switch to the category module - there will be mechanisms for converting your taxonomy (and book) structures to category structures.

The plan at the moment is for this to be released as a separate module (probably called category_import, or something like that). Ideally, this module will painlessly convert your existing structures to categories at the click of a button. However, this functionality won't be available until after the category module is released.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

eaton’s picture

I've bene kicking around ideas with a couple of other developers for a while now, and I stumbled across this discussion... there are a couple of concerns that I have, specifically with the statements that 'book' and 'taxonomy' are variations on a theme.

First, I agree that Drupal desperately needs a simple way to organize a hierarchy of pages. People -- especially web designers used to using directories and html files to classify content -- can be easily baffled by the 'vastness' of taxonomy. It solves lots of BIG problems but seems to ignore the little (and common) ones.

Taxonomy is a content categorization toolkit/api that's used in a variety of ways. It's used to tag modules with content metadata. It's used by third-party modules (Image, for example) to create custom browsing interfaces. And it's used by other modules (Forum) to function as a hierarchial structure.

I would much, much, MUCH rathe rsee a modification to the taxonomy module that allows vocabularies to be marked as 'internal' -- in other words, to be used and edited by a third party module rather than the user. I don't want to see Image Galleries and Forums and Books and so on when I go to the Categories tab in the admin view. Those taxonomies are managed by the modules that created them, using Taxonomy as an API.

Book,though, occupies an uncertain middle-ground between 'categorization' of content and 'creating direct relationships between pieces of content.' What we REALLY seem to want is an easy way to maintain parent/child relationships in Drupal, and to navigate those relationships programmatically to form breadcrumbs and menus.

That's something that taxonomy is ill-suited for, but needs to be flexible and robust, along the lines of the node relations module released a few months ago.

I like the idea that you're putting forward -- at least in principle -- but I'm concerned that it may try to jam a square 'taxonomy api' into a round hole, OR introduce another separate categorization system that is useful, but not flexible enough to solve a number of emerging problems with large scale drupal sites.

Perhaps I'm mistaking your post or misunderstanding -- or perhaps I just need my morning coffee... :-)


Jaza’s picture

I understand your concern, Jeff, when you say (about this proposed module):

I'm concerned that it may try to jam a square 'taxonomy api' into a round hole

And the result of jamming a square peg into a round hole is, inevitably, that all the stuff on the corners gets shaved off in order to make it fit.

I see it as a perfectly valid concern that jamming taxonomy and book together may result in loss of functionality. In fact, it's something that I've been aware of quite a bit while developing what I've done so far for the category module. But rest assured - so far, I haven't had to strip taxonomy of any of its functionality, in order to get it working in its new form. And I don't plan for anything to be stripped from it in the future.

Regarding your idea that vocabularies be marked as 'internal', this is actually implemented already in the existing taxonomy module. The vocabulary table has a module field, which records the 3rd-party module responsible for a particular vocabulary. However, this information isn't currently used by taxonomy's admin interface. Perhaps this would be a good feature to include in the category module (which stores this same data)?

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

MichaelFox99’s picture

I am wondering what familiarity you, Jaza, and the rest of the community have with the relativity module ( . Which, although a bit more sophisticated, seems to offer most of the functionality of the category module, while maintaining a very traditional parent-child approach to structuring content. The problem with drupal in this area needs to be tackled using tried and true methods, ie parent child relationships. I am a bit curious as to why you are so compelled towards storing structural information in 'category' nodes. Or perhaps you are planning on assigning parent nid's to each node (as the books module has done).

Finally, one of the major limitations of relativity at this point is that it doesn't work at all with organic groups, which I percieve to be a very important module. Do you expect the 'category' module to work in conjunction with organic groups at all?


Jaza’s picture

Hi Mike,

I have some familiarity with the relativity module - I had a look at it when it first came out at the start of this year. However, I was a bit turned off by its complex approach to relationships, which was based on a lot of mathematical theory (too high-level for most users).

Also, the category module (so far) has on the whole avoided re-inventing the wheel - as the title of this post suggests, it is the merging of two older modules into one new one. The relativity module, on the other hand, did do a fair bit of re-inventing IMO.

Another thing - the taxonomy module currently allows one term to have many parent terms. This makes it more powerful than a basic hierarchical system. The category module will continue to support this feature - as with taxonomy, the ability to have multiple parents is configurable on a per-container/vocabulary basis.

Re: organic groups support, haven't looked into it, but it sounds like something that would be worthwhile having.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

Annika’s picture

Hi Jeremy,
like everybody else, I hope you soon can turn out a category module. I'm a newbie who just spent two weeks trying to fix the navigation, and I'm on the verge of giving up, having spent too much time already on the site in question.

I've worked a lot with ExpressionEngine and love it (it just wasn't suitable for my current project). Drupal offers a lot that EE doesn't, but what EE has is an intuitive category management including a GUI that makes it very easy to use. Categories and subcategories can be combined.

It may not offer the vastness of Drupals taxonomy, but on the other hand it works. ;-)

It might just give you some inspiration.

moshe weitzman’s picture

a third hierarchy that some site builders are employing is the hook_menu system. see matt westgate built this site and uses menu system like below

  // The root menu item id of the submenu you want to display.
  $pid = 27;
  $mid = menu_get_active_nontask_item();

  $parents = _menu_get_active_trail();

  if (in_array($pid, $parents)) {
   // We want to always show the second hierarchy of navigation.
   if (count($parents) > 1) {
      $mid = $parents[1];
    return theme('menu_tree', $mid);

The authors on the site use the new "menu on the fly" in HEAD to add pages to the nav

And a 4th hierarchy system in core drupal is the comment threading. This system is very fast and clever. It is well documented in comment.module code.

Obviously, it would be great to consolidate these hierarchy models.

SimonP’s picture

What you're proposing sounds great, so I wouldn't want to burden you with anything extra, but have you considered how it could relate to the news aggregrator. I've never exactly understood why (historical reason? technical reason?) but it has its own set of categories.

From my point of view it would obvioulsy be better if there was just one set. At the moment I have two seperate but identical sets of categories, one for nodes and one for news feed items.

If it was possible for the categories.module to be used for classifying news feeds that would just be ideal....?

The other alternative, of course, is to get the news feed items treated as normal nodes and so be able to be classifed into the same set of categories. I know there are modules that can do this and that work is going on to improve the way they work - there's discussion of this at

Boris Mann’s picture

Do a search for aggregator2, it does this. Both feeds and feed items are nodes, and can be categorized using all the normal Drupal tools.

ultimate_fish’s picture

Hi Jeremy, what you're proposing sounds very interesting. I'm a newbie to drupal having discounted most php cms systems for their stupid navigation.

I'm happy with the principles of the current taxonomy module but what I want to be able to do is give each term an index page so the crumb trail actually makes sense without users being presented with a daft A-Z list of nodes.

I'd like the index pages to be completely customizable, a node in their own right I guess.

Is this something the category module would be able to do? I confess I've got a bit confused reading through all the comments.

I'd be interested to hear how things are going with the module. I'm very happy to help with any beta testing.

dkaye’s picture

Jeremy, et al...This is definitely a much-needed capability. I'm evaluating Drupal as a potential new CMS for IT Conversations, which will be quite hierarchical: Channels, Series, Programs, Components. I've had the same frustration with the existing modules and nodetypes: not even close. I'll also be very interested to see how we can wire this into a revived workflow module. My understanding is that the current workflow module (which doesn't work with the current rev of Drupal) is in need of some "love." FYI, I'm fleshing out requirements for the new IT Conversations CMS here.

Doug Kaye, Executive Producer
IT Conversations

crunch42’s picture

After spending ten or so hours wondering if I really was as dumb as a sack of hammers, I found this post and realized, oh no, it's just that Drupal can't do what I took for granted any CMS could -- make static pages and sub-pages. This module sounds great. I'm just sort of shocked it wasn't part of the version 1.0 release of Drupal.

But I guess Drupal has been developed more for blog type sites and not for brochure type sites.

* sigh *

Good luck! Hope it's done in time for me to use it instead of rolling my own CMS again.

sepeck’s picture

Thank you for your sarcasm, It is deeply appreciated and of course wrong. Drupal was NOT designed as a blog site, that came later. Drupal was designed around commmunity content and catagorization. A combination of path module and menu module and menu on the fly will accomplish this

Much of this has already been integrated into 4.7 Again, to bad we wated your time. Please move along, nothing to see here.

Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

bomarmonk’s picture

Drupal is a really cool CMS. But I have to admit that I too was frustrated and surprised by Drupal's lack of support for hierarchal content. Sure, it can be done, but it takes the installation of multiple modules and a lot of patience (I employed both).

I'm glad Jeremy is working on this. Whether this ends up in 4.7 or as the "category module," I'm sure it will make Drupal even better. After all, isn't the power of a flexible taxonomy somewhat negated if it can only be used for certain types of websites?

It sounds like a solution is on its way, and I truly appreciate all of the developers that put their energies toward making this cms even better. Bravo!

sepeck’s picture

Lately we have had several new accounts posting almost the same messages across a number of forum topics. These are by people who are obviously unwilling to be part of the solution and instead want to log in, post their complaint and then go off in a huff somewhere else. Or it's the same few individual's. In either case it's rude and unhelpful.

Yes, people were annoyed by this lack of hierarchal structure becuase they were coming into Drupal with their pre conceptions. I was able to get a working solution for myself, but others with posibly more complex needs were not. Guess what, changes have been made over time and will continue to be made based oncontructive feedback.

If someone is going to complain, then complain constructively. Jeremy did. He wrote constructve articles. Even if you can't code, people can propose a method to accomplish what you want. Open Source is about participation.

10 or so hours of research, don't make me laugh. He came into this with pre-conceived notions of what Drupal should do, made three posts that were answered, then drew conclusions that were wrong and was rude about it. We can easily afford to let him become a drain on some other projects resources.

Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

crunch42’s picture

I was annoyed by the lack of hierarchical structure because when I was researching whether Drupal would fit my needs I took a look at the Is Drupal Right For You section in the case studies and it stated that Drupal is a good choice for corporate sites. Not seeing anything to the contrary, I interpreted that to mean that it would function like "normal" ie hierarchical sites.

Having spent 10-some hours poring over the manuals and other people's posts and websites and trying to get Drupal to do what I wanted I finally came to the conclusion that this isn't really something that Drupal does. I felt mislead, and hence the sarcastic post. I apologize for that sarcasm, but I think that if a lot of people are posting complaining about Drupal's lack of simple hierarchical site support, perhaps it means something besides that we're a bunch of logheads. Perhaps it means that this is something that is widely wanted.

Yes, I will and have moved on. I actually set up the exact site I was trying to do in Drupal using WordPress instead, never having used WordPress before, in about 5 hours.

But before I go, here's my suggestion for improving Drupal: somewhere in the Is Drupal Right For Me section some wording should be added to the effect that Drupal doesn't currently support the easy creation of hierarchical websites, though it may in the future. That'll keep the cranks like me away in the first place.


sepeck’s picture

with your new site. I will say though, that creating a heirchacal web site with Drupal is perfectly posible. Perhaps something in the future will require the power of a CMS over a blog software.

Oddly enough, it's not really a lot of people, but a few who have a lot of posts. These folks have also done something about it to get the features they want by actively engaging in the community. Open Source is all about participation so you continue to get that free software.

Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

eaton’s picture

Drupal certainly does support hierarchial sites. It just takes some different-thinking and a bit of manual tinkering to get it rolling.

You're probalby used to sites based on actual server directory structures, with HTML files and subdirectories forming the hierarchy. I know I was when I started working with Drupal. Drupal -- and most other database-driven CMS systems -- store their stories, pages, and other content in a soup of data with no inherent hierarchy.

Set up a single 'Site Structure' Taxonomy vocabulary to serve as the 'directories' for your site. Then, use the 'path' module to specifiy the 'directory' that each page or story should go in.

The path aliases really are the key to this -- they allow you to map a 'traditional' URL structure onto a free-form soup of content. There are a number of modules that may be able to auto-generate this path based on taxonomy, but I've done it manually thus far.

Using certain modules like Taxonomy_theme, you can even specify different appearances for the various sections of the site by tagging content with different taxonomies.

I'm not suggesting that this is an *intuitive* way, or that the documentation shouldn't explain this specifically, but it's certainly possible to do hierarchial sites even without elaborate addon modules. I pounded my head against it for a while until I realized I was using the right tools in the wrong way.

jasonwhat’s picture

What is wrong with book module for hierarchy and brochure type sites? It seems perfect for a one man controlled hierarchy. I don't get what is so complex.

Jaza’s picture

If a simple hierarchy of pages is all you need, there's nothing wrong with the book module. On the contrary, I really admire how easily and efficiently this can be done already with the book module. I said as much in the proposal on this page.

The problems start when you want a hierarchy of static pages, and you want to use some of those static pages as categories, and assign dynamic content such as blog entries to them. At the moment, assigning a piece of content to a 'category' means assigning it to a taxonomy term, and a taxonomy term is not a node. Hence, you can't do node-like things with it, such as easily include it in a hierarchy of pages, or give it a page-like descriptive blurb.

For those who want a static hierarchy, Drupal already has the book module. For those who want their content tagged with flexible categories, Drupal already has the taxonomy module. For those who want both these things working together, Drupal will soon have the category module.

(By the way: I'm a bit behind in development at the moment, but I hope to have the first release of the category module ready in the next few weeks - thanks for all your support guys!).

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

Zach Harkey’s picture

The problems start when you want a hierarchy of static pages, and you want to use some of those static pages as categories, and assign dynamic content such as blog entries to them.

Actually, the book module is already perfectly capable of setting up a hierarchical site. The key is to create a single book page node for each of the 'pages' you want in your site, regardless of content, and use a snippet to generate the your dynamic content where you want it.

So, in this basic example, I would create a book page for each of the following pages in my hierarchy (7 pages total):

- Home
- About
- Articles
- - By topic
- - By subject
- Contact

Obviously the static pages (e.g. About and Contact) are no problem since they are book pages to begin with. But what about Articles etc?

Then I create a vocabulary e.g. 'Site' that includes a term for each of my dynamic categories (term ids[tids] in parenthesis):

- Articles (term: 10)
- - By topic (term: 11)
- - By subject (term: 12)

I want my "By topic" page to be a list of the 10 most recent nodes from the "By topic" category, and not a static page. Same goes for "By subject." The reason I made them book pages instead of using the dynamic taxonomy pages (e.g. and, is because I want them to show up in my book hierarchy.

In the body of my "By topic" page I paste the following snippet of PHP:

$term_id = 11; 
$list_length = 10;
$sql = "SELECT * FROM node INNER JOIN term_node ON node.nid = term_node.nid WHERE term_node.tid = $taxo_id ORDER BY node.created DESC LIMIT $list_length";
$result = db_query($sql);
while ($anode = db_fetch_object($result)) {
$output .= theme('node', $anode, $teaser = TRUE, $page = FALSE);
print $output;

As a result, this once static book page now displays the 10 most recent nodes from the 'By topic' category (term id: 11). If I wanted, I could also include a little custom HTML before my snippet to act as an intro.

A far as I can tell, this method addresses all of these previously stated caveats with using the book module to create a site hierarchy:

If you ever decide you want to post dynamic articles in a static book hierarchy, you can't, but oh well, you should have thought about that earlier on.


You won't be able to put one article in more than one section, but oh well, at least your menu blocks and your breadcrumbs will all look good.


Those terms won't be treated as part of the hierarchy, but oh well, you can't have everything.


Really, the only downside is that that PHP code looks scary to the average user. The upside is that you aren't limited to a basic category list. You can mix and match PHP page snippets to make any kind of page you want.

Now 'all we need' is a nice little AJAX form that can make the process pretty and user friendly...

harkey design

: z

iferrer’s picture

What would be the breadcrumb when viewing a node listed in a book page?
I think it would be wrong beacuse it will be taxonomy based, and breadcrumb links will point to dynamic term pages, not to parent book pages. Is that right?

restyler’s picture

Ocasionally found this topic. Great. Respect flyout 2 Jeremy, we need this module. I've read your 'making taxonomy work my way' yesterday, it is wonderful.

Currently I'm trying to create Drupal package that will be easy to use for dummies, and I've encountered the problem.

I think coding such a mod will take much time, and there will be not two ways to categorize content. There will be three.

Surely categories.module should be created in 2000, for Drupal 1.0, instead of taxonomy - and now may be we would be talking "How can I have multiple parents for my node?" :)

I'm a bit disappointed with Drupal now - and it's after four months of euphoria, during which I was sure that Drupal can easily drive-all-sites-in-the-world-in-the-best-way. I've spended much time exploring Drupal, and now I'm tired a bit, and I don't want! to go away, exploring Xaraya, or Xoops, or another super-mega-cms with clear and simple categories. :) I like Drupal, and I want to work with Drupal developing my sites.

Jeremy, you created this topic 3 months ago - and still no category.module in projects :( You found another good solution?
we need many-many hours to create the module ...

Every coder searches the easy way :)

That's why my idea is to patch taxonomy.module so we can create a "link" term-to-node, and the node linked to term will serve as index.html in static HTML site (now it can be partly done by term description, but we can't use search for that, and many other disadvantages, I don't want to repeat it again, it is clear for everybody here)

- and with the solution where we can define main vocabularies that will serve as categories for breadcrumbs (like you way with vocabulary weight, but may be a bit more flexible) we'll get the categories.

What do you think about this?

RussianWebStudio: improving the web

Neil Adair’s picture

+1 for this proposal
I'd decided to avoid book due to its' rigid hierarchy. The site we need to build will grow to over a 1000 pages and the structure has to expand and adapt as it grows. I concluded using taxonomy and context and incorporating your breadcrumbs patches (when a stable .8.2 crm/mm/og CS is available) would do the job but this proposal is much more straightforward. Minimizing the number of vocabularies and terms will be important to avoid overwhelming users. We will be using organic groups and I would like each group to have a dedicated vocabulary they can use to organize content within the group. Our groups are for policy development and they have proposals, resolutions, backgrounders etc. as well as forums as input and policy papers as output. Different groups will want to structure content in diverse ways.
Sometimes I don't know whether to laugh or cry at all the available permutations in Drupal ;)


turtle182’s picture

I share the frustrations with Drupal on this need for a more complete heirarchical structure. I think your proposal is excellent! I look forward to seeing it become a reality.

tangent’s picture

Drupal's greatest weakness at the moment, for my needs, is lack of node/user level access control.

As I'm sure someone will be quick to point out, the taxonomy_access.module provides this functionality at the term level but the menu module ignores taxonomy access when displaying menu items rendering the addon module irrelevant.

My clients invariably require some content to be restricted to certain users. My current client needs to restrict sets of content to single users. To accomplish this he would have to do the following for every user.

1. Create a new role for that single user (not really viable)
2. Create a new taxonomony term for that user's content
3. Assign access for the new term to the new role

All this will provide the necessary access control, but still doesn't provide for a hierarchical menu. Because both the book module and the menu module do not use taxonomy but are independant it is currently impossible to provide a dynamic menu for access controlled content (as far as I am aware).

This is partially off-topic but demonstrates that there is more need to consolidate the taxonomy and structure of content than just for menu purposes. Actually, it may be that using taxonomy for access control in the example above is not the best solution but it is a workable solution for many other cases.

The fact that there are multiple ways (e.g., book module, menu, menu_otf, taxonomy_context) to provide a menu for structured content is, perhaps, an advantage for the power user but is extremely confusing for new users. Structured, access controlled content needs to be given significantly more focus if Drupal wants to play in the CMS arena and not be considered just another blog software.

chadcf’s picture

There is a node access module here:

that does what you want. I assume it's alpha/beta quality, but it's working for me well enough. It adds a grant tab to each node (if the user has permission to use this module) that allows users to specify which roles or individuual users may view/edit/delete that node.

tangent’s picture

Based on the modification date and that it isn't working for me I don't think this module works with Drupal 4.6.x

I was able to make a node completely irretrievably inaccessible to the admin account (should this even be possible?) along with all other accounts but was unable to do anything useful with it.

The UI is not at all clear.

What is the terms tab (in the admin/settings) for? Does this duplicate taxonomy_access functionality? If so, what does the single checkbox allow for the role? 'View all nodes' associated with that term?

How do you grant permissions? Checking (or unchecking for that matter) every single box on the node grant page leaves the node inaccessible to every user from admin to guest.

If you could post or email me some tips for using this module (since it isn't a contributed module) I would be much appreciative.

Oh, sorry for highjacking the thread. It was unintentional.

chadcf’s picture

I basically just use the grants tab. You set the defaults in the settings, and then can change them on the grants tab on each node.

The terms tab basically disables roles from accessing content tagged with that term, but it's rather flawed. I would not recommend using it, just dont' change any settings there and it will not be used. The problem with it is that if a node has no taxonomy assigned to it, if that part is enabled then no one, not even the admin, will be able to do anything with the content.

To reset your permissions while playing, delete everything from the node_access table and insert a row with the fields 0, 0, all, 1, 0, 0 and that will get you back to the defaul drupal access permissions.

styro’s picture

If you use node_privacy_by_role you would skip some of those steps. It is node/role access control rather than node/term/role.

Both have their place depending on what you want to achieve.

You would still need to create user specific roles though. But per user rather than per role permissions is a major PITA 99 times out of 100, so I don't see that as an issue for the general case.

Even then, creating a role per user still allows you to change a user role and what they can access in one action, rather than resetting permission on all the nodes or terms etc.


tangent’s picture

This module does almost everything I need.

Book pages honor the node permissions and do not appear in the block if the user does not have permission to see them. However, the menu module still doesn't honor node permissions of static pages. I may try to figure out how book.module is working and patch menu.module (if that is where the problem is).

brandondrury’s picture

I'm extremely new to using Drupal. I've put about 30 hours of work into Drupal over the past 2 two days and 90% of my frustrations have went into the problems that this plugin should fix. The other 80% is just my ignorance.

I would imagine that every single site that I've ever built and ever will build under the current internet system will use a combination of taxonomy and the book system.

This sounds brilliant to me. When can we expect a release?

Brandon Drury

Jaza’s picture

Due to numerous other commitments, development of the category module has been stalled for some time. However, barely a day goes by that it's not on my mind. Expect a release within the next month or two (for Drupal 4.6 and 4.7).

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

eaton’s picture

I have to admit that I'm still halfway between 'concerned' and 'curious' regarding this module. If I understand correctly, you're planning on making a 'category' module that provides hierarchial organization of pages, ala book.module, in addition to tagging of pages (ala taxonomy).

I've read through many of the posts in this thread, and I'm still not sure whether you're really talking about merging the two modules, or creating a single new module the puts a user-friendly interface on top of the shared functionality.

It seems (to me at least) that you're looking to solve a couple of technical problems: display of 'information pages' for taxonomies, easy sorting of items into hierarchies without manually adding new taxonomy terms (ala book), and the creation of navigation structures from the resulting hierarchies.

I tend towards a slightly different solution. Rather than trying to merge Taxonomy and book (a change very unlikely to make it into HEAD, I think), perhaps what you need is a 'Category' module that works as a front end to the existing drupal infrastructures.

Interfacing with taxonomy.module would give it a way to store its hierarchy, interfacing with menu.module would give it a way to construct navigation menus and breadcrumbs dynamically. I'll admit that I would rather see book.module die and be replaced by a generic 'outlining' module, without the need for a dedicated 'book' node type. And I like your idea of providing a module that univies disparate navigation structures. I'm worried, though, that merging two existing modules rather than providing a front-end to useful Drupal APIs will only make the problem worse in the long run.

Have I misunderstood the goals of your project? I'd like to get involved and help, if I think it is going in a direction that would be useful.

Jeff Eaton | Click Here To Find Out Why Drupal "Sucks"

Zach Harkey’s picture

I'll admit that I would rather see book.module die and be replaced by a generic 'outlining' module, without the need for a dedicated 'book' node type


harkey design

: z

FabriceV’s picture

I agree.

I thing most of the learning problems of beginers emerge from the overlap between taxonomy and menu (which seems logic, but interface creates confusion).

Finaly I would like to build a site that also do this kind of separation and provide both access, hierarchical and thematic access.

jeff h’s picture

perhaps what you need is a 'Category' module that works as a front end to the existing drupal infrastructures.

As a developer, Drupal appeals not only for it's immense flexibility and power, but its ability to allow clients to "build their own site" based on a framework I have created within Drupal. These clients will not understand books and taxonomy vocabularies.

That's not to deny the usefulness of these concepts, but it would be brilliant if there were a simple interface whereby a "semi-literate" user could go in and extend and redefine their site structure, without needing to write books or become taxonomists :)

FabriceV’s picture

Dear Mr.

One more thing concerning your proposal.

Creating a hierarchical menu for each submitting post gives an over fragmented book (as Drupal ones) that limit accessibility of information. Futhermore, a long post is problematic to edit directly using drupal form (I supposed you are well organised to write your own long proposal).

Thus, some CMS and the wikis use multiple posts to compose a page (as forum or comment) with only one menu address.

This could be add to your proposal. Currently this is missing


Jaza’s picture

Your idea of 'using multiple posts to compose a page' sounds interesting and useful. But it also sounds complex, and I really can't see how it is relevant to the subject of this thread. I don't consider a problem such as this to be within the scope of the category module. As with the 'multiple pages for a node' functionality, I think that this would best be implemented as its own module.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

FabriceV’s picture

You are probably right, thinking of that because of book hierarchy and related problems. The latter question could be how the different modules could interact so that the whole works properly.

Jaza’s picture

A beta version of the category module has been released, and is now available on! A new thread has been started for discussion on the new code, status updates, etc:

Please do not post any more comments to this thread, but instead, post your comments in this new one (or in a new forum topic of your own). Thanks very much to everyone who gave their feedback on this page: I've tried to cater to as many of your requests as I could. Don't forget, you've all contributed an important part to the development of this module!

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh