Integrate Features with a Taxonomy Export Module

my first feature is 80% ok, but I guess taxonomy is not exported yet? Will taxonomy be part of this in later releases as my node type uses taxonomy in combination with a view which filters by term.

Here's some code that may be useful for creating taxonomies:

function test() {
  
  $vocab = array(
    'name' => t('Image Galleries'),
    'multiple' => 0,
    'required' => 0,
    'hierarchy' => 0,
    'relations' => 0,
    'module' => 'taxonomy',
    'nodes' => array('page' => 1),
  );
  $terms = array(
    array(
      'name' => 'term 1'
    ),
    array(
      'name' => 'term 2'
    ),
  );

  create_taxonomy($vocab, $terms); 

}

function create_taxonomy($vocabulary, $terms) {

  taxonomy_save_vocabulary($vocabulary);
  $vid = $vocabulary['vid'];
  
  dsm($vocabulary);
  
  foreach ($terms as $term) {
    $term['vid'] = $vid;
    taxonomy_save_term($term);
  }
}

I've used this in hook_install to put default taxos with a module.

subscribing...

I'd like to help with this if I can, since most of the stuff I want to export as features is heavily dependent on the presence of certain vocabularies. As I understand it, these are the pieces that have yet to be figured out:

1. Vocabularies don't have machine-readable names, but features/API.txt strongly recommends using machine-readable names as opposed to sequential IDs. This could be resolved in one of the following ways:
   1. Patch taxonomy.module to support machine-readable names (preferable, but potentially difficult since it's part of Drupal core?)
   2. Write a helper function that can generate an appropriate machine-readable name for a given vocabulary based on its human-readable name and, if necessary for uniqueness, its ID.
2. Vocabularies are not yet natively exportable. Three solutions exist:
   1. The taxonomy_export module provides the necessary code rendering logic; the main disadvantage is that, as a contributed module, it would be another dependency.
   2. The exportables project is also supposed to provide this functionality, but as of this morning I couldn't figure out how it works :) In any case, it comes with severe warnings not to use it in production, so I don't think it's ready yet.
   3. Ideally, we'd want to add code export logic to taxonomy.module itself, but again, it may be difficult to get new API functions into the 6.x core (I'm really not sure how that works; haven't ever tried to patch anything that important before.)
3. The taxonomy module doesn't provide a defaults hook.
   1. Again, could easily be fixed with a patch to taxonomy.module.
   2. Could also be fixed by providing the hook as part of another module in the mix; either inside features or taxonomy_export?

Thinking through all this brings a few questions to mind. It seems like there are three possible places where some or all of these patches could be applied:

• taxonomy.module
• contributed helper modules like taxonomy_export or exportables
• the features module itself

I kind of dislike the idea of using a helper module just for features integration…seems like it should be handled either inside the module providing the component, or in the features module itself (as with node, views, etc.).

Anyway, that's my brain dump on that for the moment…I would love to be a part of this conversation, and hopefully contribute some working code before too long…but feedback at this point is critical, since there seem to be too many ways of doing this :)

Let me know what you think!

Thanks,
Adam

@jazzslider: I think that using a helper module is the "Drupal way" - keep everything as modular as possible. I wish you great success with this; I think it could be helpful to many people.

D6 is feature-frozen even for API functions; you can try to get them in D7, but it might be too late even for that. Worth a shot, though. D7 has a different DB abstraction layer, so you'd have to bear that in mind.

Thanks for getting back to me about that; I'm curious, though, as to why the features module hasn't taken the "helper module" approach with the exportables it already implements…e.g., if you look in the includes directory, there are several files adding functionality on behalf of various other modules: content, menu, node, views, etc. (These files even go so far as to add functions in other modules' namespaces: views_* and so on.)

I'm not sure this is really the ideal approach, although it's certainly the simplest. Ideally, modules would all provide their own features hooks (e.g., views_features_api() would live in views, not features), right?

With contributed modules, this ideal is a very real possibility, provided that module maintainers are willing to take the time to review the necessary patches. With core modules, it's pretty much impossible at this point, at least for D6 and D7.

That leaves us with two possibilities: add more components in features/includes, or add helper modules that provide the necessary features hooks in the same way that features/includes files do. My first instinct, since features/includes already exists, is to take care of it there rather than adding another helper module dependency.

The problem, of course, is that taxonomy requires a bit more work than those other modules do, on account of the fact that vocabularies lack machine-readable names. The exportables module provides one possible solution to this, but using a helper module for one kind of component and not using one for the others seems like it would produce a bit of unnecessary unpredictability.

On the other hand, the taxonomy_export module does provide a useful service even without features: it makes it possible to export vocabulary as code for use in install profiles. So it wouldn't necessarily be a great idea to collapse that code into features, because then it couldn't be reused without features.

Eh, it's a rock and a hard place, isn't it? It would all be so much easier if we could just add a couple of new functions to taxonomy.module :)

I'm going to continue looking into this as I get the opportunity; one way or another, I really want to be able to leverage vocabularies in my exported features…they're an extremely important part of how I tend to do my Drupal site building.

Hello!

For the time being, I've gone ahead and uploaded a first-draft patch to the exportables module, which you can find at http://drupal.org/node/544204#comment-2099430 . It has some issues, which are documented there…and it might fit better somewhere else, I dunno. In any case, if you're interested, take a look!

Thanks,
Adam

Hello!

Spent a lot more time looking into this this week, posting issues all over D.o, sometimes intelligently and sometimes not :) Here's the state of features' taxonomy integration as I see it:

1. yhahn's response to me in #592444: Views export doesn't refer to other components by machine-readable names confirms one thing I'd already suspected…wherever possible, it's best to try to integrate the features hooks into the module providing the component.
2. Taxonomy vocabularies in Drupal 7 already have machine-readable names (#549898: Machine readable names for taxonomy terms), so we can look forward to this being a lot easier in D7 :)
3. However, as already discussed, machine-readable vocabulary names don't exist in Drupal 6. At present, the only way to get at that functionality is to use an additional contributed module like exportables.
4. I've submitted a (very beta) patch to exportables (#544204: Integration with features module?) that implements the features hooks on behalf of taxonomy. It works, but it's buggy.

This is mainly just a summary post so that interested parties can see all this activity in the one place they're most likely to look for it …seems sort of difficult to keep the conversation connected when the work and discussion is occurring across several different Drupal components :)

In any case, please provide any feedback you may have …as I've said before, I've got the time and the motivation to do what it takes to get this working, but I want to make sure I don't make any dumb mistakes along the way that could've been avoided with a little communication :)

Thanks!
Adam

subscribe

subscribing

i'm interested in this too

Hello!

For what it's worth, I've been actively working on adding this functionality in the existing exportables module; the patch I referenced earlier (in #544204: Integration with features module?) is already committed to CVS and seems to be working correctly. There are a few issues left to resolve (most notably #598510: exportables_sync() should be tied to enabling/disabling the module providing the default items) before I'd say it's production-ready, but it's definitely a good start.

Ultimately I'd love to see this as a native part of the features module, but unless we can get machine-readable vocabulary names into the Drupal 6 core (they're already available in D7), I don't know that that's likely. There's always going to have to be an extra layer providing the machine names, and exportables is currently our best shot at that.

Please feel free to give it a whirl; it's still very much a development release, but the more eyes we have on it, the better chance we have of getting it stable :)

Thanks!
Adam

subscribing

I can see the code in the "exportables" module for providing "features" integration, however -- How is this planned to actually integrate?

Would it be with "features" having an optional dependency on "exportables" and a new include/features.taxonomy.inc file that implements taxonomy_features_export(), taxonomy_features_export_options(), taxonomy_features_export_render(), etc.. ??

If I knew how to connect the dots from "exportables" to "features" I'd be happy to test integration and maybe hack on it a little bit, but I'm not sure where to start. Please advise.

Thank you!

Never mind my questions! I didn't notice that modules/taxonomy.inc implemented the features hooks.

All I had to do was add a machine readable name to my vocabulary, which I did directly in the database:

  INSERT INTO exportables_machine_names VALUES (1, 'taxonomy_vocabulary', 'pos');

Then add info about it in my features *.info file:

  features[taxonomy_vocabulary][] = "pos"

And update the feature with drush:

  drush features update myfeaturemodule

Everything appears to be in working order. I'm not (yet) including any views or anything that uses this vocabulary, just using it on the content type I'm including.

I really need to get the terms on the vocabulary too, but I'm not sure that is in the scope of the exportables module? I may hack it on there.

FYI, I created a patch to "exportables" that will causes all of a taxonomy's terms to also be exported and included in a feature. You can find it here: #645596: Patch to export taxonomy terms

This issue is also now at play for further taxonomy support: #651084: Patch for special treatment of install hooks -- required for taxonomy integration

Subscribing.

Subscribing.

subscribing..

Subscribing... Is there a reccommended approach to exporting/importing taxonomy and taxonomy terms with Features? Is it to use the exportables module?

What happens if a feature is being developed offline, and it includes a view that references a taxonomy (both the view and the taxonomy are included in the feature). But, presumably the reference on views part will still be referenceing the taxonomy by it's numeric id? So, if you import this feature onto the live site, the taxonomy may be created, the view may be created, but the two might not link together correctly due to the taxonomy having a new numeric ID on the live site?

It seems that there are many people interested in a "best practice" for a connection between Taxonomy and Features.

I decided to test Exportables module which works okay, but there are still some open issues http://drupal.org/node/645596.

And the problem which is described in #23 is not unknown (e.g. see http://drupal.org/node/645596#comment-2593388), but I don't know if there already exists a solution.

What about putting all our knowledge about Taxonomy integration into Features on a "comparison page" where we compare all approaches with pros and cons?

The issue with exportables and taxonomy export is exactly what mrfenton in #23 has said, any newly imported taxonomy will have a new ID and anything built with the taxonomy (views, etc) won't know about it.

Exportables solution has been to map id -> machine name in their own table. This is an OK solution, however I could see there being issues with it. The problem is that then the view's code needs to know about this conversion. Which it doesn't and the problem isn't solved.

My solution has been to reserve IDs for the taxonomy and vocabulary terms i know I am going to use and bump up the auto increment number by 10,000. I have a module built on features and exportables that does this. It's almost ready to be released and will update the thread when it is.

Subscribing.

subscribing

Subscribing.

subscribing

Maybe of interest: I just posted #789556: Support taxonomy vocabularies which focuses on a vocabulary-only export.

Subscribe

subscribe
note to self: dev->staging->production
-- good starting page on exporting taxonomy terms and also see community effort to bring taxonomy terms into features -- no stable solution yet.

Beginnings of Features support here, according to the project page:
http://drupal.org/node/698006

Also, http://drupal.org/project/features_extra provides features support for taxonomy (and other things)

Subscribe

In addition to http://drupal.org/project/features_extra , http://drupal.org/project/taxonomy_export 2.x has an experimental integration with Features.

However, http://drupal.org/project/features_extra says that "It has views support" but at the moment I have not tried it and I can't find how to "edit the vocabulary, give it a "machine name"," as mentioned on http://drupal.org/project/features_extra

To give a machine name, you just have to edit the vocabulary as mentioned on http://drupal.org/project/features_extra
The export and import of the vocabularies have worked with http://drupal.org/project/features_extra However, unfortunately it didn't create the terms inside each vocabulary

It says on the module page that it won't create the terms inside the vocab. To be honest, I think that is the correct behavior anyway. Aren't taxonomy terms content? You don't create all the nodes of a certain nodetype when importing/exporting content types.

Problem is technically you're right, but often terms are used for structure (think of modules like Taxonomy Menu and I have many clients with pre-defined vocabularies that are not intended to be altered frequently). In fact, terms are more frequently structural than not, in my experience. Though I see what you're saying...

@greg.harvey - I actually agree with you, I was just playing the devil. I would definitely be in favor of the ability to bundle terms up with a feature, just as I would be over the moon wiht the ability to bundle nodes up with them too! I often use taxonomy terms for structural purposes, though possibly not the majority of the time.

Can someone confirm the status of this issue relative to #789556: Support taxonomy vocabularies? It's not quite a duplicate.

It seems to me that #789556: Support taxonomy vocabularies seems quite related to this issue.

Hi folks, I've just committed the patch from #789556 and it's as far as I want Features to go into taxonomy territory. I think all the issues have been pretty well discussed above. Let's leave other modules to attempt exporting terms themselves.

Is there a centralized effort to handle exporting terms that's compatible with this new solution, then? I do understand the justification, but before I start off developing my own module to do this, I want to make sure I'm collaborating rather than duplicating.

I assume it would also have to handle machine-names for terms somehow, am I correct?

I've been working on a shared taxonomy module. It works if your databases can talk to each other via array notion for db_url
http://drupal.org/node/18429

Requires a patch for 6.x; 7.x code is in place so no patch will be needed.

Hi! I'm the maintainer of taxonomy_export. I appreciate the interest, but am too busy to get much of this coding done myself. If anyone is interested in getting becoming a maintainer to help clean up the features integration in the 2.x branch, please let me know over here #521706: Taxonomy export features integration.

All the best,

James

Subscribe

Subscribe

Subscribing. Here's a link to the UUID project.

Another way to do this is with the UUID Features Integration module. I've posted a couple of patches (#965450: Add component that exports vocabulary with all its terms and #966510: Add support for related terms and synonyms) which when both applied allow you to import/export whole sets of vocabularies with all hierarchy and relationships intact.

subscribe