6

There's no obvious way (that I can see) to isolate a Drupal site's configuration (which is of course all in the database) from its content (which is of course in the same database) when doing any operations on the database.

For instance, it would be very useful to be able to be able to push your configuration changes from your development server to production,

drush sql-sync @dev @prod

and then push only your content back to development from production.

drush sql-sync @prod @dev

Short of going through the database and making a list of tables for each type of data, and writing your own script to dump and import just those tables (an approach which seems kludgey and error-prone), how can this be done?

UPDATE: There doesn't seem to be any way to do exactly what I'm asking how to do. Since both answers were very helpful, however (1st of all because they contain useful information, and secondly because they indirectly confirm that it's not currently possible to do in any practical way) I'm up-voting them and selecting one. I hope that by selecting an answer no one is confused into thinking that what I described is possible. (I've seen such things happen before.)

Improve this question

2 Answers 2

Reset to default
6

There are different ways of passing the configuration data between various environments;

1 - Features

The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically.

It can be used in combination with Strongarm .

2 - Configuration Management

ability to keep track of specific configurations on a Drupal site, provides the ability to move these configurations between different environments (local, dev, qa, prod), and also move configurations between completely different sites (migrate configurations) without the use of modules with all configuration being owned by the site.

Improve this answer
1
  • Features are simply a way to export and import certain data. The big downside is that only SOME of your configurations are exportable. And even if it were a complete solution to the problem it aims to solve, it doesn't actually separate the data, and doesn't give any way to do what I suggested.
    – iconoclast
    Commented Oct 27, 2012 at 17:39
2

Good answer from junedkazi.

I know that this isn't much use right now, but wanted to point out the config management initiative being worked on for D8.

http://groups.drupal.org/build-systems-change-management/cmi

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.