Some suggestions
public
group: Distribution profiles
Sheldon Rampton - Sun, 2007-07-29 19:28
I just tried out Drupal's installation profile feature for the first time this week and think it has a lot of potential. Using the Install Profile API and Profile Wizard, I was able to create a customized .profile in just a few hours. In the process, the following ideas occurred to me for ways that the installation profile system could be improved further:
- Right now the install_select_profile_form function is only designed to support providing a list of installation profiles from which to choose at the moment of installation. It would be a good idea to provide some support for selecting custom values within each installation profile. As an example, the profile I just created is designed to configure a type of Drupal site that I am calling a "SourceWatch partner," with modules enabled and configured to provide some integration features with my Mediawiki-powered website, Sourcewatch.org. By changing a couple of values in the installation profile, it could also be used to provide similar integration with other Mediawiki sites, such as Wikipedia. People ought to be able to make that sort of change without having to create an entire separate installation profile just to change a few values. I think this could be done by just adding a fieldset under the radio button for selecting each profile, whose values are then passed to hook_profile_final.
- At present there are only a few installation profiles available for download. If more are created, there are going to be some namespace collision problems. To avoid this, installation profiles should be required to follow the same naming conventions that apply to modules. Here are some examples of ways this isn't happening at present:
- The "conference organizing" profile is a file named conference_organizing.profile, but it appears within a directory named "cod". The directory name ought to be the same full name as the name of the profile itself, "conference_organizing".
- The "drupal_wiki" profile appears within a directory that is also named "drupal_wiki" (which is good), but it contains a function named "_menu_disable_item" (which is bad). That function should be renamed either "drupal_wiki_menu_disable_item" or "_drupal_wiki_menu_disable_item".
- Finally: A lot of the work within an installation profile consists of configuring individual module settings. If the number of installation profiles takes off, I think people are going to want to start borrowing from each other's code. (For example, the sourcewatch_partner.profile that I just created borrows significantly from drupal_wiki.profile.) To make borrowing code as easy as possible, I think it would be good to encourage the practice of putting the code that configures each module inside a separate function, e.g., "sourcewatch_partner_akismet_configure", "sourcewatch_partner_fivestar_configure", etc.
Sitewide tags: distributions · install profiles
For #1, that's a core Drupal
For #1, that's a core Drupal change. Very few folks have dug into wizard-izing the core install profile stuff, but install time variables and options definitely need to be made possible.
Configuring functions for modules: right now, everything is in crud.inc. Likely, we'll want to include additional module configurations as needed in an extensible way, which probably means a modules folder, with something like akismet.inc.
The drupal_wiki is probably not a great example. There are lots of helper functions in there. The menu disable one is one that you'll find in abstracted form directly in crud.inc. Ideally, all of these will eventually be available directly from core Drupal. In the mean time....crud.inc.
It's actually quite hard to re-use code between install profiles right now. We need a way to break chunks of configuration down into smaller pieces. The best I've come up with is, again, include files. One example being a set of fully configured TinyMCE profiles (which are a pain to create, and I generally don't really want to change them).
Thanks for the feedback!
Drupal_wiki was useful for me
I don't know why you think drupal_wiki was not a great example. Right now there are only a handful of installation profiles in Drupal contrib. I looked at them all, drupal_wiki was the best of the bunch from my perspective. For one thing, its implementation of hook_profile_final at least "broke chunks of configuration down into smaller pieces" by putting comments at the beginning of blocks.
Creating a separate configure function for each module being configured by an installation profile would also help break things down into smaller pieces. When the Profile Wizard creates its profile_final function, a big part of what it does is dump values from the variables table into variable_set function calls. Since most of the variables in the variables table are named after the modules that created them (e.g., "pathauto_blog_applytofeeds"), it would be easy for the Profile Wizard to compare the variable names against the list of enabled module and break them out into separate function, so that all the variables beginning with "pathauto" would go into a function named _pathauto_configure, which is in turn called by _profile_final.
This would in turn make it easier for installation profiles to reuse the code from other installation profiles, either by copying the _pathauto_configure function or by simply invoking them. For example, if the pathauto configuration in was in a function named drupal_wiki_pathauto_configure, someone else could simply copy the function into their own profile file, rename it to myprofile_pathauto_configure. Or, if they don't have any changes that they want to make, they'd simply call drupal_wiki_pathauto_configure. (There are multiple ways that an individual module can be configured, but some of those may be useful for more than one installation profile.)
Anyway, thanks for the work on crud.inc. I've written a function for enabling and disabling blocks that I think could be added to crud. I'll submit it over on the Install Profile API's project page.
| Sheldon Rampton
| Research director, Center for Media & Democracy
| http://www.prwatch.org
Vehement agreement
You misunderstood me: the drupal_wiki is a great example of a well built install profile. The menu example I mention because it's specifically something that I abstracted into crud.inc ... rather than build it over and over again. I actually have taken drupal_wiki and re-written it to use crud.inc -- much smaller and easier. Reminds me I have to post that as a patch....
I now understand better what you meant by bundling into functions. I was saying the same thing, except I am more of a fan of cut and paste. e.g. the Bryght basic profile just has sections that are well commented, so you can pick and choose what you need. Beyond that, I think pathauto_configure.inc is easier than wrapping it in yet another function.
I saw your block post: thanks, I need to spend some quality time and integrate some of these items.
I actually did some work on #1...
Now in 6, thanks to yours truly, you can have an profilename_form_alter to alter the form. Easy!