As I mentioned in the last post one of my biggest headaches with Drupal is moving changes from one server to another. I specifically chose pathauto alias settings as an example because the form can be rather large and repetitive to fill out. I'll skip the part about how repeating your steps on this form gets boring, because it was covered in the last post. The focus of this post is to talk about different ways Drake can solve this problem.
Breaking down the Pathauto settings form
The pathauto alias settings form is defined in pathauto.admin.inc. The part that we're most interested in is the very last line of the form definition.
return system_settings_form($form);
This form, like many other core and contrib module defined settings forms, is utilizing a system settings form function to handle its processing. Calling this function on your form adds a submit handler which loops over each of the keys in your form and calls a variable_set on the submitted value. So now, when you click "Save Configuration" the values you entered in get placed in your site's variables table.
Write a drake script to simulate a form submit
One of the things you can do with drush out of the box is set variables by command line. Very simply you could manually log onto each of your servers and run a series of "drush vset foo_var_name bar_var_val" commands. But why do that when you could write a drake script?
$drush drake-file
$drush vim 432412431.drake
vset pathauto_max_length 100
Now all you have to do is execute drush drake on each of your servers and your variable change is executed. Your changes are sequentially executed, can be stored in source control management, and can be handled automatically if your build process was built around drake.
Taking it to the Next Level
It didn't take me very long to be unsatisfied with writing my own drake scripts to set these variables. For starters you have to either dig through the code or look at the form with Firebug to get all the variable names right. You're also probably repeating your work since you'd make your pathauto changes by hand in the admin panel, test them out, and then write a drake script. The other issue that came up has to do with array data. Currently, drush's vset doesn't work well with array data. There is some discussion about how to handle a user inputting array data. So what we're left with is: getting too familiar with form element names, repeating yourself, and only working with simple key/value pairs. Time to give up?
Enter the module side of drush_migrate. In drush_migrate_form_alter I scan the form's submit handlers for the presence of the system settings form submit handler. At this point I can assume that the main goal of this form is to set each of its keys to the site's variables table, which means you can generate a script file automatically that accomplishes the same goal. The form_alter function adds an extra "Export to Drake" button that creates a drake file and writes a series of vset's for your form's keys.
This gets rid of problem 1 and 2, because you are no longer writing form keys by hand, and you are also only making your configuration changes once. The problem with array data still exists. For safe exporting, when the module creates the drake script it serializes each value, regardless of if it is an array or not. When drake processes your scripts, it attempts to unserialize the value. When processing arguments, if the value is serialized we unserialize it. If the value can not be unserialized (i.e. the command name, hand written arguments), it is kept as is. We can now export array data from system setting forms easily, because each line is getting serialized by the drush_migrate module. Exporting your pathauto settings is now as easy as clicking a button. Importing them is as easy as typing a one line command.
Closing
This initial functionality to drush_migrate solves a very small portion of the problems that arise in a multi environment Drupal team. However, utilizing a little Drupal knowledge and the pre existing vset drush command I was able to find a solution that I was happy with. My next goal is to tackle migrating roles and permissions.
