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.
We now have the ability to assign vocabularies to specific modules, but the taxonomy module claims all vocabularies for its vocabulary and term editing interface. This leads to problems, see e.g. this issue: http://drupal.org/node/24274.
We should probably limit the taxonomy editing interface in taxonomy.module to vocabularies assigned to taxonomy. Or, at least, provide a way to exclude a particular vocabulary from taxonomy.module's interface.
Comment | File | Size | Author |
---|---|---|---|
#9 | taxonomy.columns.20060215.patch | 1.12 KB | mfredrickson |
Comments
Comment #1
Crell CreditAttribution: Crell commentedBig +1 on this. Taxonomy is very powerful if properly leveraged by other modules, but often other modules will use a lot of them. I've a module I'm still working through in my mind that will, in practice, have 50-odd vocabularies just for itself. Having 50+ vocabs, each with a dozen or more terms, would make the taxonomy page completely unusable as it is now. That interface should be reserved for user-created vocabularies, not system-created vocabularies, at least by default.
I can see a reason to have an edit-all-vocabs option in order to unbreak something or for the master admin to get an overview of the system, but that's a very special case. Let's make that a special case, not the default.
Comment #2
chx CreditAttribution: chx commentedBig -1 on this. When module was introduced it was tried and reverted for damned good reasons, it was just a PITA.
Comment #3
Crell CreditAttribution: Crell commentedDefine "damned good reasons". I know for what I'm planning to use it for, the current taxonomy setup is going to be a PITA. Why is non-visable vocabs or module-owned-and-operated vocabs a more of a PITA?
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedbasically, for some applications you like seeing the vocabs on admin/taxonokmy and others you don't. when we hid them from there, some complained because they were using the same vocab for forums and other things. we essentially removed their ability to admin that vocab properly .. not sure what the right solution is here. maybe we hide them by default from admin/taxonomy but let a varaible_override show them. that way, a savvy admin could bring them back. only savvy admins share vocabs like that
Comment #5
robertDouglass CreditAttribution: robertDouglass commentedAs a programmer, I'm a fan of the idea of being able to say that a vocabulary is module created, managed and should never be manipulated by the administrator. Whether this applies to the forum or image modules is another thing. I'm still +1 for having a status for vocabs that strictly excludes them from the interface. We do this with menu items. Some can't be deleted or disabled. Some can be disabled. Some get put into the menu as visible items and some as suggested items. This level of granularity would be my wish for taxonomy vocabs as well.
Comment #6
nedjoOne approach would be to introduce a new field in the vocabulary table. This could be:
* a boolean (tinyint) field with 1 meaning taxonomy module should handle the vocabulary, or
* a varchar just like the existing module field, but defaulting to 'taxonomy', indicating the module that handles the vocabulary.
Of the two approaches, this second one (we might call the field 'handler') seems the more flexible. It could enable scenarios in which, e.g., modules define vocabularies to be handled by the forum module.
Comment #7
mfredrickson CreditAttribution: mfredrickson commentedSee also:
http://drupal.org/node/48599
Comment #8
Jaza CreditAttribution: Jaza commentedTo please everyone, I'd say the best solution would be to move the module-administered vocabularies to a separate tab. At the moment, all vocabularies are shown in the 'list' tab (i.e. 'tab' as in 'menu local task'). This tab could be further broken down into two sub-tabs (i.e. 'sub-tabs', as in 'menu secondary tasks'), called 'user vocabularies' and 'system vocabularies'. So the menu structure would be as follows:
We can also put some help text on the 'system vocabularies' page, saying that the vocabs on this page should not usually have to be edited.
Comment #9
mfredrickson CreditAttribution: mfredrickson commentedOn nedjo's solution:
Why do we need another field? Isn't one enough? Modules that want taxonomy to handle their vocab will not set that field, modules that want control will. As I understand it, this is backwards compatible because this field is new. Only modules that want control will request it, and existing systems won't break.
I vote -1 on tabs, +1 on a column based approach. Right now we have "name", "type" (indicating which node types) and "operations" (edit vocab, edit terms). I suggest adding "module" and displaying the vocab's name. If admins want to mess with system controlled vocabs, that is there business, but they should have the right info.
Attached is a patch to do just that.
-Mark
Comment #10
mfredrickson CreditAttribution: mfredrickson commentedIn addition, we might want to think about creating a set of callback hooks.
Every time we do something to a vocabulary, we grab the module name and invoke the module'
s
hook_vocabulary_update/display/whatever
. Taxonomy could implement its own methods by implementingtaxonomy_vocabulary_update/display/whatever
.Robust. Addresses the issue at hand. Does not break old code (unless they happen to have named a function with our hook title).
Can we identify where we will need these hooks and if we should have one massive hook function or many individual hook functions (I would suggest 1, but I'm open for alternatives)?
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commentedmfrederickson - why do we need another hook. you have seen hook_taxonomy?
Comment #12
mfredrickson CreditAttribution: mfredrickson commentedOk. I should have said, the hook should be extended. In looking at it closer, I think it does
1. I can trace no path from taxonomy_form_alter to an invocation of this hook. Did I miss it? Chx notes in another forum topic that I can use weights to force my module to alter forms after taxonomy, but this seems like a bad idea.
2. The form option only allows for extra information on the term and vocabulary creation forms, not for the deleting of information. Therefore I can't call this hook to take information out of the form. I could use hook_form_alter, but I don't want to alter all examples of the taxonomy forms, only those that appear on my modules pages. I will admit I don't know the form API well enough to know if I can do this robustly.
This could also be accomplished by splitting taxonomy_form_vocabulary into two functions: one to build the form and one to call drupal_get_form on it. Similarly for form_term. I'll put together a patch.
3. (This is starting to wander from the exact nature of this issue, but I'm going to include it anyway) Taxonomy_node_save never calls the hook either. I would like it to call a hook with the old terms and the new terms. Or, this function could invoke node_load and node_save, but I don't think it is necessary.
In this post I'm trying to identify issues I see in my own custom module, taxonomy access control, and the core taxonomy.module. I apologize in advance if it is hard to follow.
Comment #13
LAsan CreditAttribution: LAsan commentedStill a feature request?
Comment #14
catchYep, but not going to make it into D7.
Comment #15
jibranI think it is bit late for D8.
Comment #16
BerdirThe concept of using vocabulary and terms for for storing things that aren't really terms dates back to pre-7.x or even 6.x, where it was the only available option to categorize/reference content. Things like forum, userpoints.module (weird categories for something that aren't nodes), simplenews (newsletter categories), should all be using their own entity for this now. I'd say whatever we do support here exactly should be dropped and removed, just like we already did for node types.
Comment #17
catchPretty sure there is no support for this at all any more, vocabularies are bundles/config entities.