Support taxonomy vocabularies

Tried out this patch and was able to export a vocabulary into a feature and revert it on another machine. Looking good so far.

Wouldn't this interfere with hook_term_path implementations?

Can you explain how?

Looks to me like hook_term_path is only giving the module a chance to change the path. If it is not provided, it will default to taxonomy/term/$tid

if ($vocabulary->module != 'taxonomy' && $path = module_invoke($vocabulary->module, 'term_path', $term)) {
    return $path;
  }

That is the piece of code taxonomy_term_path uses to delegate path specification to modules.

To specify a custom term path you have to give the 'module' property a valid name (letters, numbers and underscopes) and use it to implement hook_term_path.

Example: if vocabulary[module] == mymodule, mymodule_term_path should be implemented if you want to override the default path for terms under this vocabulary.

In the patch, 'module' fields (inside vocabulary definitions) are written as 'features:{modified vocab name}', which is a problem since ':' character can't be use inside function names.

I see your point.

The : doesn't seem to be strictly necessary. It looks like it could be replaced with _ and the patch would still work. There could be namespace issues with any modules named features_{machine_name}.

Would that work?

Updated the patch to use features_ instead of features: as its vocab identifier prefix.

If you've already exported vocabularies using this patch you will need to update your export to use features_ as well as run the following query against your database:

UPDATE vocabulary SET module = REPLACE(module, ':', '_');

Subscribing. Thanks

subscribe
note to self: dev->staging->production
only export taxonomy vocabs and the idea is to ignore taxonomy terms per no straightforward/stable solution exist

The patch in #10 no longer applies cleanly - first hunk fails (rest works).

seems like part of patch in #10 has already been incorporated into dev code base. This patch seems to be what is different now from current dev version.

ignore me in #14, that was incorrect.

ignore me in #14, that was incorrect. I think this one will run without failing.

The attached patch changes how taxonomy 'machine names' are managed. Bringing them closer inline with how they normally work. Instead of dynamically generating them I've added a machine name field on the vocab editing screen. I think this separation between the name as what we see vs. name as id is needed to prevent reckless branding changes from breaking features.

Same patch as #17, minus the call-time-pass-by-reference issues.

Just tested this patch out (#18), and it works exactly as I had hoped. I haven't reviewed the code, but I thought it would be useful to note that it passed my quick-and-dirty "does what it's supposed to" test :)

Thanks for your hard work on this; once this functionality is incorporated into features, I'm going to put it to extensive use.

Thanks!
Adam

I can confirm #18 works on a test vocabulary. It ends up with a different vid - is that right?

If so, can we move this to reviewed & tested by the community? We're itching to get moving with Features.

Just a thought... is this functionality duplicated by http://drupal.org/project/features_extra ? Also see #521630: Integrate Features with a Taxonomy Export Module.

I confirm that http://drupal.org/project/features_extra adds the functionality to export and import vocabularies as Features but the terms are not imported.

Reviewed and confirmed on Drupal 6.17, PHP 5.3. I'd say this is ready for release.

As an aside, it was mentioned by others that adding taxonomy terms would be a no-go, which does make sense for most cases. For the edge cases where a Feature depends on those terms to drive functionality, would this solution (indirectly) support any means of programmatically adding terms after the creation of a vocabulary? If so, I haven't found it - hook_install/hook_update_N is a no-go, which should have been obvious to me before, since those hooks fire before Features has a chance to work its magic. More than anything, I'm wondering if this merits its own issue - obviously it shouldn't hold up the review process here.

Subscribing

Modules providing vocabulary features integration:
http://drupal.org/project/exportables
http://drupal.org/project/features_extra
http://drupal.org/project/taxonomy_export

Modules using hook_term_path (never used any of them, but have used hook_term_path in several projects):
http://drupal.org/project/taxonomy_redirect
http://drupal.org/project/image
http://drupal.org/project/views_tpo
http://drupal.org/project/nodeorder

Btw, exportables has a issue to export terms, it also stores it's map between ids and machine names instead of (mis)using a existing field, and provides functions for looking up them, which is quite useful for matching of exported fields with their vids, etc.

Edit: Added taxonomy_export to module list.

@25 - Add http://drupal.org/project/taxonomy_export (2.x-dev branch) to the list providing features integration - I was introduced to it by a coworker just after I reviewed that patch, and it looks promising.

Looking at all of the alternatives, I'm in agreement that duplicating effort is a concern, and that resolving the issue here may not necessarily be the best approach. If I understand the situation correctly, the question we should ask is "where is the best place to resolve this?" Do we want this support in Features, or another contrib module?

If you look at the actual integration methods you will see that the approach taken by this patch is quite different from the other listed projects. This patch adds machine names natively to vocabularies and is paired by a Views patch (and may require other contrib patches) such that vocabularies can be referenced in other configuration objects by their machine name, not their vids.

subscribe

@27 - I'm not contesting the approach (I see the merit for machine names), but with the amount of similar solutions I (and seemingly others) am just left wondering where the "definitive" one should live. :]

I think it makes perfect sense for the handling of vocabularies to live in Features itself. Then other modules can build off that to do additional things, with all of them using the same foundation.

And several people have reported that it works, so changing it back to reviewed and tested.

I'd cast my vote for favoring an external module, probably Exportables, to host the base changes that enable exportability. This allows features to be a tool, rather than an infrastructure module.

I've updated the patch in #18 for recent changes in features and committed it! Thanks to everyone for your input.

@Grayside, I hear your concern, but for other non-exportables in core we do this same thing. So really this is right inline with what we're already doing and will probably keep doing until core incorporates these changes.

from http://www.angrydonuts.com/major-new-release-of-ctools-panels-and-panels... :

In an effort to make sure export.inc integration is generally useful, we added a new piece of code that will let it get its keys and fields from joined tables. This effort was ultimately to allow exportables.module to integrate with it (and thus get the free integration with features.module this provides). This means that many core objects such as vocabularies and input filters will soon be freely exportable just like views.

Does it mean that the approach of hijacking core's {vocabularies}.module column can be reverted ?
This column has one (single ?) useful use case, defining which hook_taxonomy_term_path() hook is called to generate term paths (when you want something else than /taxonomy/term/%tid). Hijacking it can have side effects on existing code.

Not for the time being -- just because an object is exportable using a serial ID doesn't make it useful. In particular any references in other configuration objects need to also be updated, and it's not a straightforward problem to track down every last vid reference in a view, variable, etc. and update it to be the new serial. Using the module column as the machine name for vocabs starts to address this problem.

As for hook_taxonomy_term_path(), this hook is still usable with exported vocabularies (but under the namespace of that vocabulary's machine name) and it's unlikely to affect existing code as anyone using this hook already was purposefully altering the module field of their vocab on creation. Any vocabulary created using the taxonomy module will not be affected.

I have to assume this patch is available in the aug 12 1.x-dev, right?

I don't see any difference or any support for exported vocabs in views...

Argument:

      'validate_argument_vocabulary' => array(
        '4' => 4,
        '2' => 0,
        '1' => 0,
      ),

Field:

      'vids' => array(
        '4' => 4,
        '2' => 0,
        '1' => 0,
      ),

Filter:

      'validate_argument_vocabulary' => array(
        '4' => 4,
        '2' => 0,
        '1' => 0,
      ),

---------------

I noticed a patch being worked on for module-name support for vocabularies in Views 3.x. Being that I'm running Views 2.x, is that my problem?

Yep, you will need #789674: Support vocabulary[module] field to reference vocabs by machine names in your views.

At least one of the earlier versions of the patches should work with Views 2.x., try http://drupal.org/node/789674#comment-3230930

Should the Features project page be updated to link from "Taxonomy vocabularies *" to comment #37, and also to remove the * from the description since it's now basically supported?

Subscribing, interested in this.

subscribe

subscribe

subscribe

Subscribe.