Hi

If you want to be able to export tac_lite settings using the Features module, you might run into the problem, that the vocabulary has a different id on other systems. It would be good to have it use machine_name instead.

I wrote a patch for that. Take a look at it and tell me if you like it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bitkid’s picture

Just to clarify what this does, it changes the use of vocabulary id (vid) to machine name (machine_name). So the 'tac_lite_categories' variable will contain ie. 'categories' instead of '4'. This makes it easy to export and import using the Features module and Strongarm.

To update an existing installation, apply the patch and go to the admin page for tac_lite (/admin/people/access/tac_lite/settings) and set it up again. The patch does not update the settings automatically. When the settings are saved, the machine_name will be used.

dysrama’s picture

Status: Needs review » Reviewed & tested by the community

+1 for this patch, I really would like not having to set up tac_lite manually.
I can confirm the patch applies and works as intended.

Dave Cohen’s picture

Status: Reviewed & tested by the community » Needs work

Didn't even know about machine names. Is that new to D7?

Does this change what's stored in the database? If so, it needs as update hook.

Machine names are only for vocabularies, not for terms, right? And if so, is there any point in doing this?

bitkid’s picture

Hi Dave

The point in doing this, is that when you export your settings to a feature (using the Features module) and then install the feature on a different site, the vid might not be the same, but the machine_name will.

This only has influence on the variables stored with variable_set. Therefore the only thing you need to do, is go to settings and re-setup tac_lite. When it is saved, the machine_name will be used instead of the vid.

If you want to see the changes, do a drush vget tac_lite before and after you save the settings.

Dave Cohen’s picture

OK. I think what I said in #3 still stands.

A patch like this needs a update hook. It not good to ask everyone to re-setup tac_lite.

This will help with vids, but not tids. It makes only a small portion of tac_lite's configuration exportable. It might mislead an admin into thinking their settings were exported and imported, when really only a portion (the vids) were.

gabriel.achille’s picture

Hi guys
The fact is if we base the solution just on the strongarm module it will have limitations : I mean strongarm is "blind" when he is exporting the content of variables. We may need to change the vid and tid referenced in tac_lite settings during the export-import process...
What do you think if we build a features which is based on the uuid module to make the tac_lite settings exportable through features and take care of different vid and tid accross different drupal installations ? To complete the end-to-end solution we may suggest to use the uuid_features module to export the related vocabularies and terms...

Dave Cohen’s picture

It sounds pretty complicated to me. If you can submit a patch, I'd consider it. Does there need to be another module (i.e. tac_lite_uuid.module) to connect these pieces together?

gabriel.achille’s picture

Well... This exportability function will have 2 module requirements : uuid and features. (+ 1 more if you consider a end-to-end export solution : uuid_features : to be able to export the related vocabularies). No UI would be needed because it will integrates with features module. I think it could be better to put that in another module (or more a sub-module of tac_lite ?) otherwise people who don't need this will have to support this complexity too.
It may sound complicated but from my point of view it's a solution for export the tac_lite setting which is relatively consistent with exporting settings features in other drupal modules... But I may have miss something...

Dave Cohen’s picture

Issue tags: +get involved

makes sense. If anyone can put that module together, great!

gabriel.achille’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Assigned: Unassigned » gabriel.achille
Status: Needs work » Needs review
FileSize
4.81 KB

I developed this feature.
a few notices:
- I propose to consider it as a sub-module of tac_lite. But It could be integrated inside tac_lite as well if it's a better idea (Dave ?)
- Actually I developed it for Drupal 6. But it musn't be a big issue to port it on Drupal 7.
- Even if you can technically export the tac_lite settings specific to a user (I did that to cover 100% of tac_lite settings), I wouldn't suggest do so. Because user may be considered more as "content-data" than "configuration-data". And features is designed for configuration export. But that's just a project management consideration.
- README file is include with plenty of information...

And of course: Needs review (Especially, I'm not very familiar with node access rule rebuilding, you may have some issues in seeing imported settings apply immediatly...)

gabriel.achille’s picture

Minor fixes in info file and README.

dysrama’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
FileSize
3.92 KB

I noticed some errors in the originally posted patch, nodes didn't get the correct access realm because _tac_lite_get_terms() returned empty every time.
See new attached patch for fixes.

fastangel’s picture

I think that this patch need to fix also other problem. When you save the settings use tid. I think that should use a method for use name or similar instead tid.

hanoii’s picture

Just re-relloing patch at #12.

humansky’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #14 works for Vocabularies. It would be nice if we can get the same effect for Roles. Use roles machine name, instead of rid when exporting.

GuyPaddock’s picture

One issue I noted with #14 is that it breaks the per-user TAC lite form. It looks like the form default values are still being computed based on vocabulary IDs even though the data is now stored based on machine names.

The attached patch corrects this.

However, I am setting this to NW because there needs to be a schema migration written to update existing settings for TAC Lite so that VIDs are migrated to machine names. Otherwise, this patch breaks existing sites.

GuyPaddock’s picture

One other change to address in this patch: it looks like the patch is using $vids variables to represent machine names now. It appears this was done to minimize how many lines needed to be touched for this patch, but it leads to confusing code that's hard to maintain going forward since what's in those variables is not vocabulary IDs -- it's machine names.