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).
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)
--News and articles
----Work for us
John posts a new topic on the Drupal.org 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.
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)
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