This is the second post in my series on install profiles. It covers the anatomy of an install profile and creating .install and .profile files. We create a simple brochure style install profile which is based on the standard D7 profile with a few customizations of my our own.
Yet another key component to the Drupal Platform is the install profile and it's another one that deserves a few posts to cover it adequately. The goal of this series of posts will be to build an install profile capable of creating a basic brochure-style website - more or less what WordPress's core functionality offers (ok, we'll be doing a bit less for this example ;-)).
Drupal 7 install profiles differ quite significantly from Drupal 6 install profiles so a lot of the material covered here won't necessarily apply if you're working on D6 only. There's already a lot of great documentation to help get you started. Drupal.org has an overview of install profiles that's worth taking a read through, for example. The Drupal documentation also covers all of the common hooks that you may want to use in your profile. But the best place, without question, is just reading through the Drupal core profile code (no, I'm not joking). Check out profiles/minimal, and profiles/standard folders that come with Drupal, particularly the .info, .profile, and the .install files.
Over the past couple years Drush has become an essential part of the Drupal site builder's toolkit. I personally use it daily and like a lot of developers now couldn't imagine building a site without it! (Well, I suppose I could imagine it, but I can also imagine building sites in Drupal 4.6, and it's not pretty ;) ).
Drush is one of those areas of Drupal that has been very well documented and I think it would be useful to compile what I feel are some of the more appropriate areas for site builders. There are many awesome webcasts, though I'm personally biased against them due to my forever inconsistent connection speeds while I'm traveling, so don't take it personally if I pass your webcast by :). Most of the existing documentation is written for D6, but fortunately Drush is Drupal version agnostic so all D6 documentation should work almost identically to D7.
Dev -> Stage -> Prod style of workflow for site building
If all you want to use features for is the second option, then this is perfectly acceptable. But when you start re-using features across multiple sites, you'll end up needing to fork the feature across each new site build. While you'll no longer have the overhead of creating a blog feature when doing a new site build, you may wish to add new components to your blog feature at some point. How to you push the updated feature across all sites if you've already forked the feature to accommodate necessary customizations?