Variable export by module

I just came across this and just created a module to do something related to this, http://drupal.org/project/variable_dump. Rather than trying to figure out what variables go with which module I provide a form where you can search for variables by a pattern, like looking for all variables that start with a specific module name. It will then create an export that you can copy and paste into an install profile or .install file. By using patterns, you can get very refined, like looking for variables that end with a specific content type name or start with something like 'content_extra_fields' (the weights that CCK sets for extra fields on various content types).

I think (or hope) that most modules are good citizens, creating variables that are prefixed with the module name to make them easy to find and organize.

FYI, our particular itch in this realm was to ensure certain variables were set (similar to how some people use settings.php based global $conf overrides. We cooked up strongarm which allows you to enforce variable values through a hook. Along the way, we ended up writing code similar in concept to variable_scan but preemptive (it simply attempts to mark any form fields that might correspond to strongarm'd variables), and drush commands for some of what variable_dump provides a UI for.

Interestingly enough, a prototype strongarm-features integration turned out to be rather undesirable -- variables don't always act like other modular components. For example, some variables like book_allowed_types you'd want multiple features to contribute to (e.g. feature A and feature B both provide separate content types that should be book enabled).

It would definitely be a good idea to join forces on this front and start to collect experiences and ideas for improving the variable system to handle these sorts of problems.

Yeah, my particular itch was to have a way to dump the current variables out of a site in a format that makes it easy to add them to install scripts. And I wanted to do it selectively, only values with a certain prefix or whatever. I didn't always even want all variables that a module creates, sometimes I only want some of them. For instance, CCK creates a variable to set form element weights that I like to export in sites with lots of content types as an easy way to replicate the form layout in another existing site that shares the same content types.

But importing variables has lots of other issues, as you noted above. I'm mostly focused on the cut and paste application where you can decide what you want to use. Trying to automate that would be very tricky :)

Nice concept. Looking at your code, I do see a possible issue: You look at modules that implement hook_menu. There are module with add-on modules that don't need a hook_menu, yet still create variables (even with system_settings_form) that eventually need to be deleted on uninstall.

first of all, subscribing.

secondly, I think variables support are a invalueable addition to features, as this allows you to create features where everything is already set ot of the box.

thirdly, i'm even happy with an first implementation that requires me to hardcode the variable name somewhere (.info?) and only works with that. cycles.

I'm considering to abandon my http://drupal.org/project/drush_sm in favor of features module but fear the same variables itch.

drush sm export variables is able to export a subset into ie version control. And with drush sm report variables there is also a kinda diff report.

I'm willing to create a patch as #5 suggest because I think features is a way better concept and is drush capable. See also the documentation http://drupal.org/node/580026 ;)

Hmm ... I think I need some more study to grasp better what I should program. Here are my two pennies:

1. I created a file called features/includes/features.variable.inc because I'm integrating variables into features. But it's not called somehow. I guess due to variable_features_api misunderstanding. So there are no options at all.

2. I thought I map the variable through the module name given but guess that's the features module name. Variables should come from the dependencies of the feature module.

I attach my file but it is no patch at all. I hope some can help me 10 steps forward :p

I think actually the variables should go together with the dependencies as they go along with modules.

Your file won't be included because of the way features_include() works

It first looks for actual modules which implement the features_api hook. This uses module_implements() so your include wouldn't be picked up here.
It then iterates an array containing a list of modules that features itself provides support for. 'variable' won't be in this array yet so it won't be picked up here either.
If you did add 'variable' to the array the include still wouldn't be picked up since the modules referred in the array to must actually exist.

Subscribing

What I tried to accomplish was a similar approach as 'dependencies' which are also not represented by a module implementing a features hook. That's why I said "variables should go with dependencies" but I hope to find some time to retry.

So my effort was not in writing a module implementing features hooks. Not sure whether this explanation helps ;)

You're right. Core is terrible at that. Some I suspect is legacy and some is just laziness. I don't see D7 getting much better.

subscribing

http://drupal.org/project/strongarm

I'll be focusing my efforts on Strongarm 2 which provides variable exports via CTools export integration with the Drupal core variable table. CTools also gets us rudimentary Features integration for free.

Once a beta or stable of Strongarm 2 is out I think it will be appropriate to write delegation of variable exporting into the features.node.inc.

I took a stab at building a module that just make all variables available for setting. I figure we can figure out how those should be presented (figuring out which modules use them and such) later. But I needed something that would include variable settings in a feature.

It simple implements a hook_fe_feature_default_set that returns an associative array of variable name values. and then implements a hook_enable (which requires the patch from this tread http://drupal.org/node/651084) which runs through the hook_fe_feature default_set array and executes variable_set calls.

I would like to put it out as a module, but want to post here to see if I should take a different path.

@e2thex: Have you looked at strongarm 2? I think it already handles the export/import/synchronisation of variables using features pretty well...

@mrfelton,

well I drush dl strongarm when I was looking at it so I only got the v 1 release, so I missed the goodness.

I now see that it does add the variable export ( funny thing this morning I change the module I had written to just implement a hook_schema_alter very similar to the one in strongarm 2)

Do you think there would be value in removing the hook_schema_alter to its own module, it seems that it adds alot of functionality on its own. Also if other modules want to implement something similar but different from strongarm (or just don't want to use it more robust features) they can not implement the same hook with out causing needless conflict with strongarm.

Subscribing.

subscribah

Closing, Strongarm 2 now provides features integration.