Posted on October 3, 2007 // Short URL

Taxonomy Taxonomy Taxonomy!

Robert Douglass, Jeff Eaton, Angie Byron, and Jeff Robbins discuss the ins and outs and ups and downs of Drupal's taxonomy system.

Podcast:

Drupalize.Me Podcast

Tags:

taxonomy, podcast, drupal core, deprecated, categories

Comments

Chad

Great timing for this

Great timing for this podcast as I've been pondering whether to use CCK Select List or Drupals Taxonomy for my project. (Thanks Angie for bringing this up!) Advantages of CCK 1.) Easier to Theme ( on the node submit form and in node.tpl ) 2.) Ability to use CCK Field permissions module to define who may tag the node with the CCK Select list without having to get waist deep in code. My only obstacle now is trying to build the " Nested List Summary" available in taxonomy but instead using the CCK Fields. Example Birds (33) Dogs (32) etc. etc. I know you can do this with views, but the queries are not desirable. Or better yet, any idea how to display the *count in the Views exposed filter? eg. When selecting from the exposed filter, it would tell you how many nodes have that CCK field ( or taxonomy term).

Reply

Rick Hood

Multiple Hierarchy

Glad to hear that multiple hierarchy is not recommended. I was wondering about whether I should ever use that or not.

Also, is Pathauto module needed to make friendly URLs for URLs like this 'taxonomy/term/1'. Is there another way? ...not that another way is needed, as pathauto is awesome.

Reply

jeff

Pathauto is Great!

...and it's under consideration for inclusion in core for Drupal 7. It works especially well for the situation that you're describing.

Keep in mind that having lots (and I mean LOTS) of path aliases on a site can be a performance consideration, so only use it where you need it (like maybe not for freetagging terms or forum posts). But using PathAuto is no less efficient than creating paths manually using path.module.

I have it installed on pretty much every site I work on.

Reply

ngaur

Is this right?

I'd expect the time it takes to do a look up on a single indexed field to go as log(n) of the size of the table. Ie where you say LOTS, presumably that means a number with LOTS of digits? I wouldn't have thought a few million aliases would present a problem. Then again, maybe there's something silly in how this has been implemented. I haven't gone through the code.

Reply

rpmute

Excellent.

excellent podcast. any take on the 'taxonomy super select ultra' module?

Reply

jeff

Looks cool

I haven't used it, but it sure looks cool. I'm going to put that on my list of modules to try out...

Reply

Anders

taxonomy_term_path

I didn't know about taxonomy_term_path, handy! (found in Taxonomy Redirect and Image module mentioned by Jeff Eaton): http://api.drupal.org/api/function/taxonomy_term_path. What's the difference between that function and a regular hook function, which usually is much better documented, people write "Implementation of hook_blablabla" etc?

Reply

terry

sticky taxonomy nodes

hi,

thanks for another great podcast. I have a site with views filtered by multiple taxonomy terms (teaser mode). I'd like to add one sticky node to describe each taxonomy term section but the stickyness does not work in the view. The sticky nodes do work if I go to the taxonomy term URL.

Any suggestions? I think I'm missing something obvious here.

Drupal 5.2

Reply

jeff

Obvious?

Are you sorting by stickiness as your first sort item?

The default taxonomy.module sort is first by stickiness (descending) and second by creation date (descending).

Another tip for Views is: always remember to make sure that "node:published is TRUE" is one of your filters, otherwise unpublished nodes will appear in your Views. While you're at it, you probably want to make sure that moderated nodes are filtered out too (node:moterated is FALSE).

Reply

Anonymous

Thanks for the response. I

Thanks for the response. I tried to sort by stickiness but that sent all the sticky nodes to the top of the view instead of to the top of the term section.

Thanks for the published tip. I'll use that from now on.

Reply

terry

Yes, I tried to sort by

Yes, I tried to sort by stickiness but that sent three sticky nodes to the top of the view instead of the top of each section. When I remove the stickiness sort, the sticky nodes return to their place in the view by creation date (instead of the top of the term section).

The rest of the view is filtered by taxonomy term with one term selected and three sub-terms beneath the selected term.

Thanks for the node-published tip.

Reply

Rich

CCK and default taxonomy terms

Jeff Robins, discussed taxonomy defaults modules (1:23:10 into the podcast) as a way to assign a default taxonomy term to a node. What I want to be able to do for my users is have them create a node (of a specific type) and have a taxonomy term assigned to that node type without them having a means of changing it or even seeing the selection. I want to use the power of taxonomy along with fine grained access control to the content types (different groups/users will have permissions only to create certain node types). I can then use other modules (path auto, views, and the auto breadcrumbs module mentioned in the top 40 podcast).

I am presently a category module user and use the fact that my custom nodes can be terms and I am looking for a way to replace that behavior and see this as perhaps a way for me to reduce my dependency on the category module (this podcast warns against using). I did not realize that it was a "heavy weight" module, but my site is not that large (< 1000 nodes).

Can anyone comment on hiding the default selected taxonomy term that the taxonomy defaults module provides?

Thanks for the great podcast(s)!

Rich

Reply

jeff

Form api...

The form api makes it pretty easy to change the taxonomy select field from a displayed form item into an (internal) "value" of the form. This value can then be changed during the 'validate' stage of the form submission. This way you could, for instance, assign all of the nodes to a taxonomy term representing the first letter of their title ('A', 'B', 'C', etc.), without having to make the user select from the alphabet for every entry they create.

Of course, the hard part of this scenario is learning the form api! ;-) But this is a one-time learning curve for Drupal developers.

Just before I hit submit, I'm re-reading your post and it occurs to me that you might be talking about hiding the term as it appears on the node. This can be handled at the theme layer, by only outputting the terms from vocabularies you want to appear. There are some documentation pages about this on drupal.org. Another option could be the taxonomy hide module, which I used on a project several years ago, but haven't visited since.

Reply

Rich

Thanks

Thanks Jeff. The former is what I meant. I think what I really want is to hide the selection of the taxonomy term from users without proper authorization during content creation, and allow administrators to have access. I seem to recall a module that can apply access control to fields within CCK nodes.

Rich

Reply

Peter

Not sure code is needed for this...

I may be missing something, but if the goal is to have a term from a vocabulary automatically assigned to certain content types without the user every seeing the choice then I believe the taxonomy default module is all that is needed.

This is in fact what I'm doing on one of my sites right now.

Basically you create a vocabulary with terms, but do not assign it to the content type in question. You then go to the "default terms" tab on the Categories admin page (/admin/content/taxonomy/taxonomy_defaults). Next to each content type you will see listings for each of your vocabularies. If a vocabulary is disabled for this content type you will still see it, but it will say "not active". But you can _still_ check it off for taxonomy default and select a term from the vocabulary. End result is that the term is automatically added to future postings of this content type without the end user ever seeing the choice on the node entry screen.

Now of course since the term is actually assigned to the node the term will appear along with the node teasers, etc. so theming would be required if you don't want certain terms to appear (no different than normal).

The only thing this doesn't address is making it so the administrator can manually edit these "hidden" terms to over-ride the defaults. Of course you can always temporarily add the vocab to the content type, make the change to an existing item, then remove the vocab from the content type again. That would be a bit clunky though. This is not an issue for me as the only time I use taxonomy defaults in this way is for terms that I would always want explicitly associated with a certain content type.

Here is an example. I have 3 content types that are all essentially "news story" content types. One is very structured to make is very easy for someone with no HTML background to use and displays in a very specific way. The second is a "free form" story option (pretty much the default story content type). This one allows for the less frequent case where we want the power of a freeform node type to add elements that are not typical on the site (like larger pictures, etc.). The third is a specialized "message from" story type with appropriate specific options. Since all three are basically news stories I have a vocabulary called "Content Type" with one of the vocab terms being "News Story". I use taxonomy defaults so this term is automatically assigned to these 3 "news story like" content types. So anyone who uses any of these three content types automatically has their posting tagged as a News Story which makes it very easy to have News Story section on the site since it is a simple taxonomy link as well as being easy to theme. Also, if I come up with other news story formats I can simple add another content type in the same fashion.

Please correct if I'm missing something or misunderstood the problem.

- Peter

Reply

Paco

Enlightening

Bringing the light to one of the most obscure parts of Drupal.
As humans we tend to classify everything so its in web sites.

Thank you!

Reply

Anonymous

"Error opening file" for the

"Error opening file" for the audio podcast.

/me prefer podcast video too. I'm a foreigner (or you are ? :D)
Hope I understand some words in the 93:59 minutes when they'll come back :>

Reply

John A

nice

Glad to hear you guys struggle a bit with taxonomy use issues. I have a job posting site that uses taxonomy, it works very well.

Thanks, keep going!

Reply

Anonymous

Poor Angie

She spoke 2wice. But...this was a very useful resource :)
thx

Reply

Rob Lang

Multiple Parents

Great 'cast. A really good listen.

A hierarchy is a single-parent per child relationship (by definition of a tree). If you move to a system of multiple parents, you're actually building what's sometime called a "directed semantic network". This is where words are linked together be meaning, this is much like related terms. It's much better to have your taxonomy in a single parent relationship and then have the tags gain their meaning by the documents that they are attached to. Two tags that keep appearing together on similar documents will then be related to each other.

Great work!

Reply

Jeremy Epstein

About Category module

Wow — you guys sure slammed the category module pretty hard in this podcast! And it's not hard to see why: indeed, many of the criticisms that you made about the category module are 100% valid. You're right:

  • Thus far, it has failed to scale for any kind of large-scale site, due both to it supporting too many disparate things at once (e.g. terms, books, menus, nodes), and to its reliance on parts of Drupal core (i.e. the menu system) that, in turn, also scale poorly.
  • It tries to bring together many different things that weren't designed to be brought together, and as such, it is doomed to always be fighting an uphill battle, and it is doomed to never actually "working properly", the way that a truly integrated system can work properly.

As the module's author and biggest fan, it is (of course) my duty to stand in the line of fire, and to defend it as best I can. I don't want to try and argue all the benefits of the category module right here, as I've already done that too many times, in too many other places. But what I will do here, is just mention two important new changes in the upcoming Drupal 6, that are going to change the future of the category module radically:

  • The new menu system. D6 will be the first version of Drupal that can actually scale to support a site with 5,000+ menu items. This is because D6's new menu system will not maintain a cached array of the site's entire menu tree, and it will not load the entire menu tree into memory on every page request. This means that contrib modules that take the approach of category_menu — i.e. modules that generate potentially thousands of menu items, for (e.g.) every node on a site — will now also, in turn, actually scale, rather than bog down the site and its poor admins beyond all hope.
  • Book module improvements. The D6 book module now uses the menu system to store its parent-child relationships between nodes, rather than storing these relationships in its own separate area. This approach is very similar to the approach that category_menu takes, and it may actually mean that menu integration can be removed from the D6 version of the category module, and that the category module can instead rely on the new book system in core for achieving this.

In my opinion, D6 is going to do two opposite things at once for the category module. First, it is going to make it less necessary than ever, as the book module improvements provide a lot of menu-integration functionality that was previously not possible with nodes in core. Second, it is going to make it more useful and more scalable than ever, as Drupal's new menu system is more ready than ever before to be relied on, and integrated with, by third-party modules. Personally, I believe that there will always be a need for a terms-and-vocabs-as-nodes solution, and that the category module is about as good as such a solution can realistically get (considering the current state of core), and also that the module has yet to come of age and to actually prove itself (neither core, nor the contrib module, is ready for this right now).

Jeff, I should also point out that I originally wrote a module called taxonomy_assoc, which does virtually exactly what your taxonomynode modules does — it associates nodes with terms, and embeds those nodes as the descriptions for terms. The category module was born from my frustration with this limited solution, which didn't do nearly all the things that me (and many others) wanted out of the taxonomy system.

Reply

Anonymous

Anyone know the CORRECT way

Anyone know the CORRECT way to only display certain vocab terms in node.tpl.php?

<?php
        $terms1 = taxonomy_node_get_terms_by_vocabulary($node->nid, 19);
        if ($terms1) {
          print '<span class="labels">TAGGED: </span>';
          foreach ($terms1 as $key => $term1) {
            $links[] = l($term1->name, 'taxonomy/term/'. $term1->tid);
            print implode(' ', $links);
          }
        }
     
        ?>

The above code will not work for me. Something about the
$links[] = l($term1->name, 'taxonomy/term/'. $term1->tid);
and the [] not being allowed? Reply

Ola Lindberg

Thanks a lot!

This episode was really great! Thanks a lot! Covering such a hard-to-understand topic as Taxonomy in a podcast was just what I needed.

Best regards,

Ola

Reply

catch

multiple hierarchy and synonyms

We just moved a load of taxonomy terms from a free-tagging vocabulary into a mulitple hierarchy (yes we're mad).

The reason is we want to have regions classified like:

Europe
-Germany
-Turkey
Middle East
-Iraq
-Turkey

You're right that the UI for inputting this is rough though. Pretty sure there's a module that allows each level of selection to be it's own select box, conditionally displaying the terms underneath, just hav eto find it.

With synonyms, the only thing I've seen mentioning them recently is this amazing patch against Drupal 7. If you've got synonyms set up for a freetagging vocabulary, it'd tag the node with the term itself, if any synonyms were entered. So you could have 19 mis-spellings as synonyms, and it'd catch them, rather than having to go in and delete/merge terms all the time. Same for sofas and couches etc.

Reply

dfd

multiple hierarchy

Hi,
I was wondering if you have found a module that allows each level of selection to be it's own select box, conditionally displaying the terms underneath. Sounds like exactly what I am looking for! Would be grateful if anyone could suggest a module. The idea of creating one from scratch is a bit daunting.

Reply

JL

multiple hierarchy - conditional selection?

Hi,

This is exactly the same problem I have. I have a taxonomy with multiple hierarchy and have to categorize the nodes accordingly. Did you find the solution to your problem?

Thanks a lot!

Reply

guardian

taxonomy_redirect

please, could you emphasize more on the usefulness of taxonomy_redirect ? i mean compared to setting up a taxonomy/term/tid view ?

at first, i thought it could be "getting rid of the taxonomy/term/tid" url but pathauto is here to help :)

so ? what's so terrific about this module ?

Reply

Joseph

Taxonomy Redirect

I just put this module to work to solve this problem:

  • I created a View that lists nodes in a very customized format.
  • The View has a Taxonomy:Term "argument", which means that there is essentially a separate view page for nodes tagged with each term. These pages have paths like: myView/term1, myView/term2, etc.
  • BUT whenever a term showed up on my site, the link would take the user to taxonomy/tid/1, taxonomy/tid/2, etc., which shows the list of nodes in the standard teaser format, not my customized layout (+ extra filtering criteria, etc.)
  • How can I "take control" of those taxonomy term links (which are oh so nice) and "redirect" them to my custom views? Well, Taxonomy Redirect, of course!

I was really pleased to hear this is a lightweight module. Something that would be VERY useful for the contrib. modules is a rating system. Modules should be rated by their developers based on how "heavy" they are, their scalability, and how easy or hard it is to "back out" once you've invested in the module. Modules should also be rated by their users, so the community can see what others think.

Reply

Amnon Levav

Synomyms *are* used by the glossary module!

Unlike noted by your podcast, There IS a module which leverages the 'Synomyms' lists.

As far as I know, those lists are used by the glossary module! All synonyms are highlighted with a link to the original term.

Example: Synonyms are highlighting my terms in http://sakeret.com, a Hebrew natural diabetes healing guide.

Enjoy,

Amnon
-
Professional: Drupal Israel | Effective Hosting Strategies | ????? ?????
Personal: Hitech Dolphin: Regain Simple Joy :)

Reply

Evan

There was some discussion

There was some discussion regarding when to use a vocab and when to use a CCK field, which was basically summed up as, "Use a CCK field if the node does not make sense without it."

I'm looking at designing an employment site, with job listings as a node type which would have several select/drop-down fields like employment type (perm, temp, contract), location (i.e. city or suburb) and similar. The advanced search page would be able to search on these fields specifically.

Now, the node is incomplete without this information, so the above wisdom makes me think that they should be CCK fields, but the taxonomy facilities seem perfect for the requirements on this.

What are the pros and cons? Should I look at some sort of bridging between the two such as the CCK Taxonomy Fields module that I think was mentioned?

Reply

cathy

more please

Yes, I need more help in deciding a CCK field vs taxonomy...
is there a collection that points to people's posts in the drupal post installation forum where they say: my site needs to... how? with what?

Maybe I could then find a site similar to what I need and look at their solution...

Reply

Anonymous

An easy way to add content

An easy way to add content to the top of taxonomy is to add a block that only appears for the specific taxonomy. Of course, this is not very scalable, but for small sites it is quick and easy.

Thanks for the great podcast, I learned a lot!

Reply

Richard Schaefer

My method

I like to use the taxonomy_term default view to generate my taxonomy lists with a certain level of navigation. But what I also is set the view to 'Teaser List', and then modify the teaser template for the content type(s) that appear on the list. That way you can make the taxonomy list output just about anything you want.

Reply

Avangelist

jjjjjjjjjesus I am bored

That is it, I have reached 16 minutes of this drivvel and you haven't kept me interested.

Get to the blimmin point will you.

93 minutes my butt.

I can sum this up in a short sentence.

Taxonomy - use this because you cannot use keyword meta data in Drupal.

You're welcome.

Reply

Hans (drupal) B...

Only boring people get bored

All you're really saying is that you are already very familiar with this topic. Someone just starting out with Drupal would get a lot of good ideas from this even if they already thought they understood what taxonomy was all about.

Great job Lullabots and thanks!

Idea for enhancing the value - find a way to motivate listeners to contribute to a transcript/summary page, perhaps then turning into a wiki/forum discussion on the topic covered.

Reply

Anonymous

use the texonomy terms to be used with the conditional fields

i have created the vocabulary include multi terms in hierarchy and
i want when i select term, i want to see the file field and when i select other term i want to see the
image field. i have tried it with the conditional field + content taxonomy to solve but...

Reply

Anonymous

use the texonomy terms to be used with the conditional fields

i have created the vocabulary include multi terms in hierarchy and
i want when i select term, i want to see the file field and when i select other term i want to see the
image field. i have tried it with the conditional field + content taxonomy to solve but...

Reply