I can see this module being hugely useful in wrapping up whole vocabularies with all the versionable, distributable goodness of features.

However for vocabularies of more than a few terms, selecting each term is annoying and quickly becomes impractical. I thought a select all facility might help but that wouldn't work with more than one vocabulary and would still be a UX nightmare for large vocabularies.

What is needed is a component that encapsulates the concept of a vocabulary as a complete collection of terms. In this way, the UX is very simple and clear and the state of the vocabulary as a whole can be determined - e.g. if a term is added to the vocabulary, the state of the component becomes 'overridden' (this is not possible using a combination of uuid_vocabulary and uuid_terms).

I have written a patch that adds a 'Vocabulary with terms' component to uuid_features. It mostly re-uses code from uuid_terms and uuid_vocabularies.


Members fund testing for the Drupal project. Drupal Association Learn more


chaps2’s picture

9.99 KB

Here is the patch.

chaps2’s picture

Status: Active » Needs review
chaps2’s picture

Re-roll of patch in #1 with whitespace diffs removed. Code in CVS has extra whitespace.

chaps2’s picture

Found a bug. Re-roll with correct db_placeholder type.

chaps2’s picture

Added order by statement to ensure terms are exported in a consistent order.

Also added second call to rebuild terms which guarantees the hierarchy will be set up correctly as all parents will have been imported in the first pass.

aschiwi’s picture

This sounds like a good idea but it's not working for me with patch from #5. I get the export, but upon enabling the feature the vocabularies do not get created.

chaps2’s picture

@aschiwi - do you get any errors?

aschiwi’s picture

No, nothing. I did realize I'm on Pressflow, not regular Drupal. I noticed that uuid_features doesn't well in Pressflow. I can export fine, but it won't show on import. Upon activating the same feature in a Drupal installation, all works well (didn't try an export with your patch though).

tomswiggers’s picture

I can use this also.
When I find the time I will test this.

Thx for the patch!

scottrigby’s picture

Status: Needs review » Needs work

@chaps2. I get 'Segmentation fault' during drush fr while reverting uuid_term. Too late tonight to debug - i'll try to look closer soon

scottrigby’s picture

Tried a few times with the same results. Interestingly if I revert through features UI it's fine O.o

chaps2’s picture

@aschiwi - I can't reproduce the problems that you are experiencing. I have created two vanilla installs of Drupal 6.20 with the bare minimum of modules enabled - features, uuid, uuid_features, (one with devel and devel_generate to generate a vocabulary); exported a vocabulary with terms from one and imported into the other with no problems at all.

chaps2’s picture

865 bytes

@scottrigby - I can't reproduce your problem either. Same set-up as above, feature reverts without error both via the UI and drush fr. Version of uuid_features is the 6.x-1.x-dev version from git with just patch #5 applied and nothing else. My test feature contains just one single "vocabulary with terms" component. In fact I'll upload it and you could try it for yourself...

SocialNicheGuru’s picture


Shadlington’s picture

Any chance of a D7 version of this patch?

tim.plunkett’s picture

Status: Needs work » Needs review
0 bytes

For some reason, features_include_defaults() isn't being called properly. Adding a call to it fixes the problem, but there is likely something else wrong here.

tim.plunkett’s picture

Okay here's a patch bigger than 0 bytes.

tim.plunkett’s picture

Status: Needs review » Needs work

Still didn't work, I had to manually do this in devel/php:

Rik42’s picture

All the patches include

 function uuid_term_features_rebuild($module) {
   $terms = module_invoke($module, 'uuid_features_default_terms');
+  return uuid_term_features_rebuild($terms);

This will throw a Fatal error: Maximum function nesting level of 'X' reached, aborting!
Last line should be return uuid_term_features_rebuild_terms($terms);

solotandem’s picture

Status: Needs work » Needs review
1.38 KB

Based on a quick review of patches above, it seems they are trying to implement a separate "vocabulary with terms" item. I can't imagine why you would want to export the vocabulary and not the terms. The attached patch implements that simple design. It automatically adds the terms as a result of adding the vocabulary. This feels the same as adding a content type and automatically getting all the fields.

tim.plunkett’s picture

699 bytes

#1245582: Restore uuid_features compatibility with uuid is removing the includes/uuid_vocabulary.features.inc file. Here is another approach for this.

tim.plunkett’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
audtroutt’s picture

This patch (#21) worked for me when I also applied http://drupal.org/node/1245582#comment-5837264

chaps2’s picture

I haven't tried the patches in #20 and #21 but if they add all the vocabulary terms as dependencies the features UI just will not cope with large vocabularies. I specifically avoided that approach because I wrote the original patch for vocabularies with thousands of terms. But it's been a while since then so take this comment with a pinch pf salt.

I used the D7 deploy module recently and the deployment plan approach taken there is much better suited to content: http://drupal.org/node/1406136.

tim.plunkett’s picture

Hm, I don't use the features UI, just drush. But deploy is pretty awesome, that's true.

Hydra’s picture

Status: Needs review » Reviewed & tested by the community

#21 looks good to me.

#24 is right also :P thx for your consideration!

xjm’s picture

Title: Add component that exports vocabulary with all it's terms » Add component that exports vocabulary with all its terms

Confirmed that #21 resolves the issue.

wupperingo’s picture

Assigned: Unassigned » wupperingo

Can import and export terms now, but I'm missing the trail.

SocialNicheGuru’s picture

this does not seem to work anymore. has anyone else gotten it to work?

Ahhhh - you can only export one vocabulary at a time with terms.

SocialNicheGuru’s picture

Status: Reviewed & tested by the community » Needs work

Does not work for large vocabularies
I just tried the patch
it adds the uuid_terms to the .info file which is stored in the db system table
There is an upper limit for the size of this file
(if someone can tell me how to change this limit, I'm all ears)

Does storing large vocabs in the .info file bloat the system table?

I had a huge vocabulary which created a long list of uuids added to the .info file
I got a WSOD:
PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'info' at row 1: UPDATE {system} SET info=:db_update_placeholder_0 WHERE (filename

Here is how I resolved it:
1. Created a .inc file i.e. module_name.inc
2. I moved all the "features[uuid_term][]" lines from .info to the new module_name.inc
3. added files[] = module_name.inc to the .info file

Is there anyway to include this in a new fix?

adamdicarlo’s picture


What you've done is the same as just deleting all the "features[uuid_term][]" lines from the .info. files[] does not include extra .info data - I don't believe there's any mechanism for that.

files[] has been fairly widely misunderstood. Its only purpose is to tell the class autoloader where to find PHP classes. That's it—files that aren't PHP or do not contain class definitions should not be listed with files[].

lotyrin’s picture

Status: Needs work » Reviewed & tested by the community

I can't see any solution to #30 within the scope of this patch, it seems like an expected consequence of using features for a large number of feature components (uuid_term just makes it easier to create a very large number of components).

Features could look to solve this by listing feature components outside .info files, or core could look to change its schema, but the limit isn't part of this issue.

SocialNicheGuru’s picture

I have no problem with it creating a large number of components.

then maybe on the project page saying that if you have large vocabularies then you will not be able to create a feature from it.

The issue is that there is a finite size of the .info file that is in the system table.

If you have a large number of uuid_terms then you will reach that limit and will not be able to enable the feature.

Thus some warning should be given to the user about this so that they will know what to expect.

Mile23’s picture

+1 on needing this functionality.

Jeffrey C.’s picture

Status: Reviewed & tested by the community » Fixed

Committed in b7504e4.

brantwynn’s picture

Status: Fixed » Needs work

This was committed wrong. There are htmlspecialchars in the code and your latest alpha release (alpha2) doesn't even install due to parsing errors.

+ * Implements hook_features_pipe_COMPONENT_alter().
+ *
+ * When exporting a vocabulary, include its terms.
+ */
+function uuid_features_features_pipe_taxonomy_alter(&$pipe, $data, $export) {
+  if ($vocab = taxonomy_vocabulary_machine_name_load($data)) {
+    foreach (taxonomy_get_tree($vocab->vid) as $term) {
+      uuid_term_features_get_dependencies($export, $term->uuid);
+    }
+    $pipe['uuid_term'] = $export['features']['uuid_term'];
+  }
Jeffrey C.’s picture

Status: Needs work » Fixed

Please see commit: 1a2d661. Sorry about the hasty fix!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.