There is no reason why you have to select a content type for a vocabulary.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kkaefer’s picture

Category: task » bug

(Duplicate of http://drupal.org/node/75386; the patches are identical)

flk’s picture

Category: bug » task
Status: Needs review » Reviewed & tested by the community

I personally dont see why there should be a restriction on where a vocabulary should/nt be used...fair enough that certain modules want to create vocab for their own use but there is really no need to a vocab to be linked to a certain content type.

i.e. currently i am working on the user_tags module an want to create a vocabulary that is not linked to a content type (thats do able using taxonomy_save_vocabulary()) but if i wanted to change the settings of the vocab i created, i have to assign the vocab to a content which really is not necessary.

PS applied patch an works fine (removes required element of content type)

kkaefer’s picture

Same patch has been submitted here: http://drupal.org/node/59623

flk’s picture

Status: Reviewed & tested by the community » Closed (duplicate)
Zen’s picture

Status: Closed (duplicate) » Reviewed & tested by the community

So, this is set to duplicate and the other patch is set to won't fix. Rather counterproductive, no?

Setting this issue back to its previous status.
-K

RobRoy’s picture

I agree that content type should not be required. Many times you create a vocabulary before you create the content type or create a vocabulary for other uses. +1

ChrisKennedy’s picture

Category: task » feature
Zen’s picture

Category: feature » task

This is not a feature request. I would class this as a bug, but can live with task.

Thanks,
-K

Dries’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

I don't understand the use case and I'm tempted to mark this "won't fix". A taxonomy without a node type has no practical use.

kkaefer’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community

If you disable a module (e.g. forum.module) temporarily, the node type disappears. Then, if you want to update the vocabulary, you can’t save because you have to select another node type. This restriction often bugs me when rearranging a site, enabling/disabling modules etc. Also, there is no benefit in having a user select a vocabulary. If no node type is select, it’s pretty obvious that the user can’t use the vocabulary to categorize nodes.

On the other hand, there are some modules that use vocabularies/terms for their own purposes instead of attaching them to nodes. Taxonomy is not really tied to nodes that much. E.g. there is a module that allows tagging users. If you just use a vocabulary for tagging users, you don’t want to select a node type for it.

RobRoy’s picture

I agree with both kkaefer's use cases. The first one definitely bugs me a ton and I end up having to select page for node type, then going back and changing it later. I've also use taxonomy before together with a custom module that did not categorize nodes. I still like this!

drumm’s picture

Status: Reviewed & tested by the community » Needs work

What if we set a message after a vocabulary is saved with no content types selected, which explains that the vocabulary won't do a whole lot and offer a link back to the edit page?

RobRoy’s picture

Marked http://drupal.org/node/116748 a dupe of this.

RobRoy’s picture

Version: 5.x-dev » 6.x-dev
Status: Needs work » Needs review
FileSize
2.67 KB

That last issue I mentioned actually includes another where upon UPDATING a vocab you don't have to select a content type which I've included in this patch. Also, a minor change to the wording for types/node types to make it more consistent/clearer. Still some "node" in user facing text on that page, but that's for another patch.

Chris Johnson’s picture

Additional use cases for taxonomies without content types:

  1. Using the existing glossary module.
  2. Administratively creating a vocabulary which will be applied to node types in the future, but for the time being is not. For example, during the development of the vocabulary before the terms are finalized, to prevent it from appearing to content creators.
  3. I'm sure if we tried, we could dream up other use cases.
Zen’s picture

Status: Needs review » Needs work

I think that it's a lot cleaner to just update the description text for the "content type" association check-boxes field to be more informative, rather than adding a rather redundant status message.

-K

Zen’s picture

Status: Needs work » Needs review
FileSize
2.11 KB

Perhaps like so.

Zen’s picture

FileSize
1.65 KB

Missed a spot.

Dries’s picture

I think we'll want to write 'categorize' instead of 'categorise'. If you fix that I think this patch is RTBC.

Zen’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.65 KB

Here you go.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)