by Angie Byron on June 5, 2009 // Short URL

5-Step Drupal Distributions

Distribution? Eh? What's That?

We all love Drupal because it can do anything from a simple personal blog, to a complex social networking site with all the trimmings, and more! Of course, there's a lot of work that goes into making a really polished Drupal site, not the least of which is lots and lots of configuration: deciding which modules to use, enabling them all (and all of their dependencies), setting up your basic CCK types and views, configuring all of the settings on your site just so, and sometimes adding bits of glue code to make it all flow smoothly.

In version 5, Drupal added Installation Profiles (sometimes also confusingly called distribution profiles) to its list of features. An installation profile is basically nothing more than a list of required modules and a variety of configuration code which gets performed during installation to give Drupal a bit more oomph out of the box.

A "distribution" of Drupal is one or more installation profiles included with Drupal itself and all of the required modules. Distributions can either be offered as a convenience to site builders by bundling together frequently used components, such as Acquia Drupal, or they can be used to offer a version of Drupal specifically targeted to a unique use case, such as Open Publish. Dries has some heavy things to think about for anyone interested in getting into the distribution business, so I'll pause for a moment while you go and read that link.

Back? Great! So you've decided you want to share your ultimate Drupal site for whatever reason, and you want to do it in the fastest way possible. Then this article is for you!

5 steps? How does that work?

The traditional method of creating installation profiles is an awful lot of work. You need to write code for each and every change you make on your site, from creating a CCK type to toggling a checkbox to positioning a block. There are nice helpers like Install Profile API module, but even still, this tends to be really tedious. If you're like most people, you sit down to write an installation profile, take one glance at the developer documentation, then curl into a fetal position and remember all of that really important grouting work that you need to get to.

However, there's one thing that all of these CCK types, checkbox toggles, and block positions have in common: they're all stored in the database. We can use this fact to your advantage, and simply place an installation profile wrapper around a database dump and voila! A Drupal distribution in no time flat.

Step 0: Make a Drupal Site Worth Sharing

Ok, this part we can't actually help you with. But once you get your site to a point where you want to share it with others...

Step 1: Download and extract to the /profiles directory

This zip file contains a .profile file that does one thing and one thing only: imports the contents of a database dump into Drupal during installation. (OK, fine it does a few more things than's commented pretty well, read it! :))

Step 2: Take a database dump and save it as /profiles/dump/db.sql

Use PHPMyAdmin, mysqldump, or whatever other tool you have at your disposal. It's important to note that your distribution will give your users exactly what's in this database dump, so make sure you don't have any sensitive info (such as user accounts, e-mail addresses, etc.) and that you change your admin password to something other than your usual one. I suggest "12345," which is the same combination on my luggage!

Step 3: Change PROFILE_NAME and PROFILE_DESCRIPTION to something else.

There are two constants at the top of the dump.profile file. Edit their values to whatever you'd like.

Step 4: Remove settings.php.

Not a lot of fun to send your database credentials out into the world. Check for any other sensitive files that might be lying around too, like SSL certificate keys, .htpasswd files, and the like.

Step 5: Zip up the Drupal directory.

Zip up the Drupal directory, including your installation profile, the required modules and themes, etc. and you've just made your very own Drupal distribution!


There are some caveats to this approach:

  • Table prefixes are a no-go. The table prefix you use has to match that of the original database dump.
  • The first thing that the installation profile does once Drupal's installed is remove all of the host database's tables. It has to do this or else you run into errors about tables already existing that are also in the dump, or rows that already exist in various required tables. But what that means is you will suffer data loss if you try and run this installation profile on an existing database. Oopsie! ;)

I have some ideas on how some of this could be circumvented; for example, if we required db.sql to have no table prefixes, it'd be fairly trivial to add table prefixing in the part of the code that reads through the dump and executes the queries. It's also possible as we're going through this to gather up a list of tables ahead of time and only delete the contents of /those/ since they will presumably be Drupal tables. I encourage anyone who wants to take this code and futz with it and come up with something more robust to go ahead and do so!

Also note that if you're interested in more robust tools to handle things such as versioning and rollbacks, you may want to check out the Demonstration Site module and its sister project, the Demonstration Install Profile, both of which were drawn upon heavily for the creation of this method. Features looks pretty sweet, too. I just wanted something dead simple with as few steps (and dependencies) as possible, because I am lazy. ;)

Hope it helps!

Angie Byron

Powered by Drupal!




I would not call an install profile which creates the database from a db dump as Drupal "distribution". It is not maintainable at all. You can't improve the distro, it could be only a one time install. You can't create version 2.0, can't distribute a second db dump, that would overwrite the users db..
If something does not work, users will have to make the changes manually, or fully reinstall their site to the new version and lose every custom data..


Brockdin Barr

Cookie Cutting

Hi, This seems like it could save a lot of time if you're building a lot of sites that have similar features, though I guess every 4-6 months or so you may want to "update" your own "distribution" still. If you know you want a WYSIWYG editor, pathauto, cleanurls, seo modules, etc, etc in every site you do, and you know the server you'll be installing it on, then this could be a good way to save a bit of time.


Tj Holowaychuk

I love how Drupal is so far

I love how Drupal is so far behind in terms of distribution, so many using FTP etc, its pretty sad. Take a look at solutions like Capistrano, not mundane zipping/unzipping. Or create a quick bash script that will do all this for you


Salim Lakhani

Or you can use

I don't mean this to be a shameless plug but you can also do this very easily at WebEnabled.... setup a free trial account, provision whatever version of Drupal you want, add whatever modules and themes, configure it just how you like it, and simply "share" the environment privately or publicly. Other users can then just make an exact copy of your environment with modules, themes, and configuration - all under their own URL.


Kevin Millecam

Cool intro! Thanks Angie!

This looks like a cool (and most importantly, simple) way to distribute some of your Drupal dreams.

Sure there are more robust methods, but this one tempts me to dive into the distro world.

Thanks Angie!



Oooo. This article seems to have touched a nerve. ;)

Yeah, I should clarify:

  • This approach is a hack. A big, ugly hack.
  • Everything Adrian, Pasqualle, Damien, and others said about the limitations of this approach are bang-on. Perhaps I should've put the "caveats" section in big, blinking, red marquee text. ;)
  • Read Damien's post for info on the "right" way to do distributions.


For a very specific use case, which is "I just need to get a copy of this site as it is out to people" – for instance, example code files which will never change (by design) – this way is a huge time saver. It's something I had to figure out how to do, so I figured I'd write it up. :)



I did an even more ghetto

I did an even more ghetto solution for rolling out near-identical D5 sites - a database dump, a zipped up site directory, and a handful of shell scripts. It takes just a few minutes to get a "stub" site up. Of course now I need to figure out what to do for D6 sites...



OpenPublish install profile sorely needs a quick fix like this

I agree that there are specific cases where angie's hack is the fastest (and arguably the most efficient) way to get things done. And I can name a very specific case which sorely needs this sort of approach - the Drupal OpenPublish install profile.

Ever since it was released early this year, this opensource application supported by Thomson Reuters is unuseable for the majority of developers/publishers who are on shared hosting. Simply because the way the install profile script is written, it is resource-hungry and does not efficiently run to completion on shared hosting and even some vps systems.

Neither Phase2 Technology who wrote the install profile or Thomson Reuters have come up with any solution so far although their reps involved in the project are personally aware of this problem.

Until a more efficient install profile comes along, the quick fix for this problem is to just put out a sql dump of the database tables of a clean installation for those who wish to roll up their sleeves and manually set up the database for OpenPublish to work on their site.

Anybody care to put out the sql dump of any test site they managed to install cleanly?



Doesnt work with aegir

As the db import is triggered via changing the submit handler for a form, in situations where that form isn't submitted, as is the case with aegir, it doesn't work.

Perhaps the _profile_final() hook might work, anyone managed to get this to work?




Hey Angie
Thanx so much for this - i now finally have my own "aaaah i need all this config thingies everygoddamn time and now i just push a button" install profile

even that its hackish n stuff :P

thanx a bunch!



Thanks for this

Thanks for this Angie,

Coming from joomla where it's a similiar process of db dump and load -> working site !!

I was getting frustrated about the tedious effort to deploy a site with drupal, Reading from all the other posts. ie. convert to code.

At least I now how a no-brainer way to deploy a new site without having to learn the drupal api.

I'll be holding my breath for features, in the meantime, this is great!




Thanks for this

Thanks for this Angie,

Coming from joomla where it's a similiar process of db dump and load -> working site !!

I was getting frustrated about the tedious effort to deploy a site with drupal, Reading from all the other posts. ie. convert to code.

At least I now have a no-brainer way to deploy a new site, without having to learn the drupal api.

I'll be holding my breath for features, in the meantime, this is great!





This works great on its own, but not with aegir.

Anyway this could get modified to work w/ aegir?