Drush Get, Set, and Delete variables - A way to be exact?

This is certainly possible, and is a fine idea. Patches welcome.

i was actually thinking a module which provides a mechanism to set any drupal variable.

Personally, all my settings.php files check for a global.inc , which they include, so i can set variables in one place for all of them (files directories, etc)

well said, adrian. adjusting title.

i also have used a global include file on a multi-site project.

perhaps we go one step further and provide a 'php' command which lets you run any php you want (like devel.module block). in this case, it would be variable_set('maintainence', 1) or somesuch. then again, a dedicated command for maintainence is nice so you don't have to lookup variable names.

Today I wrote some code which implements set a variable (it's not much code at all) and would like to contribute it to drush. The question is whether it should go in drush itself or drush_extras? As far as I know it would be version agnostic.

I've never contributed code to Drupal before, so learning the process for doing so will actually be bigger than the code itself. Can someone give an opinion on which of the 2 projects the code should go in and where to find instructions for submitting it?

We can put that in drush proper. Thanks.

Patch attached to add setvar to core.

patch needs review.

Here's an updated version of the patch with 'variable get' , 'variable set' and 'variable del' commands implemented.

Looks good. But to my eyes, the command listing is getting long. How do we maintain sanity once Contrib starts piling on its commands? Any thoughts?

umm. that's completely unavoidable.

it's a swiss army knife after all =)

I added a --filter option for the help command so lets pile em on! Actually, lets turn this into 1 command with 3 operations.

I am also considering adding support for json as the value , so you can set arrays and the like via the command line.

variable_get also needs to pretty print the output if it's an array and the like.

also need to pick up the difference between 'true' and true (ie: figure out and cast the input string correctly).

100% agree with #13.

Idea - if easy and useful we can borrow some code from devel module.

Question: these variable commands here - do they give me a listing or even better a searchable list of drupal variables?

(If not adding this seems easy with some php and mysql selects from the vars table.)

Comments?

PS Now with update.php invokation and maintanance mode - we are getting closer to the fully automatic updates of core and modules. Some more points from UPGRADE.txt and we are ready... :)

Quote from #16:
" ...
Question: these variable commands here - do they give me a listing or even better a searchable list of drupal variables?

(If not adding this seems easy with some php and mysql selects from the vars table.)
..."

in drush_sm the code to list vars is ready - as well as some CCK and views export ... the maintainer wants to control these with CVS so he needed an export ...

I didn't find this issue until done coding drush variable integration, so this is a new patch, more code than the last one but also I think more useful. I wrote it to give me options when I don't know the exact variable name (essentially searchable as requested in comment 17).

Adrian's points in #14 are still issues somewhat, but I think it's workable as is.

This could be the shizz for avoiding config pages.

@Jody Lynn: I think it would be of interest to allow searching variables containing the string, not only those that startswith(). Think of searching all variables related to "zen" or "file". Even better, it would be awesome to use the % wildcard on demand:

drush vget file
drush vget file%
drush vget %file%
drush vget %file%_%

Note that current code already allows for wildcards as the argument is not cleaned up.

In addition a problem that can't be addressed is that some variables don't exist and a default value is used until they are set, as the maintenance mode variable. So you can't search what's the name of the maintenance mode variable. %offline%? %maintenance%?

Could someone review this and we'll commit. ... I'd love to see the improvements from 14.

Patched and tested #18. Tried, vdel, vset, and vget. Works as expected. Great feature additions. Thanks everyone.

Thanks for the great feature, i have tested the patch and it works for me also, at least vset and vget.
Can anyone tell me what the vset command is doing in detail?
E.g. for putting the site into offline mode, does it only log into the mysql db and sets the site_offline parameter of the variable table?
I'm only asking because someone pointed out some cache problems (maybe with cache_page, memcached) if doing this: http://samat.org/2008/10/31/taking-drupal-site-offline-mysql-and-command...

+++ commands/core/core.drush.inc	9 Aug 2009 21:01:25 -0000
@@ -439,3 +476,139 @@ function drush_core_watchdog_delete($typ
+    drush_die('No variable specified');

use drush_set_error(). this lets the script proceed in case rollback or other stuff is needed. Change later instances of drush_die() as well.

+++ commands/core/core.drush.inc	9 Aug 2009 21:01:25 -0000
@@ -439,3 +476,139 @@ function drush_core_watchdog_delete($typ
+    variable_set($args[0], $value);

data changing operations should be called via drush_op(). that gives you automatic support for the --simulate feature.

+++ commands/core/core.drush.inc	9 Aug 2009 21:01:25 -0000
@@ -439,3 +476,139 @@ function drush_core_watchdog_delete($typ
+    drush_print(dt('!name was set to !value.', array('!name' => $args[0], '!value' => $value)));

confirmation messages should call drush_log() instead of drush_print(). that gets them properly recorded even when called by a remote drush instance.

+++ commands/core/core.drush.inc	9 Aug 2009 21:01:25 -0000
@@ -439,3 +476,139 @@ function drush_core_watchdog_delete($typ
+        variable_set($choice, $value);

again, use drush_op()

+++ commands/core/core.drush.inc	9 Aug 2009 21:01:25 -0000
@@ -439,3 +476,139 @@ function drush_core_watchdog_delete($typ
+        drush_print(dt('!name was set to !value', array('!name' => $choice, '!value' => $value)));

again, use drush_log()

This review is powered by Dreditor.

#18 patch looked the business, but I have been getting infinite looping when trying to set variables in a Drupal 5 environment.

A patch to the #18 variables.patch is attached which escapes the vset while loop when an exact match is found. This might need adjustment for the fuzzy search functionality.

Thanks Moshe

Updated patch with Moshe's changes and added the performance improvement from #24 (it shouldn't need any adjustment)

Tested the vdel, vget and vset and it still works great for me.

I added expanded the names of each command and aliases vget, vset, vdel. Also documented the --yes feature. Finally, moved this all to a new variable.drush.inc in the core folder. Nice and clean.

Committed to HEAD. Thanks all.

Would be great to add some of the features from #14.

looks like the function names are not right for the new variable.drush.inc file

committed. thx ... was a last second untested change by me.

How to use

Vget preprocess_css: "1"
I want to change from 1 to 0 ([347] : preprocess_css -- )

And run
drush -r /var/www/sitios/multidesa -l sitio1.arg vset

output list of variables

And
1)
Enter a number to choose which variable to set.
1
347
preprocess_css was set to [success]
An error occurred at function : drush_variable_variable_set

2)
Enter a number to choose which variable to set.
0
and output
Cancelled
An error occurred at function : drush_variable_variable_set [error]

[error]

Excuse me, could someone explain me how to change the variable preprocess_css eg from 1 to 0

Thank you very much for implementing the truth that saves me a lot of work, this very good drush.

Sorry my inglis.

I apologize for asking to reopen this issue
Thank

you have to pass a variable name and value as arguments to the command. see `drush vset --help` for more detail

i just committed a fix which shows proper errors when you get this wrong

thank you.

drush help vset
Set a variable

Examples:
 drush vset --yes preprocess_css 1         Set the preprocess_css variable to true. Skip confirmation.
 drush vset pr 1                           Choose from a list of variables beginning with "pr" to set to true.

Arguments:
 name                                      The name of a variable or the first few letters of its name.
 value                                     The value to assign to the variable.

Options:
 --yes                                     Skip confirmation if only one variable name matches.

fix for searching, etc.

Removed comment. Comment added to this feature request instead: http://drupal.org/node/664452#comment-3141974

What if I want to manipulate a variable whose name is a prefix for other variables, but without any pattern matching? The context is automated scripting (under Unix), where there's no interactive user to make an informed choice.

I came up with some awkward workarounds.

Background: manipulate variable date_default_timezone:

$ alias dr='drush -r /Applications/MAMP/htdocs/my_site/'

$ dr vget date_default_timezone
date_default_timezone_name: "s:13:"Europe/Zurich";"
date_default_timezone: "i:7200;"

Get:

$ dr vget date_default_timezone | grep date_default_timezone:
date_default_timezone: "i:7200;"

Delete:

$ num=`echo 0 | dr vdel date_default_timezone | perl -ne 'next unless /\[(\d+)\] :\s+date_default_timezone\s*$/; print "$1\n";'`

$ echo $num | dr vdel date_default_timezone
Enter a number to choose which variable to delete.
  [0] : Cancel
  [1] : date_default_timezone
  [2] : date_default_timezone_name
date_default_timezone was deleted.                                                           [success]

Add, if you know the variable doesn't already exist.

$ echo 1 | dr vset -y date_default_timezone 'i:7200;'
Enter a number to choose which variable to set.
  [0] : Cancel
  [1] : date_default_timezone (new variable)
  [2] : date_default_timezone_name
date_default_timezone was set to i:7200;                                                     [success]

Modify, if you know the variable exists. This use-case already works as desired.

$ dr vset -y date_default_timezone 'i:10800;'
date_default_timezone was set to i:10800;.                                                    [success]

I found a better workaround for scripting, though I still suggest a fix to the approach above.

$ dr php-eval 'echo variable_get("date_default_timezone", "UNSET"). "\n";'
7200

# -- Put the value in quotes (eg, "10800") to get type=string
$ dr php-eval 'variable_set("date_default_timezone", 10800);' 
$ dr php-eval 'echo variable_get("date_default_timezone", "UNSET"). "\n";'
10800
 
$ dr php-eval 'variable_del("date_default_timezone");'
$ dr php-eval 'echo variable_get("date_default_timezone", "UNSET"). "\n";'
UNSET

$ dr php-eval 'variable_set("date_default_timezone", 7200);'
$ dr php-eval 'echo variable_get("date_default_timezone", "UNSET"). "\n";'
7200

# -- FYI - What's really in the DB:
$ dr sqlq "SELECT * FROM variable WHERE name='date_default_timezone';"
name	value
date_default_timezone	i:7200;

The new http://drush.ws page mentions option --always-set (which does not appear in other docs). It unconditionally creates new variables, or modifies existing ones.

$ dr vset --always-set date_default_timezone 10800
date_default_timezone was set to 10800.    [success]

$ dr sqlq "SELECT * FROM variable WHERE name LIKE '%date_default_timezone%';"
name	value
date_default_timezone	s:5:"10800";
date_default_timezone_name	s:13:"Europe/Zurich";

Caveats: I don't see how to force the timezone type to be integer rather than string, and this option seems not to work for vget and vdel.