CCK Taxonomy Fields 5--1.1

Events happening in the community are now at Drupal community events on www.drupal.org.
mlncn's picture

Robert Douglass announced a new release of the CCK Taxonomy Fields module. The module allows sets of terms to be used as custom fields on content types.

This release fixes Views integration and guarantees that hierarchical taxonomy lists are represented correctly wherever they appear.

Douglass would like help with sorting views by CCK taxonomy and free tagging support.

Comments

KentBye's picture

As I understand it, Free Tagging support for a view requires that it multiple free tagging forms can be shown in the node teaser -- or in this case themed within a view.

I just wanted to point out that nedjo has actually implemented the ability to tag nodes in teasers in a patch for the community_tags.module, but it had other complexities that ultimately killed this patch.

I've looked into this a little bit and actually started a feature request thread to support tagging nodes in teasers with the community_tags.module. nedjo's patch needs to be simplified and tested, and there is some growing interest for this from others as well. So it may be worth checking out to see if there's any overlap.

Taxonomy and CCK

mlncn's picture

kentbye brings up another way "taxonomy fields" can be interpreted -- in this case, as allowing people to tag content without editing the content.

A taxonomy field that is made available to people who cannot edit the node, using the (buggy) CCK Field Permissions module, could approximate community tags functionality, but it would always be more awkward. In doing Community Managed Taxonomy I will see if I can draw on Nedjo's work and generalize the ability to tag nodes.

Meanwhile, there's another taxonomy and CCK module other than Robert Douglass' CCK Taxonomy Fields.

It's been around since 4.7 and has a Drupal 5 development version also. It seems to expose taxonomy to CCK directly.

Content Taxonomy:

This module provides a field type for CCK for referencing taxonomy terms.

Available widgets:
- selects
- radios / checkboxes
- autocomplete
- activeselect

I think we're in need of a good document explaining the differentiation at least between these two modules.

~ ben melançon

member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"

benjamin, agaric

Content Taxonomy

mh86's picture

The Content Taxonomy module offers you some additional settings to taxonomy fields, but a detailed documentation of my module is still missing, so some things might be a bit confusing to people.

One important point is, that the Content Taxonomy allows you to select only some hierarchical parts of a vocabulary, which are then exposed to the form field, e.g. you determine a parent in the admin settings and only the children of this parent are shown in the form field.

Furthermore it's possible to choose between different element types, like selects, radios/checkboxes and autocomplete. The activeselect support is a bit buggy at the moment, but it would be a great feature. It allows you to place dependent select fields so that only children of the selected term above are loaded through AJAX.

Concerning the saving mechanism of the Content Taxonomy, it offers you in general two possibilities, first you can save the term-node relations like the taxonomy module does (in the term_node table), or the second way is to save the terms in cck tables, like the CCK Taxonomy module. If you want to use functionality from the taxonomy module, it's better to use the first saving mechanism. If you use Views instead, the second way of saving terms might be better and more efficient.

robertdouglass's picture

Matthias' module is far more feature rich and configurable than mine, and it will stay this way. The only real similarity that the two modules share is that there is a way to get the tid stored in a CCK field table. Both modules should be developed and bugfixed. A detailed architectural document explaining the differences between the two is in order, but I'm not promising to write it soon. I'd love to see the views sorting and freetagging support that Benjamin mentioned find their way into my module. It would also be nice to think of a way to offer terms for display as links, similar to taxonomy module, but rather links to views which pass the term name in as an argument.

Glad we're all talking about these modules =) These are the efforts that will help taxonomy.module become what it should be... a hierarchy manager.

Taxonomy shouldn't be a poor-mans-views for taxonomy listings, and it shouldn't worry about the semantic meaning of its hierarchies (which is the aspect that my module targets the strongest). Using cck_taxonomy, vocabularies become hierarchical lists. You only decide what the semantic name of that list is when you attach it to a content type as a field. As such, you could have a list of sizes {small|medium|large}, and apply it to a content type three times: shoe size, t-shirt size, nose size. Three semantic meanings, same list.

Taxonomy Panels

mlncn's picture

Robert Douglass' request for "links to views which pass the term name in as an argument" is perhaps answered by the ability to replace a taxonomy page with panel:

http://drupal.org/project/panels_taxonomy

~ ben, Agaric Design Collective

benjamin, agaric

Hi Matthias, I didn't realize that was yours

mlncn's picture

I feel more than a little silly... I'm glad it was highlighted here. The link to the project again... Content Taxonomy.

How difficult or what side effects might there be of saving terms in both ways? I'd rather work on making taxonomy a first-class citizen of views, though.

~ ben melançon

member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"

benjamin, agaric

saving terms in both ways..

mh86's picture

In Content Taxonomy, there is a option to save terms twice, first in the standard term_node table and second in a cck table. In this case, when a node is loaded, terms get loaded from the cck table instead of the term_node table, because I think it's a little bit faster. I not sure if there are many use cases, where saving twice really makes sense, I rather think, that this has more disadvantages, because of double saving the same information.

difference in display

ray007's picture

I think it would be enough to save the information only in one place, but what I like about the 3 options (cck, terms, both) is the different visualization when showing the node:
When saved in cck table the information is shown inline in the node.
When saved as terms you get the taxonomy links.
And "both" ... well, no need to explain that one, right?

Whatever changes in the storage model I hope we still get those 3 "display options".

--
best regards

    Ray

If you need a drupal developer contact me!

--
best regards

    Ray

If you need a drupal developer contact me!

use cases

mlncn's picture

I was thinking about Tagadelic and various contributed taxonomy modules, especially for site structure and breadcrumbs.

~ benjamin, Agaric Design Collective

benjamin, agaric

similar enough?

ray007's picture

You say that content_taxonomy is more feature rich and configurable. I'm really curious about your document describing the differences between the two, because from what I've seen so far I can't see a reason to not try to merge the 2 modules.

--
best regards

    Ray

If you need a drupal developer contact me!

--
best regards

    Ray

If you need a drupal developer contact me!

Content Construction Kit (CCK)

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: