Configuring Drupal modules from within another module_问答_开发者

When I create a new Drupal site I usually end up with at least one custom module and several community contributed modules. To get the site working as it should, many configuration values need to be set on the various modules. This makes deployment onto a fresh Drupal instance painstaking and error-prone.

I would like to give my custom module the ability to configure all the other modules. Either on install or on the click of a button on my custom module's administration page,开发者_开发百科 all the necessary configuration values on the other modules would be programmatically set.

How would I best go about doing this?

AFAIK, there's no way to achieve what you mean easily. I tend to put as much as I can in hook_update_N() implementations and do frequent DB synchronisations as described in my answer to this question. However that does not work when you already have a live server with which you will have to merge data.

To that purpose, I use various tools according to the need. No one is perfect, but here's however a small collection of my favorite ones:

Features. This is a new concept and a new module. The idea is pretty awesome: it allows you to define a set of configuration/modules/settings and to export them as a feature. This feature will then be installed as if it were a module on the target site. This module does not export every possible setting, but it does however do a good job with the modules that need the hardest configuration, as CCK, Views, ImageCache and others... You can see a screencast demo (~10 mins) here.
Backup and migrate. This is a more radical approach: it simply dump and rebuild the entire database on a target system. It is good only if you need to overwrite the target system completely.
Node export. This allows to export (and import) nodes from a drupal installation to another one. It supports bulk operations but - unluckily - it does not support the migration of attached files and images.
Deploy. Because of the limitations of node export I once looked into using this module (still in development). I finally did not, and preferred to do a merge of the production and staging databases, but the concept seems very valid, as it allows to import/export complex data type via SOAP.
Taxonomy import/export. I suppose the name is self-explanatory. It uses files to achieve the tasks (XML or CSV).
Installation profiles (suggested by ctford) are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles. The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.

Finally, you can find a collection of tools for importing/exporting data here.

HTH!

have you looked at the "features" module? it is a new paradigm introduced as part of the open atrium distribution but also available as a stand-alone module. from their description:

"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."

http://drupal.org/project/features

Installation profiles are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles.

The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.

I know what you mean, it's a pain to set all modules up.

I'm sure you can investigate all 3rd party modules to see how configuration takes place and mimic that in your custom module, but I'd advise you against that...

The problem is that modules may change the way they store their settings from one revision to another, so whenever you update to a new version of any module you should do some reverse-engineering to see if your 'ultimate-one-click-configuration module' still works ok - which, if you ask me, is even more painful than manually configuring all modules for each project.

Just relax, take it easy, and enjoy Drupal :)

As the initialization is only required when Drupal is installed, I would think that a installation profile is the better solution; to keep a module that is not anymore used once that the installation is configured seems a little excessive, IMO.

Changing the installation profile used from a site, and make the new installation profile run its installation code isn't something that Drupal allows out-of-the-box. I would create a custom installation profile before creating the sites I need, and only for the features I know all the sites will share. For the other features, I would create separate custom modules I can later install, and eventually uninstall when the features they implement aren't anymore necessary.