In the last post I demonstrated creating a very basic install profile in Drupal 7. It was more or less a stripped down version of the standard profile with a few very minor additions.

I've been getting some great comments on my posts and one I wanted to note was from @david regarding the Profiler project. I've not had a chance to use it yet but it looks very promising. The profiler module provides an improved API and tools to vastly simplify what's necessary in writing your install profiles. While I would guess some more complex tasks still require you to use the raw Drupal API, this tool looks like it could give you a huge head start.

So, in the previous post, one of the additions I wanted to make but couldn't, was to create the default client user. The client name and email address will obviously differ on all sites we build. For this we need to add a new step in the install process to allow us to configure the client account prior to it's creation. All of the code from here on out will sit in our .profile file (recall that this is equivalent to a .module file, but for install profiles).

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.

In the previous two posts (Features Part 1: A Simple Feature and Features Part 2: Managing Your Feature) I demonstrated how to build a simple feature. The result is something that's particularly useful for two things:

1. A starting point for new site builds
2. 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?