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.

CommentFileSizeAuthor
#9 taxonomy.columns.20060215.patch1.12 KBmfredrickson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Crell’s picture

Big +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.

chx’s picture

Big -1 on this. When module was introduced it was tried and reverted for damned good reasons, it was just a PITA.

Crell’s picture

Define "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?

moshe weitzman’s picture

basically, 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

robertDouglass’s picture

As 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.

nedjo’s picture

One 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.

mfredrickson’s picture

Jaza’s picture

To 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:

Home
-- administer
---- taxonomy
------ list
-------- user vocabularies
-------- system vocabularies

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.

mfredrickson’s picture

On 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

mfredrickson’s picture

In 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 implementing taxonomy_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)?

moshe weitzman’s picture

mfrederickson - why do we need another hook. you have seen hook_taxonomy?

mfredrickson’s picture

Ok. 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.

LAsan’s picture

Version: x.y.z » 7.x-dev

Still a feature request?

catch’s picture

Version: 7.x-dev » 8.x-dev

Yep, but not going to make it into D7.

jibran’s picture

Version: 8.x-dev » 9.x-dev
Issue summary: View changes

I think it is bit late for D8.

Berdir’s picture

The 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.

catch’s picture

Status: Active » Closed (cannot reproduce)

Pretty sure there is no support for this at all any more, vocabularies are bundles/config entities.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.