While many people lament Drupal being a product somewhere between a content management framework and a content management system, it’s often in these less than ideal situations that remarkably creative solutions are born. Examples of this are CCK, Views, Features module, and the list could go on. If it weren’t for the painstaking nature of writing SQL in the “Drupal Way”, Earl Miles might have never created the Views module. If it weren’t for the fact that it’s virtually impossible to have a clean dev/staging/QA/prod workflow with Drupal, Development Seed probably wouldn’t have even dreamt of the Features module.

This brings me to install profiles. Those of you who’ve written them before know that things are not as simple as they seem. The system in its current state is not easy to implement. Forced into alternate solutions by the constraints of this system, we’ve come up with a API design for install profiles patterned loosely after Drupal’s theme layer.

“What?”

Yeah, so that doesn’t make much sense does it? Let me try to explain. Drupal’s theme layer functions kind of like a hierarchical visitor pattern. For instance, say you use Zen as your base theme. To create a new sub theme of Zen, in the dot info file of that theme you would write:

There you see the base theme is Zen. You get all the niftyness that Zen includes but then get to modify it and add new things if you’d like. Now if you tweaked out this sub theme and added all sorts of custom specialryness, you could then create another theme and have that theme be a sub-theme of your second theme:

So what if you could do something similar with install profiles? We asked the same thing…and then we tried to answer that question. In the process of building any custom project, you end up repeating many things. For instance, how many Drupal sites have you built that didn’t have Views and CCK installed? While drush does speed up the process of enabling all these modules, you still have to remember to do it every single time. Granted the chances of forgetting to enable Views is slim, but certainly there are other modules in your workflow that you overlook until some point later in the development process when you are asking yourself, “Now why is that not working?”

I know we’ve done that. So we have an install profile internally that loads up a file that sets a foundation for our typical custom site, much the way the Zen sub theme helps you easily create a new sub theme. Here’s are some portions of our ‘basic.info’ file that any custom site starts from:

Basic Info

Modules

So far this is pretty basic, just listing some modules and setting the theme, but here’s other things that go in our file:

Input Formats

Variables

Menus

Pretty cool, huh? So then when we start a custom project for one of our clients, we can just create a new dot info file and base it off of what we’ve already built:

All we’re doing here is just adding a few more modules to what basic already described. The nice thing about this is I can keep honing the basic.info file every time I work on a new custom project.

The install profile that does all this magic isn’t publicly available yet, but if people seem interested, we are easy to persuade. :)