Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There is no reason why you have to select a content type for a vocabulary.
Comment | File | Size | Author |
---|---|---|---|
#20 | tax-required_0_0.patch | 1.65 KB | Zen |
#18 | tax-required_0.patch | 1.65 KB | Zen |
#17 | tax-required.patch | 2.11 KB | Zen |
#14 | taxonomy.module_37.patch | 2.67 KB | RobRoy |
vocabulary-content-type.patch | 738 bytes | kkaefer | |
Comments
Comment #1
kkaefer CreditAttribution: kkaefer commented(Duplicate of http://drupal.org/node/75386; the patches are identical)
Comment #2
flk CreditAttribution: flk commentedI 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)
Comment #3
kkaefer CreditAttribution: kkaefer commentedSame patch has been submitted here: http://drupal.org/node/59623
Comment #4
flk CreditAttribution: flk commentedComment #5
Zen CreditAttribution: Zen commentedSo, 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
Comment #6
RobRoy CreditAttribution: RobRoy commentedI 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
Comment #7
ChrisKennedy CreditAttribution: ChrisKennedy commentedComment #8
Zen CreditAttribution: Zen commentedThis is not a feature request. I would class this as a bug, but can live with task.
Thanks,
-K
Comment #9
Dries CreditAttribution: Dries commentedI 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.
Comment #10
kkaefer CreditAttribution: kkaefer commentedIf 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.
Comment #11
RobRoy CreditAttribution: RobRoy commentedI 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!
Comment #12
drummWhat 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?
Comment #13
RobRoy CreditAttribution: RobRoy commentedMarked http://drupal.org/node/116748 a dupe of this.
Comment #14
RobRoy CreditAttribution: RobRoy commentedThat 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.
Comment #15
Chris Johnson CreditAttribution: Chris Johnson commentedAdditional use cases for taxonomies without content types:
Comment #16
Zen CreditAttribution: Zen commentedI 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
Comment #17
Zen CreditAttribution: Zen commentedPerhaps like so.
Comment #18
Zen CreditAttribution: Zen commentedMissed a spot.
Comment #19
Dries CreditAttribution: Dries commentedI think we'll want to write 'categorize' instead of 'categorise'. If you fix that I think this patch is RTBC.
Comment #20
Zen CreditAttribution: Zen commentedHere you go.
Comment #21
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #22
(not verified) CreditAttribution: commented