5

I'm thinking specifically here of layout changes, such as:

  • moving a block around, or
  • when a new block is created and needs to be positioned, and shown or hidden on specific pages.

Currently, when somebody makes layout changes using the admin menus, we all have to go through the same process by hand. My issue with this is that it's time-consuming and error prone.

In an ideal world, I would love to have a system that is able to transfer someone's updated config changes to my local site.

Is this possible?

Improve this question

4 Answers 4

Reset to default
7

At the risk of opening up a whole ugly can of worms on Drupal's current lack of config management, I am just going to point towards the D8 Configuration Management Initiative as the over-arching response to this.

To answer your more specific question about block/layout management, there are a few attempts at addressing this using Features/Features Extra:

Layout with Context or Panels or Display Suite

Better blocks with Boxes or Bean or Bricks

Improve this answer
5
  • Best answer possible, given current state of Drupal, so I'm going to accept it... I like the thought of using features to encapsulate a given configuration and then sharing that between team members - that kind of thing ought to be possible right?
    – Sam Murray-Sutton
    Commented Nov 29, 2011 at 10:41
  • Yes. that is correct.
    – user842
    Commented Nov 29, 2011 at 16:55
  • 2
    I would say (with the risk of starting a flamewar) that all abovementioned "solutions" are incomplete, unstable or get your only so-far. There is simply no working solution, and the reason for that, lies deep in the architecture of Drupal itself. Abovementioned solutions don't fix the problem, they merely supress the symptoms that problem causes. The only solution I found so far is simply "re-do the configuration". "And again in test". "And again on production". "And on every developers setup".
    – berkes
    Commented Dec 12, 2011 at 15:03
  • @berkes: I'd love to hear more explanation as to how and where the above solutions fall short.
    – iconoclast
    Commented Aug 20, 2012 at 21:27
  • 1
    @iconoclast In my experience, the above mentioned solutions can fall short in encapsulating all of the settings that one might make on a dev server, and even minor settings being missed force you to retrace your steps. An example would be field formatter settings being missed, nested fieldsets, etc. These are things I've encountered, at least.
    – Charlie Schliesser
    Commented May 28, 2013 at 3:15
2

You can hardcode any variable (you know, from variable_get()/-set()/-delete()) in your settings.php.

E.g, mentioned in that file, the "site name".

$conf['site_name'] = 'My Drupal site';

This only works for variables, so is of (very) limited use. As @nicoz mentions: a can of worms.

Places where I use this, though:

  • A test.example.com/settings.php: $conf['site_name'] = 'WARNING TEST ENVIRONMENT';
  • Quick, custom modules. It saves you from developing settings-pages that will only be visited once while avoiding harcoded values inside that module.
  • Different API-endpoints, keys, etc in various environments: You want to avoid hitting that production-payment-platform when developing on localhost. Or sending out 10.000 "W000t it works" mails to all your clients. :)

But for sharing with your co-workers this might be too limited.

Improve this answer
1

I can recommend this session from DrupalCon London: Building and Maintaining a Distribution in Drupal 7 with Features.

Improve this answer
1

This is an old question, so I'm posting an update: There's also a Drupal 7 version of the Configuration Management module.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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