Quick tip: When using an installation profile for custom projects, don't try to enable your custom modules during installationSunday, 5th May 2013

For all our new Drupal projects at Godel we set up an installation profile for the project with a make file that everyone working on the project can reference.

This workflow means that all anybody needs to start working on the project, either in parallel or through "inheriting" it down the track, is drush, access to github and a database dump from prod.

We also use the Profiler module to enable easy-to-use .info files for our profiles. We don't create new projects from scratch, we have a template profile that contains a bunch of "standard" contrib modules like Views and Transliteration in the make file and "dependencies" in the .info file to enable them all when a site is first installed on the profile.

We use Aegir for local development to simplify managing builds/sites and to help simulate potentially complex site migrations/upgrades. Our internal "standard recipe" for importing existing sites into local Aegir platforms is very similar to the Omega8 recipe. This process involves first installing a new, empty site on the existing platform so that Aegir can prepare sites.php and settings.php as well as additional configuration for your web server before you attempt to import your database dump.

The "install a fresh site" step can fail unexpectedly and be gnarly to debug if the last person to work on the install profile introduced a new dependency to the project and forgot to update the make file. When a site being installed through drush provision is missing a module dependency it will fail with a rather cryptic DRUPAL INSTALL FAILED message and no further information.

Debugging a missing dependency after a site has made it through the initial installation phase (ie. post-importing your db dump) is really easy as all the information about missing dependencies is laid out for you on the "modules" page in the Drupal administration UI.

So, looking at all the modules that are likely to be in a typical custom installation profile they're going to be either core, contrib or a custom module (that's possibly also a Feature module). Of the three, the most likely type of module to introduce new module dependencies mid project is your own custom modules. Actually, it's amazing how easy it is to "recreate" a Feature on deadline and have a new unmet (in the makefile) dependency injected into your site and cause your next deploy to fail.

With all of this in mind I suggest that you do yourself a favour and never make a custom module an installation dependency for new sites installed on your custom installation profile - unless you really know what you're doing and have an amazing QA process in place for this project. Even if you do, do you want your next failed deployment to be easy or difficult to debug?

Syndicate: planet drupal