Shared containers - categories and containers that exist in multiple hierarchies

The basic idea behind this proposal is that a set of categories in a containeri often need to be 'shared' between multiple sections of the site. The easiest way to explain this is with an example. Say you have a container called topics, that has a whole bunch of categories that are used to categorise posts by topic - e.g:

Topics (*)
-- Computers
-- Fishing
-- Kayaking
-- Movies
-- Travel

And say that you post content to two separate sections of your site - the news section, and the blog section. However, you'd like to use the same topics to categorise your news posts and your blog posts. This is your only option for achieving what you want at present:

Articles
-- News
-- Blog
-- Topics (*)
---- [topic categories here]

But you don't want it to be like this. With this structure, the topics container only lets you browse by categoryi with the news and blog posts all mixed together. What you really would like is to be able to browse only the news posts by category, and only the blog posts by category. You'd like your unified tree of categories to be shown in two places, and to only show posts of one type in each place. Example:

Articles
-- News
---- Topics (*)
------ [topic categories - only news posts shown]
-- Blog
---- Topics
------ [topic categories - only blog posts shown]

At present, I only have a hazy idea of how this would work. It would be quite complicated to implement - it would probably require a separate contrib module, perhaps called category_share. Shared categories and containers would initially be created just like any other categories and containers - that is, as node types, with a single page from which they're accessed. But then category_share would provide a special callback path for accessing a category within the context of another category - in effect, filtering one category by another. For example:

Movies: node 6
News: node 2
Shared path: category/share/6/2

This path would simulate the node page for movies, but would filter its node listing by the news category. The page would look very similar to the 'real' movies page (which would be at node/6), except that there would be no 'edit' ability, no 'comment' ability (and no comments displayed), and no 'add child category / container' links. It would just be the body of the node, and a specially filtered category listing (this can easily be achieved, with a custom call to node_view()). Adding new categories to this structure would be managed centrally through the 'real' page, or through the admin interface.

The tricky bit, of course, will be integrating such a system with category_menu and with category_display. This will be difficult, but it will be possible. If it's done properly, it will be able to give the impression (to end users) that shared category pages are no different than 'real' category pages - especially if they're given URL aliases. Breadcrumbs, table of contents links, and navigation links will all work together to give this impression.

This is something that a lot of users have asked for. And when it's available, it will seriously open up some new doors for the category module. But developing it won't be easy, and I for one am not planning to do it just yet.

Maybe we shoul sponsor you

Maybe we shoul sponsor you to make this a priority Jaza? :)

I added views to my containers to do this

Hey,

I created a list of general topics under the TOPICS containeri,which is directly under the root. The I created node types and their specific vocabs, let's say news and blog.

I set up the news and blog containers so that they have topics as distant parentiis, but their node type as container...

So when I create a news, it is tagged news, and then I can choose the topic, like in your example. It is true that it gives all node types on the same topics page... which is.. not so bad... but still...

Then I created a view where I simply add an exposed filter to select the node type AND also tat order the nodes by vocab, it orders the, by their container vocab (node type) cooool...

In effect, the user can click on the topic, and then arrive on the page with ALL the posts for that topic, ordered by node type. Then, since the filter is exposed he can simply choose to filter for any kind of node type he wants, and ... voila..

A user wants news? he has news, wants blogs? he has blogs!

In the same manner, I created views for the index pages of each node type, blog and news...

On these pages, the users sees all news OR blogs but can filter the page by topic, which is selectable on a dropdown, thanks to the view.

So he can browse by node type > topic OR by topic > node type.

This is how I created my own little shared categories, what do you think?

patchak

Jaza, I have also sometimes

Jaza, I have also sometimes wondered if a tighter integration of views (may be at the categoryi or containeri node form level) into the category module is the answer to this vexed issue. Either this, or Styro's excellent (except for the horrible taxonomy/term/x,y kind of urls) taxonomy filter module that lets the terms of one vocab be filtered by that of another.

This was behind my comment at http://drupal.org/node/65072 that the default taxonomy module led to fewer vocabs that could be reused for all content types as opposed to the larger vocab sets seemingly required to leverage the full power of category module.

IMHO, the inability of editing/commenting on shared categories and containers would be very limiting especially when one can build a view without those limitations.

It also seems that there are two aspects to this issue- the admin side of setting up the associations, menu blocks, menu items etc and the user side. One approach to take might be NOT to give the users a choice of filtering and have the admin set up the entire interface.

Of course, my technical understanding on this topic is rather limited, so be indulgent if I am off the mark;-)