2

We run quite a complicated Drupal 6 site with a lot of custom modules which was already migrated from D5. There are a few site administrators and we have had situations where a change in the settings of one module (usually something conflicting with Boost) has caused a problem with the site that is only detected later. We have no way to quickly tell which settings have been changed recently and what their previous values were.

Is there an additional module that hooks into to all variable_set() calls (for example) and logs the old and new values so that we can have an admin view listing all changes over time and which user made the change? It would be great to have an option to add a note to each item to explain why the change was made?

We try and share notes in our wiki on such changes but I think it would be much better if such data was available from inside Drupal itself.

1
  • Just to be clear, I'm not asking as a module developer. I'm looking for a tool/workflow as a site administrator to track changes and be able to undo setting changes if a bad side-effect is later detected.
    – Nic
    Sep 28, 2012 at 9:57

2 Answers 2

1

Blame module sounds like it might fit your needs:

The Blame module is an audit tool that allows the site administrator (or those with appropriate permissions) to see changes that have been made to any form on their Drupal website. The purpose of this module is to provide the ability to quickly identify which user made which changes to which form at a specific time. This includes node forms, contact forms, administrative settings, webforms, etc.

In the past when I've needed to find configuration changes I've grepped access logs for posts to specific forms.

2
  • That's exactly what I was thinking of! Shame is seems to be kinda dead - only 9 sites using it right now. I'll see if I can help with the rewrite...
    – Nic
    Sep 28, 2012 at 14:03
  • I wouldn't worry about that, just try it out. Those stats are just fluff and shouldn't effect your decision on whether or not to use the module.
    – digital
    Sep 30, 2012 at 13:53
1

Here is our workflow.

First of all you code base should use a versioning system as Git or Subversion, doesn't matter which you like or want use, but the main point its to use a versioning system.

Then you should give a look to Features module and all his modules relatives. This will allow you to create a set of module that include standard configuration and etc.

So, mostly popular modules are using either variables or ctools to manage their configuration, for those who sue CTools, Featues will help you export their configuration, for the others you've Strongarm.

I think just with this, you will covers at least 80% of your configuration, for the rest your should either move it to features or use hook_update_N with a module.

Here what is important its that all your configuration must be inside files and committed to the versioning system.

Like that, you will which configuration has been changed and see the historic through the versioning system.

I think the most important part its to move the already existing into Features and force people to use Features when they are doing changes in the configuration.

3
  • Thanks! Will check this out. Features covers both the config values AND the version of each module?
    – Nic
    Sep 28, 2012 at 10:12
  • Features will help your for the config values. For the version of each module and historic, you will use versioning system.
    – yvan
    Sep 28, 2012 at 10:15
  • It's worth mentioning that deploying updated features code isn't always sufficient to actually deploy the change (ie you may need to revert, which you can do in your hook_update_N()).
    – Andy
    Sep 28, 2012 at 14:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.