Strongarm/Features use cases uncovered

firebus's picture

I'm launching my first project that uses Features heavily, and I've run into some of the limitations discussed in this post by Bill at Funny Monkey.

Bill talks about the difficulties in deploying multiple sites from a set of Features, and then keeping those sites in sync with the Feature as it evolves, and how that process is incompatible with Drupal's goal of making it possible for non-technical content admins to do more things.

A similar set of problems arise when you are using Features to keep dev/stage/live instances of the same site in sync.

We're using drush to sync code from dev->stage->live and to sync content from stage->live and stage->dev (the Pantheon model).

There are some variables that you'd like to be set differently on dev, stage, and live (e.g. performance/cache settings). We solved this by creating different Features/Strongarm modules for each instance.

There's an additional Feature that tracks shared variables.

If a content admin changes a variable that's covered by the shared feature module, they probably want the change to propagate to the live server.

If they change a variable that's covered by the instance-specific feature module, they probably don't want it to propagate.

Unfortunately, we can't cover both use cases at the same time. If the variable table is part of the content push, then configuration changes will be pushed and strongarm will be overridden. If the variable table is excluded, then configuration changes will not be pushed.

Furthermore, there's no way for the admin to know that a particular setting is Strongarmed, so it's easy for a content admin to unwittingly break things.

I'd like to see some new features in Strongarm to help handle things a little better. These might be applicable ot other Features as well.

1. Some kind of UI change on settings forms to show which variables are strongarmed.

2. Locked variables. It should be possible to "lock" a variable with Strongarm so that it can't be changed through the UI. Frustrating for the content admin, but at least it will reduce surprises. Maybe this could be a suggestion (a second click is required to unlock the setting before changing it?).

3. Local overrides. When a setting is strongarmed, it is removed from the variable table. If the setting is later overriden, it returns to the variable table. If the Strongarm Feature is reverted, the setting is again removed from the variable table.

If there was a way to override a strongarmed setting without affecting the variable table (perhaps via a separate strongarm_variable table?) it would be possible to stage the variable table without staging overridden settings (you'd exclude the strongarm_variable table instead).

If it was possible to restrict a setting to being overridden locally, all possible content staging use cases could be fulfilled.


Comments

Variables in settings.php

Environment specific variables can be set in settings.php, and they won't be overriden by strongarm nor admin forms.

As for admin form locking, I'm sure it can be easily done in a contributed module. If you actually build it, please share.


A Few Responses

There are some variables that you'd like to be set differently on dev, stage, and live (e.g. performance/cache settings). We solved this by creating different Features/Strongarm modules for each instance.
We created the Environment module in part to facilitate this. With any kind of environment status available to Drupal, you can use hook_strongarm_alter() to change the values. Just be sure to revert your codebase when needing to toggle status.

1. Some kind of UI change on settings forms to show which variables are strongarmed.
Interesting status on this. Until recently, Strongarmed variables were loaded or pulled from cache on every page load, so conceivably you could check every form element against the array of strongarm items and tweak theme accordingly. However, Strongarm now pushes those variables into the database on revert, so theming the form would be an additional performance penalty. Could still be done.

2. Locked variables.
This was Strongarm 1. Blocking administrators was deemed the worse course most of the time.

In general, a heavily Features-centric site has already overlaid a lot of configuration with precooked use cases. The generic module forms are always going to have some degree of conflict between the use cases laid out by Features and the power of the modules themselves. To that end, we are building out a system to facilitate building a dedicated admin form for your day to day, slightly less privileged site administrator.


firebus's picture

Environment

Thanks for the comment!

Environment looks interesting!

From a really brief look, it looks like you're storing the current environment in the variables table. So a staging plan involving drush sql-sync would need to exclude the variable table.

This means that there's no way for a content admin to change any configuration on the staging instance and push it live.

But maybe the current environment could be set in settings.php instead (settings.php overrides the variable table, right?)

If environment hooks are updated in code, is there any way to re-run the hook via drush? That could also get complicated if hooks are not idempotent...


Powered by Drupal - Design by Artinet - Amazon Affiliate