I’ve just rolled the first beta release of Strongarm 2. The basic premise of Strongarm is that if we had a “real” variable system in Drupal, we could provide default values for a specific site. In the absence of such a system, we can use Strongarm and just force certain values. The goal of this is to make it easier to provide a bunch of variable settings with a feature so that things can work properly with no additional configuration on the part of whoever enables a module. For install profiles like Open Atrium and Managing News, this functionality was crucial in creating a solid out of the box experience.

In the new release of Strongarm, we’ve made some substantial changes. We utilize ctools’ export.inc, we’ve only got one mode, we integrate with the Features module, and we don’t have our own drush command anymore. This release gets us a bit closer to the variable system we’d like to have. I’m particularly happy that we’re now using the standard for exporting, ctools, which lets us remove code from Strongarm and at the same time expose variables in a way in which they can be used with the Features module. This means you can use the Features module’s web interface to associate variables to the features you build and capture those alongside all their other components.

Normally in Drupal a module developer provides a default value for a variable, and then a site admin can save a value that overrides that default. It’s a basic system that works for a lot of things. However structurally it has a problem. The developer who built the module really doesn’t know anything about the sites where it’s being used, so the guess they make about a default value is very disconnected from actual use. In addition, some default values aren’t meant to be a ‘for production’ setting. Quite often they’re meant to be a ‘make this module do something out of the box so I don’t get support requests that say “your module doesn’t do anything.”’ An example of such a variable is site_frontpage. In Drupal this defaults to node, which ensures that the front page gets content as soon as some exists, but for many Drupal sites this settings is simply wrong. The idea of Strongarm is to give the site builder a place in the equation - an opportunity to set the site_frontpage to something that makes sense for their site.

The first release of Strongarm served this purpose in a very direct fashion. It essentially hardcoded values. With subsequent releases we introduced “weak arm” mode, where administrators could override some of these values. But having a module like this with two operation modes and a development workflow that was essentially manual left much to be desired. This new version essentially puts a new layer between what the module developer provides and the site administrator overrides. This gives site builders a more elegant way of providing default values for variables that doesn’t prevent site administrators from changing them.

The technical details of the changes in Strongarm all stem from a realization about how we could tell ctools to export values stored in a Drupal core table. The export functionality in ctools looks for some extra information in a table’s schema definition, and once this information is in place ctools does the rest. For the variables table this amounted to six lines of code. You can see in the initial patch how quick and clean a basic implementation was.

In Open Atrium we use the Spaces module to provide different settings for different groups. Based on the new release of Strongarm, we’re experimenting with leveraging the override system in Strongarm to make any variable have a different setting per group. We’re looking at ways to do this invisibly to the code, so that in this experimental git repository, variable_get() does not always mean variable_get().