Now how about some real categories?
You've come this far - now, there's only one set of categories and containeris left to create. These ones are arguably the most important, as they alone are the ones that actually do the categorising of content. I say arguably, because the ones we've created so far exist purely for structure; and some people consider structure more important than categorisation, and vice versa. However, with the categoryi module, it doesn't matter whether you've got a structure fetish, or a categorisation fetish, or both: the module takes care of both these things. So you can have your cake and eat it, too.
We'll start with the topics container for news items. Go to the page for the news category, and click the add child container link. Enter topics as the title of your new container. Go down to the container information box, and in the help text field, enter something like "Select one or more topics for this news item". In the admin title field, enter topics (news), so that we can differentiate this container from the one for blog topics, which we are going to create further on. Under types, tick the story check box. Tick the multiple select check box.
Go down to the category display settings box. Tick the display TOC within this container check box, as well as the show links to categories on assigned nodeis, and show message if no posts check boxes. If you wish, you may also tick the show assigned node count in TOC check box - this will show the number of nodes assigned to each category in the TOC. Then, in the category menu items box, set the menu items within this container field to enabled, and leave menu items for assigned nodes set to disabled.
You may recall that in the two sections containers that we created, we set the menu items for assigned nodes option to enabled (but disable each item). However, in this container, we're setting it to disabled. Since every news item that we create will be in a category from both these containers (or, at the least, from the sections container), we have set it up in such a way that news items will always be placed under the generic news category, rather than under the various topic categories to which we are assigned.
This is a common and useful technique, and there is good reason to set it up in this way. You see, a menu item can only be placed in one spot in the site's tree. Furthermore, a breadcrumb can only reflect one parenti of a particular page. So what happens to content that gets assigned to more than one category? For example, news items may be tagged with more than one category from the topics container. It is ugly and doesn't make sense to place it under one of these topics, and not under any of the others. A much cleaner solution is to simply place it under the news category, where it is guaranteed to only ever have one parent, and to have a breadcrumb trail that can be properly parsed.
Now, submit the topics container, and go to the page for your new container. Click the add child category link, and add a few categories that you might use to tag news items with (e.g. 'sport', 'entertainment', 'lifestyle'). If you go back to the topics page, you should see all these new categories listed there. You may also notice that when you add a new category, you're redirected straight back to the 'add category' page, rather than being taken to the node page for the new category. This is to make it more convenient to add many categories at once, and it's a feature borrowed from the taxonomy module and its 'add term' page.
Repeat this process for the child containers of blog, by going to the blog page, and clicking the add child container link there. Add the topics and moods containers, with the same settings that you used for the topics container in news (except that the admin title should be set to topics (blog) for the topics container, and should be blank for the moods container; and that you might want to tick the free tagging check box for moods, as the categories in this container are likely to be added on-the-fly). Once again, fill these two new containers with some dummy categories, by clicking the add child category link on the page for each container.
Mission (almost) accomplished: your category structure is in place! Now, there's just one step left before we can adjourn and have some tea.
Fixed and fixed
Thanks for pointing out that wording error: I have now changed it to say "news categoryi" (which is what I meant), instead of "news containeri".
The issue of the content not appearing on the "articles" page was actually caused by a serious bug, which was introduced as a result of a recent patch. The bug meant that node-to-category assignments were not getting saved at all, when the taxonomy wrapperi was enabled. A fix for this bug has now been committed to HEAD. Please download the latest version of category (and re-install the taxonomy wrapper), and try again.
Duplicate names
Is it necessary that both hidden "sections" have the same name? It seemed that you did that intentionally. If so why?
By the way - the fix above worked for me thanks again.
Admin titles
The hidden "sections" containeris have the same name, because they both perform the same function. In the latest version of categoryi, there is now a field called "admin title", which allows containers such as this to be differentiated in administrative interfaces. This tutorial has now been updated to account for the "admin title" field.
reuse topics
what if you want the same topics for both news and blogs? is there a way to reuse these? maybe categoryi_menu could create seperate menu items for them like category/topics+news and category/topics+blogs
A matter of personal preference
I suppose you mean that only one containeri called topics should be set up that could be used by both news and blogs. I raised this issue in more detail at http://drupal.org/node/65072
The taxonomy approach results in fewer vocabs and you can then use query operators for the kind of union and intersection of nodes you are talking about. You can do the same with categoryi module also, as it has the same query operators.
However, the Views module that came along some months ago has taken queries to such a whole new level that the default taxonomy operators seem weak in comparison.
I personally prefer (at least for my current sites) to use the category module to predefine the union and intersection pages as categories (within containers) that can be tagged by the node. Sure, this results in more vocabs than taxonomy, but I love the auto generated menus, menu items, breadcrumbs and ToC of category module. I might even throw in a category_view to override category module's default listing styles.
So, ultimately, it all boils down to personal preference. But, it seems to me that the category module approach combined with category_views is superior to simple query operators, especially if you are dealing with hierarchical structures and want to avoid the hassle of manually generated menus and menu items. That's really hard.
so, can i have same cats in multiple cont?
so, not sure this question got answered.
I don't think it can be done and your structure diagram doesnt show this either.
I am using the auto convert to categoryi feature - I have a user create a node Genre which i would like to tag to an artist - this all worked well - but now client wants to have a Primary (only one allowed) and Secondary (multiple allowed) Genre to apply to Artists.
I thought this would be easy - i just do the same as i was doing by define another containeri and under my Genre type settings i tell it to be able to go in both containers - but no luck. And if i edit the Category that gets created it only shows ability to exist in one container.
So, sadly, the only way i can think of making this happen is to create another content type and do nodeapi code to duplicate/delete the Secondary Genre type when i create/delete the Primary.
Please let me know if there is an easier way???
Turorial Out of Date?
First, thanks for this very impressive contribution. I will almost certainly be using it.
I believe the tutorial is a bit out of date. So far as I can tell, it does not mention the need to tick the Show node listings checkbox in the Category display settings box for the Articles containeri. I'm guessing the checkbox is newer than the tutorial. Without that checkbox, associated nodes will not be listed on the articles page.
Things to check when creating topic container
I don't know if the problem I had was a result of a bug in the code, but I noticed when I followed the instructions to create the topic containeris, then entered child categories under them, the child categories where orphaned (i.e., did not appear under the first level of categories, "news" and "blog" in this example).
This is because when I submit my topic container initially, it does not have the correct "Parent" (found in Container Information section). I set this to the correct categoryi (not container), which in this case is "news", and it works.
But not quite, because when I enter the category children for topics, I get a similar problem. I need to go back to Category Information section and make sure "Container" and "Parent" contain the correct container (in this case, the "topics" father of this category).
With the above two re-edits, the category module works as defined in the tutorial. I don't know whether this was a bug or what, but if anyone else has a similar problem, this might be the solution.
-ron
warning while creating categories
I am running trough this tutorial an getting warning while fallowing instruction on this page. I am creating some categories under the “topics†containeri, as suggested. While adding first categoryi “sportâ€, the error apears:
user warning: Duplicate entry '7-6' for key 1 query: INSERT INTO category_hierarchyi (cid, parenti) VALUES (7, 6) in /homepages/19/d167162193/htdocs/localspit/includes/database.mysql.inc on line 120.
Is this a problem, the category seems to be created, this is on 4.7.2
many thanks
Darko Kantic
How many containers do I need?
This is such a great tutorial and such an amazing module - thank you for not only creating such a useful tool, but also describing how best to use it.
I'm still a little unclear, though, on when I need containeris and when I can just use a categoryi. Can I use a category as a parenti to other categories? Or is the existence of children a tip-off that I need a container?
I'm also missing the point of the Topics container here (although, if it's true that anything with children should be a container, it makes more sense. I think.) Why can't we just put the Sports, Entertainment, and Lifestyle categories directly under Blog?
In my own site, I've created three high-level sections at the level of Blog Section and News Section here. So my structure looks like this:
Articles
Sections (Terms) [C]
Terms [C]
Categories [C]
Styles [C]
Bungalow
Eastlake
Queen Anne
Elements [C]
Roof
Catslide
Hip
Mansard
Window
Parts
Muntin
Pane
Rail
Stile
Types
Sash
Venetian
Sections (Places) [C]
Places [C]
Sections (People) [C]
People [C]Only the Styles part is built; I'll be adding Elements soon ( ... perhaps shortly after you reply [grin]).
So, first, do I need the Categories container (which corresponds to the Topics container in the tutorial)? Or can I just stick Style right under Terms?
And second, in Elements, should I make Roof and Window and Parts and Types containers, or can they be categories?
What are the clear differences between containers and categories? (I'm sure it's my experience with Taxonomy module that's confusing me. Sorry!)
Many, many thanks!
Kristi
Containers
So, first, do I need the Categories containeri (which corresponds to the Topics container in the tutorial)? Or can I just stick Style right under Terms?
Looks to me like you don't need the 'categories' container - the stuff beneath it can probably be moved straight under 'terms'.
And second, in Elements, should I make Roof and Window and Parts and Types containers, or can they be categories?
For the categories beneath 'elements', whether or not you should make some of them containers depends on whether you want everything to be in one select list (when assigning categories), or whether you want the sub-categories shown in separate lists (linked via distant parentiis).
What are the clear differences between containers and categories? (I'm sure it's my experience with Taxonomy module that's confusing me. Sorry!)
There are three main reasons to use a container instead of a categoryi:
- Separate category selection lists - when assigning categories, if you want the categories shown in separate select lists (or textfields, when using free tagging), then use separate containers.
- Hidden containers - if you need a hidden node in your hierarchyi, use a hidden containeri.
- Per-container settings
- if you require different settings for different parts of your site heirarchy (e.g. nav links, TOC, menu items), then use separate containers.
Hope that clarifies things.
Jeremy Epstein - GreenAsh
Thanks!
Thank you so much - that's MOST helpful.
The image I'm coming up with is this: I'm imagining all the content at my site in one huge tree, and I'm picturing sort of snipping off each branch where I want a separate select list - those are the places where I need containeris. (Plus, of course, anyplace I need hidden containeris or the other per-container settings you mention.)
I appreciate the quick and thorough reply!
Thanks,
Kristi
help wrapping my head around this
I'm working on a "law school cms" to help me organize myself through law school.
I need to figure out the best way to make a comfortable workflow while capturing all the various bits of metadata I'll need to (eventually) generate auto-updated outlines based on the metadata.
So, below is basically the structure I *think* I need...
Right now I'm stuck on getting e.g. Criminal Law to act as a "categoryi" for Courses (is that possible?).
My goal is that when I go to create content, I'd first choose a course, and then using the fancy ajax stuff, be presented with a list of document types to choose from, and enter some tags and headings (free entry, probably). Is this possible? What am I missing?
Courses [C]
-Criminal Law [C]
--Documents [C (hidden)]
---Briefs
---Class Notes
---Reading Notes
--Topics [C]
---Chapter Heading
----Chapter Sub-heading
---Tags
-Torts [C]
--Documents [C (hidden)]
---Briefs
---Class Notes
---Reading Notes
--Topics [C]
---Chapter Heading
----Chapter Sub
---Tags
.
.
.Bug: Node Type Unchecks Itself When Categories Are Re-Weighted
In my structure, I have three categories at the "topics" and "moods" level of the hierarchyi. When I adjust the weightis of these using the categoryi bulk edit, the containeri information node type checkbox (the node type I'm using is a custom CCK node) gets unchecked for no reason at all.
As a result, the category select boxes no longer show up in my node edit pages, and I have to go back and update the categories individually, thus nullifying the whole time-saving aspect of category bulk editing.
How to stop getting nodes converted into categories?
First off, thank you so much for such a huge effort in developing a wonderful tool like Category. I'm sorry to bother you people with this, but I truly don't know where else look for it, in spite I checked out already almost everything online. My question is: How do you stop nodes to become categories?
I've already disabled in Settings >> Category transform settings each and every node type but I still get nodes asigned to a categoryi, converted themselves into a category. What am I missing?
Any comment will be highly appreciated. Can offer an es.po (under development already) in return.
"when you add a new
"when you add a new categoryi, you're redirected straight back to the 'add category' page, rather than being taken to the node page for the new category."
I don't like this feature. I would like the user to return to the saved node, as normal. How could I make this happen?
Ambiguity in the documentation
Above your write "Go to the page for the news containeri". The news container? "News" is a categoryi. Do you mean news category? or do you mean the parenti "sections" container of the news category. I tried it both ways. My content is not bubbling up to the "Articles" node.
Any suggestions?