Last updated July 24, 2012. Created by nedjo on July 24, 2012.
Log in to edit this page.

Specific vs. general vocabularies

Some taxonomies will be closely linked to a particular piece of functionality. An example is a location type. This vocabulary is relevant only to locations. Therefore, it's appropriately added to a location-focused feature, Debut Location, which might also provide a location node type. Any other location-related feature that might require a location type vocabulary can reasonably be expected to require Debut Location anyway, so we're not adding a new dependency.

However, other vocabularies are broadly applicable. Consider tags and dependencies.

By default, Features will auto-detect a tags vocabulary and add it to any feature that includes a taxonomy term field that references it. So, if you're creating an article feature and include a tags field, Features will add the tags vocabulary to your feature. Now any other feature you build that also uses a tags field will depend on your article feature--even if it has nothing to do with articles.

But if you pull the tags vocabulary into a separate feature, now every feature with a tags field will require that new feature. And - even more problematic - Debut features will conflict with any other feature that provides a tags vocabulary, since no two features may provide the same component.

So special handling is needed for broadly applicable vocabularies to avoid unwanted dependencies.

Adding a tags vocabulary

The following approach should be taken with any Debut feature using tags, and can also be followed for any other general-purpose vocabulary.

To avoid having to require another feature, the Tags vocabulary is created in each feature's .install file, as is done e.g. in the Media gallery module. Here's an example from Debut Article's .install file:

<?php
/**
* Implements hook_install().
*/
function debut_article_install() {
 
// Ensure the tags vocabulary is present.
 
_debut_article_ensure_vocabulary_tags();
}
/**
* Make sure the 'tags' vocabulary exists.
*
* Cribbed from media_gallery.install.
*/
function _debut_article_ensure_vocabulary_tags() {
 
$t = get_t();
 
// Make sure the 'tags' vocabulary exists.
 
$vocabulary = taxonomy_vocabulary_machine_name_load('tags');
  if (!
$vocabulary) {
   
$description = $t('Use tags to group articles on similar topics into categories.');
   
$help = $t('Enter a comma-separated list of words to describe your content.');
   
$vocabulary = (object) array(
     
'name' => $t('Tags'),
     
'description' => $description,
     
'machine_name' => 'tags',
     
'help' => $help,
    );
   
taxonomy_vocabulary_save($vocabulary);
  }
}
?>

Then in the feature's .module file, add some special handling to prevent the vocabulary from being auto-detected:

<?php
/**
* Implements hook_features_export_alter().
*
* Remove the tags vocabulary, which we create at install time so as not to
* create a dependency on a feature providing the vocabulary.
*/
function debut_article_features_export_alter(&$export, $module_name) {
  if (
$module_name == 'debut_article' && isset($export['features']['taxonomy']) && isset($export['features']['taxonomy']['tags'])) {
    unset(
$export['features']['taxonomy']['tags']);
  }
}
?>

If the vocabulary has already been added to your feature, delete it from the feature's .features.taxonomy.inc file (or delete that whole file, if it's the only vocabulary being added) and delete the reference to the vocabulary in the .info file.

Now, when you regenerate a feature, it won't include the tags vocabulary.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.