Proposal
I propose a hook_configuration() API.
For a while now, Drupal has had a hook_install and a hook_uninstall for it's contrib modules. These two hooks allow us to bolt additional code onto the core framework to do almost anything we want. Anything, that is, except define a standard way of coding the configuration options available to a single module. That can change.
There's been a lot of talk at Drupalcon Boston 2008 regarding an idea that modules should be able to access a standardized array of config options that are typically provided to a Site Admin via the admin/build/* or admin/configure/* pages. If contrib modules could have an API and a preset array of arrays that they could use to specify anything from "Should this node that's made by my module be automatically promoted to the front page or not?", and "Should comments be enabled or disabled for this forum post?", and even "If my module wants to make a content type with a $title, $body, and a single additional CCK text field, can I turn off the log_message box (revisions) for these? I'm the only one editing them, after all."
These "contrib config" settings should be sensible defaults, but offer the Site Admins an ability to override or change a module's settings at any point in the post-installation future. There may be a situation where this is unacceptable because it might kill the site, so that has to be taken into account.
Basically, what we're attempting to do here is provide a supporting framework for the eventual Configuration Wizard or Package Manager type application to be used by a module during installation or re-enablement. Existing sites or sites being created by an experienced admin *might* want to shut this feature off, so the first version will need to incorporate either a per-user or a per-role "disable" feature. Of course the $uid->disable_auto_config = TRUE would be an opt-in, so that brand new users and freshly downloaded core packages would offer the automated assistance by default.
How It Should Look
If we give each module a .conf file with a hook_configuration function that houses an array of arrays full of settings for every content type, block, or other (stuff that relates to dependent modules), this is what it might look like:
<?php
function hook_install() {
db_install_schema();
}
function hook_configuration () {
$module_config = array[];
// The API should be able to handle the case of which nodes were created by
// this module's hook_node_info, and also the block>deltas, right?
$module_config['modulename']['node_options'] = array(
// Default Options
'published' => TRUE,
'promoted' => FALSE,
'sticky' => TRUE,
'revisions' => FALSE,
// Multilingual Support (check to see if locale.module is on.)
'multilingual' => 2, // Enabled with translation.
// Attachments (check to see if upload.module is on.)
'attachments' => FALSE,
// Comment Settings (check to see if comment.module is on.)
'default_comments' => 2, // Read & Write.
'default_display' => 1, // Flat list, expanded.
'default_order' => 1, // Oldest first.
'comments_per_page' => 28, // Can this be any integer under 300?
'comment_controls' => 2, // display above and below the comments.
'anon_users' => 2, // This must be checked against permissions table.
'comment_subject' => 1, // Enabled.
'preview_comment' => 0, // Optional.
'form_location' => 1, // Display below posts and/or comments.
);
);
$module_config['modulename']['block_options']['delta-id'] = array(
'block_title' => 'string of text',
'visibility_setings' => 2,
'role-specific_visibility' => array('anonymous' => TRUE, 'authenticated' => FALSE), // If array is empty, block is shown to all roles. (core default)
'page-specific_visibility' => array(),
'preferred_region' => 'sidebar_left',
'secondary_region' => 'content',
'preferred _weight' => -6,
);
}
$module_config['variable_settings'] = array(
// Make some standard settings using variable_get and variable_set,
// but check for user alterations and previous installations first.
'og_default_theme' => 'minnelli-red',
'some_node_setting' => TRUE,
'views_executive_homepage' => 'this.tpl.php',
/// And on and on for anything that inserts data into the variables table.
);
?>
How It Should Work: The top three ideas.
Idea #1 is an auto_configure link next to each enabled contrib module's checkbox on the admin/build/modules page if that module supports hook_configuration(). If the link is clicked, the auto configuration hook is run.
This allows users a finite control over whether to allow that module to set itself up with it's own sensible defaults, or whether not to. The choice is yours, even when turning on and off a module multiple times during a site build. It also takes into account the fact that a certain user may in fact be a pro with $disable_auto_config turned off, but for this one unfamiliar module and just this one time, they want to see what it does and try it out.
Idea #2 (by DmitriG) is a series of additional steps after the admin/build/modules form is submitted. This idea allows for stuff like module dependencies, and in a very sleek manner too. After the form is submitted and the dependencies are checked, the extra steps of configuration are presented to the user, but only if the module has implemented a hook_configuration, the defaults specified are not the same as what exists in the database already (which would indicate that the module has simply been re-enabled), and the user has not opted out of $disable_auto_config.
Idea #3 (by cwgordon) is to intercept the modules admin form, and form_alter something in there that would trigger a configuration wizard if the module supported it, and if it needed to run, and if the $user->uid hadn't opted out of the configuration wizardry. This is a more fluid, seamless way to handle the auto-setting of certain things in the background without any needed user interaction. Unless a conflict is encountered and user input is needed, the process would be imperceptible, as if the module maintainer had taken the time to simple code all this stuff line by line.
There will be a working model of this idea's implementation posted "very soon". [UPDATE] The first version of this idea has been posted to
the Awesome Install project →
as a theoretical example.
I will also be adding a couple of use cases as followup comments. Posibly even by the end of this week. Maybe.
