Hi,
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.
Andy
Comment | File | Size | Author |
---|---|---|---|
#21 | uuid_features-965450-21.patch | 699 bytes | tim.plunkett |
#20 | 965450-automatically-add-terms.patch | 1.38 KB | solotandem |
#17 | uuid_features-965450-17.patch | 6.34 KB | tim.plunkett |
#16 | uuid_features-965450-16.patch | 0 bytes | tim.plunkett |
#13 | uuidtest.tar_.gz | 865 bytes | chaps2 |
Comments
Comment #1
chaps2 CreditAttribution: chaps2 commentedHere is the patch.
Comment #2
chaps2 CreditAttribution: chaps2 commentedComment #3
chaps2 CreditAttribution: chaps2 commentedRe-roll of patch in #1 with whitespace diffs removed. Code in CVS has extra whitespace.
Comment #4
chaps2 CreditAttribution: chaps2 commentedFound a bug. Re-roll with correct db_placeholder type.
Comment #5
chaps2 CreditAttribution: chaps2 commentedAdded 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.
Comment #6
aschiwi CreditAttribution: aschiwi commentedThis 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.
Comment #7
chaps2 CreditAttribution: chaps2 commented@aschiwi - do you get any errors?
Comment #8
aschiwi CreditAttribution: aschiwi commentedNo, 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).
Comment #9
tomswiggers CreditAttribution: tomswiggers commentedI can use this also.
When I find the time I will test this.
Thx for the patch!
Comment #10
scottrigby@chaps2. I get 'Segmentation fault' during drush fr while reverting uuid_term. Too late tonight to debug - i'll try to look closer soon
Comment #11
scottrigbyTried a few times with the same results. Interestingly if I revert through features UI it's fine O.o
Comment #12
chaps2 CreditAttribution: chaps2 commented@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.
Comment #13
chaps2 CreditAttribution: chaps2 commented@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...
Comment #14
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedsubscribing
Comment #15
Shadlington CreditAttribution: Shadlington commentedAny chance of a D7 version of this patch?
Comment #16
tim.plunkettFor 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.Comment #17
tim.plunkettOkay here's a patch bigger than 0 bytes.
Comment #18
tim.plunkettStill didn't work, I had to manually do this in devel/php:
Comment #19
Rik42 CreditAttribution: Rik42 commentedAll the patches include
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);
Comment #20
solotandem CreditAttribution: solotandem commentedBased 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.
Comment #21
tim.plunkett#1245582: Restore uuid_features compatibility with uuid is removing the includes/uuid_vocabulary.features.inc file. Here is another approach for this.
Comment #22
tim.plunkettComment #23
audtroutt CreditAttribution: audtroutt commentedThis patch (#21) worked for me when I also applied http://drupal.org/node/1245582#comment-5837264
Comment #24
chaps2 CreditAttribution: chaps2 commentedI 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.
Comment #25
tim.plunkettHm, I don't use the features UI, just drush. But deploy is pretty awesome, that's true.
Comment #26
Hydra CreditAttribution: Hydra commented#21 looks good to me.
#24 is right also :P thx for your consideration!
Comment #27
xjmConfirmed that #21 resolves the issue.
Comment #28
wupperingo CreditAttribution: wupperingo commentedCan import and export terms now, but I'm missing the trail.
Comment #29
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedthis 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.
Comment #30
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedDoes 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?
Comment #31
adamdicarlo CreditAttribution: adamdicarlo commented@SocialNicheGuru:
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[].
Comment #32
lotyrin CreditAttribution: lotyrin commentedI 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.
Comment #33
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI 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.
Comment #34
Mile23+1 on needing this functionality.
Comment #35
Jeffrey C. CreditAttribution: Jeffrey C. commentedCommitted in b7504e4.
Comment #36
saltednutThis was committed wrong. There are htmlspecialchars in the code and your latest alpha release (alpha2) doesn't even install due to parsing errors.
Comment #37
Jeffrey C. CreditAttribution: Jeffrey C. commentedPlease see commit: 1a2d661. Sorry about the hasty fix!