How does this differ from Taxonomy Enhancer?

I tried Taxonomy Enhancer awhile ago, but found it to be quite buggy and not exactly what i was looking for. So I spent a lot of time developing Term Fields for my personal use but along the line I decided I would release it back to the community since Taxonomy Enhancer lacks the features you mentioned, namely views integration and a variety of field types. Another major difference is under the hood... it uses quite a different schema from Taxonomy Enhancer. I'm sorry if it too closely resembles your module, but I don't get the impression that TE intends to be 'CCK for taxonomy terms', like I'm trying to sell my module as.

Maybe we could combine forces? I was considering contacting the maintainer(s) of Taxonomy Image and seeing if they would like to team up to make a taxonomy term fields super module, as images and file uploads in general should be considered fields too. Maybe one day we can have a 'Taxonomy Construction Kit' that mirrors the functionality of CCK. Of course, this all might be irrelevant once Drupal 7 and the field API are released ;)

About the lack of a hook for the term load event - my goal with this module was mainly to have the user display their fields using views, so I wasn't all that concerned about it. I did make a function, term_fields_get_term, which just calls taxonomy_get_term and then adds the fields for that term into the object.

Alright, I agree with that. Whatever is best for the community is the way to go. If you'd like to co-maintain the module with me I'll gladly grant you CVS access.

This is exactly what i was looking for. I was considering turning terms into nodes but this is better.

Thanks a lot.

Ps: I was not aware of taxonomy enhancer because i filter modules by version number and i'm using drupal 6

Subscribing, is there TE functionality which will be inserted in this module, like the possibility to theme the fields, or is it inside this module already?
greetings, Martijn

Term Fields uses Views to display output, so in that way yes all the fields are themeable because all output in Views is themeable.

Sorry, but is "Taxonomy Fields" not a similar/duplicate module? http://drupal.org/project/taxonomy_fields

@verlierer - no, they're not. Taxonomy Fields lets you assign CCK fields to taxonomy terms that make it so that when a node is added with that term, the CCK fields assigned to that term are automatically assigned to the node as well. Term Fields actually lets you assign fields directly to terms.

So what is the state of joining? Here is the patch for http://drupal.org/project/taxonomy_enhancer #305736: Drupal 6 port available for branching

So what would be some of the pros and cons of using this versus nodes with the node reference field?

@qbnflaco - this module has absolutely nothing to do with nodes.

ok, let me rephrase this.. I build out sites and usually if it's something I want to categorize, I use taxonomy. The only info I want for that is the actual term name, no other details. If there are more details, I make it another content type and use a node reference field. I'm curious what the advantages and disadvantages would be between this and using the term fields module.

I second #12. Duplicating CCK for terms actually seems like lot of wasted effort. There's nodereference field and instead of using taxonomy terms for categories one could just use nodes and use nodereference field to put content in categories. Also nodereference field is quite stable, long established module and is supported by CCK maintainers.
There is only one thing that makes taxonomy terms as categories in this case better: taxonomy has great established tools for working with collections ( Taxonomy Manager, Taxonomy XML etc) and you can't manage collection of nodereferenced nodes same way.
All this leads me to the idea, that effort should be spent in the general solution that provides stable and "synced" term-node relationship. Then one could maintain collection using Taxonomy tools and edit individual items in collection using Node tools.
Also, we should look what D7 offers us in this area, and keep in mind that developing tool that follows D7 approach could lead to minimum effort in porting it to D7 later.

@crea and qbnflaco: Either you guys don't understand what this module does, or I don't understand what you guys are talking about.

This module is meant to be completely separate from the node system, and I don't even understand how a nodereference field could possibly be used to duplicate the functionality of this module.

If you want a generalized solution to keep track of term-node associations, check out the Content Taxonomy module. I use it on my site in conjunction with Term Fields to provide an elegant solution to my data structuring needs. Content Taxonomy simply creates a CCK field for a certain vocabulary and saves the term id(s) that are attached to that node from that vocabulary. What's cool about this is that, contrary to the default term_node table that core provides, all the terms associated with the node are joinable in a single row in the query. This way you can do cool things like create node views and show taxonomy terms associated with those nodes AND tablesort the results by the taxonomy terms. You can't do this without Content Taxonomy, because the term_node table creates a separate row for each term-node association. Furthermore, when you add the relationship for the Content Taxonomy field in views, all views data that is associated with terms (it uses term_data as its 'base' table) becomes exposed in that node view! Term Fields is an example of a module whose data gets exposed.

Term Fields comes in when you're issue is something that doesn't involve nodes at all. Let my explain how my site works as an example.

I run a site which provides guitar tablature from video game music (http://www.gametabs.net). Every guitar tab that gets added gets assigned a game through the Taxonomy/Content Taxonomy module. I also have a vocabulary which houses a list of composers. I want to assign composer terms to game terms for games of which they've composed. So I created a numeric field using Term Fields, and, through an interface I custom made for my site, my users are able to associate composer term IDs with game term IDs. In this way I can, using views, create for each composer 'profile' pages which contain information about games which they've composed for. But because the composer 'fields' are also terms themselves, I can use the Term Fields module to add biographical information about each composer like date of birth, musical influences, etc. And I can expose that data to Views and use it on the 'profile' page. I don't have a clue how this could be done with a nodereference field.

Also, this module does follow the Drupal 7 approach. In 7, every object becomes fieldable. Taxonomy terms in my mind are objects that can have fields, as well as fields themselves. I plan to fully incorporate this module with the Field API when Drupal 7 comes out and reap all the benefits of a full blown CCK like field system for taxonomy terms.

Thanks for the answer, actually I use Content Taxonomy myself :)
I guess what you described with guitar tabulature site could be easily done with nodereferences too.
You would have to have different nodes: "composer" node, "game" node, and "tab" node. Then you would have to connect them together via nodereferences. Then your users just fill in nodereference fields instead of adding terms.
Note, that Nodereference provides Views relationship too, so you can have view that lists one node data and data from the node the first one references to. Also Noderefence has Panels integration (as Ctools relationships) so there's lot of flexibility there.

Oh ok, I see now. Vocabularies become node types, terms become nodes, and their associations are handled with a node reference. Makes sense. I've always shied away from the 'everything as nodes' mentality but I can definitely see the usefulness there. Because then your 'node-terms' automatically get the full power of the node system and CCK at their disposal! Wow. My whole life has been a lie.

I'm gonna have to put some serious thought into whether or not I want to go down that path myself. I agree that the only advantage taxonomy provides over that approach is maintainability. But I'm a serious taxonomy user and I don't even have a need for anything like Taxonomy Manager.

Well, by "collection" I mean not just plain collection, but hierarchy of items. Even if you don't use Taxonomy Manager, you probably still use taxonomy tools like tree traversing, finding parents and children etc. AFAIK Nodereference doesn't allow easy traversing of connected nodes. Guess that is one of the places such "integration" module should be aimed to.

Hi,
I understand this discussion, but I still think there is a need for "Assigning fields directly to terms", say currency to country terms. Hopefully this keeps being possible with this module?
Greetings, Martijn

Hi Martjin,

I've given it some thought, and yes, I am still going to maintain this module as I can see some issues with using nodes as terms. Like hierarchical vocabularies, for example.

I am going to begin working on a Drupal 7 version of this module soon which will use the Field API, and thus bring all the goodness of CCK to terms without any issues. An upgrade path will be provided. For now, the Drupal 6 version will remain unchanged, unless a major bug crops up.

It looks like Drupal 7 now has a field UI to match its API, so no true module will be ported to Drupal 7... only an upgrade path.

Hi, Do you mean this module becomes obsolete for D7?
Greetings, Martijn

@Summit Yes. The CCK engine for nodes in Drupal 6 is Fields. Currently fields can be assigned to nodes, users, taxonomy, plus other user defined "bundles" (A bundle is like a vocabulary or content type). Work is in progress for profiles too, but this may not get in before the code freeze sadly.

+ for the D7 upgrade path

@archard: I am the TI maintainer. I have no problem joining forces, but am reluctant to do much to the 6.x branch when the 7.x version will be so different - maybe even largely unnecessary due to Fields in core. I have to do a lot more research there.

What are your plans for the upgrade path from your module to D7? Thanks.

Fieldable terms in core does indeed eclipse most of these related projects. It will be interesting to see if an upgrade path is practical.

A new issue for discuting about an export feature to Dt fieldable terms has been created:
759138: Upgrade fonctionality to import term fields into D7 fieldable terms

I think this issue may be closed. If I am wrong, don't hesitate to reopen it.