ebase.org is preparing to launch a new drupal site, whch will replace two older sites, www.ebase.org and community.ebase.org. We've got drupal up & running fine, and we've developed a lot of our static content, theme, modules, some navigation, etc. We're unable to reach agreement, however, on how to best use taxonomy.module.
Our previous drupal site grew to >1,300 nodes, and it was difficult to search, navigate, and post to. We expect the new site could easily grow as large, so we're trying to develop features, many of which rely on taxonomy.module, to make the new site more usable and easier to maintain.
Specific questions that have come up include
- What resources are available to guide us in using taxonomy.module effectively?
- What are the pros and cons of using separate vocabularies for different content types, as opposed to trying to categorize disparate types of content within one vocabulary?
- How can we best coordinate modules that require their own vocabulary, such as Forum, with other content types that may be used to post content on topics also discussed in the forum?
- How can we make our taxonomy as easy as possible for public users, while balancing our desire to effectively and thoroughly organize publicly contributed content?
- What are effective strategies for extending/revising a taxonomy that's already been used to organize a large body of content, and what should we do now to smooth the path for future revisions?
If you have experience effectively organizing large bodies of content using taxonomy.module, please have a look at our planning documents
http://test.ebase.org/node/40
and contact me (allen@cdsnw.com) with any suggestions you have.
Thanks!
-Allen
Comments
A note on point 4 about user submitted content and taxonomy
We looked at a few ways to allow users to submit content in a flexible way and not be restricted by the taxonomy system and at the same time not let the content get too dispersed as may happen with freetagging.
1) We used cck and cck field permissions (http://drupal.org/project/cck_field_perms) to create an additional admin field where a user could suggest a category/topic/term that was not in our current taxonomy terms. The node would go into moderation and the administrator would then see if the suggested topic was valid to add to the list of taxonomy terms in our vocab.
We settled on
2) Created a seperate vocabulary for suggestions and set it to freetagging, which we associated with content types where we wanted users to suggest additional topics to classify their content. The content type would have its standard (moderated) taxonomy and then below a freetagging field for suggested terms/topics. For sites with large user base, with 100s of nodes being submitted daily, admin can easily create a view to show terms in the user suggested vocabulary with node count. This is useful because a term with a high node count would certainly make that user suggested term viable for including in the sites core taxonomy.
We also created another vocabulary for freetagging for each content type for the purpose of tags. This vocabulary was created more as a 2ndary classification and for tagclouds, which I can testify do work even for the most novice users. It just gives an alternate way for content to be classified in a more liberal way. We would not really use it for the site structure but display it below the node content as keywords/terms associated with this article/product/company.
This setup gave us the ability to allow more defined categorisation and at the same time maintain flexibility for our users. Its a win win situation (except maybe on performance side which can be somewhat resolved by using one of the cache options).
We prefered using seperate vocabularies for different content types but looked carefully at places where we could use 1 vocab, eg: Product Type and Brands. We shared the vocabs called Brands and Products, between product content type and a company content type. A company can have many brands and products associated with it and a Product can have a brand and product term associated with it.
Our difficulty came with content type to content type and vocab 2 vocab relationships (the category module solves this but we felt it is not stable enough to use). For eg: We have a company node type that has a country vocab. We have a product node type that does not have a country vocab, but is required to be associated to a company content type. Every product content type node created must be related to a company content type node. So the difficulty came in having to list Products from a particular country and simmilar cross referenced queries. We would have to query the db to find all companies in x country with x product. We also had difficulties with views and breadcrumbs. It was a stumbling block for us as we don't have the high level php resources to quickly code effective queries and render the data in the best way for the user. So this took us a while and we are still working on it (and enjoying it!).
Regarding your last question, take a look at the http://drupal.org/project/taxonomy_batch_operations module and look into the suggestion above for moderated user taxonomy.
My feeling about forum, is that it should have its own distinct vocabulary and that one could always use one of the modules that displays related content to offer the user alternate reading from the forums and lets say articles or product node types. Forums tend to grow very quickly and sometimes the content is not exactly what you would want to display anywhere other than the forum. Users tend to know what a forum content is and understand that the site is not exactly 100% responsible for the content, so they won't hold u responsible for oppinionated community content. Of course using views you could filter by content type, but it just feels so much cleaner to have a sep vocab for forums.
Does any of this help?
Yes! Thanks!
We'll need toms time to digest your approach and test it against our needs, but it certainly sounds like a clever approach to some problems we share. Thanks for taking the time.
Yes! Thanks!
We'll need some time to digest your approach and test it against our needs, but it certainly sounds like a clever approach to some problems we share. Thanks for taking the time.
This might be a good place
This might be a good place to start:
http://drupal.org/node/81589
----
Previously user Ramdak.
Hadn't seen that one
Yes, that's a helpful piece - thanks! Funny that it's categorized under "customization and theming," as if all use of categories were customization.
You're welcome. I wouldn't
You're welcome. I wouldn't have known about it either if I hadn't bumped into by chance and bookmarked it.
----
Previously user Ramdak.