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 dump.zip 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 that...it'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!