In my last blog post I outlined how to use per project installation profiles. If you read that post and want to use installation profiles to take advantage of site wide content changes and centralised dependency management, this post will show you how to do it quickly and easily.
The easiest way to switch installation profiles is using the command line with drush. The following command will do it for you:
$ drush vset --exact -y install_profile my_profile
An alternative way of doing this is by directly manipulating the database. You can run the following SQL on your Drupal database to switch installation profiles:
UPDATE variable SET value = 'my_profile' WHERE name = 'install_profile'; -- Clear the cache using MySQL only syntax, when DB caching is used. TRUNCATE cache;
Before you switch installation profiles, you should check that you have all the required modules enabled in your site. If you don't have all of the modules required by the new installation profile enabled in your site, your are likely to have issues. The best way to ensure you have all the dependencies enabled is to run the following one liner:
drush en $(grep dependencies /path/to/my-site/profiles/my_profile/my_profile.info | sed -n 's/dependencies\[\]=\(.*\)/\1/p')
Even though it is pretty easy to switch installation profiles I would recommend starting your project with a project specific installation profile.
Edit: Jaime Schmidt picked up a missing step in the instructions above. You need to enable the installation profile in the system table. The easiest way to do that is with this drush one liner:
echo UPDATE system SET schema_version = 0 WHERE name = 'my_profile' | drush sqlc && drush cc all
Further Edit: Marji Cermak picked up a typo in the dependencies one liner. It is one word I use a lot and always misspell.
Drush make is a wonderful tool for constructing Drupal platforms. A lot of Drupal developers are used to adding a list of modules, a few libraries and theme or 2 then running drush make to build their platform. It all seems pretty easy. What if I told you module developers could make things even easier for site builders?
Some contrib modules depend on third party libraries, and due to various reasons they can't always be stored in git repositories on drupal.org and included in the module release. To solve this problem module developers can include a .make file for their module. Drush recursively processes make files, so the module make file would be processed once found by drush make.
A good example of where this could be useful is the SMTP module, which depends on the LGPL licensed PHPMailer library. The module also requires a patch to be applied to the library, which drush make can apply for us. The following .make file could be included in the SMTP module as smtp.make:
core = 6.x api = 2 libraries[phpmailer][download][type] = "get" libraries[phpmailer][download][url] = "http://downloads.sourceforge.net/project/phpmailer/phpmailer%20for%20php5_6/Previous%20Versions/2.2.1/phpMailer_v2.2.1_.tar.gz" libraries[phpmailer][download][md5] = "0bf75c1bcef8bde6adbebcdc69f1a02d" libraries[phpmailer][directory_name] = "phpmailer" libraries[phpmailer][destination] = "modules/contrib/smtp" libraries[phpmailer][patch][drupal-compatibility][url] = "http://drupalcode.org/project/smtp.git/blob_plain/2acaba97adcad7304c22624ceeb009d358b596e3:/class.phpmailer.php.2.2.1.patch" libraries[phpmailer][patch][drupal-compatibility][md5] = "2d82de03b1a4b60f3b69cc20fae61b76"
Now when the SMTP module is included a normal drush make file it will be downloaded, the PHPMailer library will be downloaded and patched ready for use.
Unfortunately there are some limitations to this approach. Firstly it assumes that the SMTP module will be installed under the modules/contrib directory, which is accepted best practice, but may not suit everyone's needs. When I tested this with the current stable version of drush make (6.x-2.2) it failed, and drush make 6.x-3.x from git needed to be patched. Hopefully a fix for this can be backported to the 6.x-2.x branch and included in a future release.
Update: I have posted the make file for the SMTP module as patch in issue #1159080.
Lately I have been trying to avoid non packaged software being installed on production servers. The main reason for this is to make it easier to apply updates. It also makes it easier to deploy new servers with meta packages when everything is pre packaged.
One tool which I am using a lot on production servers is Drupal's command line tool - drush. Drush is awesome it makes managing drupal sites so much easier, especially when it comes to applying updates. Drush is packaged for Debian testing, unstable and lenny backports by Antoine Beaupré (aka anarcat) and will be available in universe for ubuntu lucid. Drush depends on PEAR's Console_Table module and includes some code which automagically installs the dependency from PEAR CVS. The Debianised package includes the PEAR class in the package, which is handy, but if you are building your own debs from CVS or the nightly tarballs, the dependency isn't included. The auto installer only works if it can write to /path/to/drush/includes, which in these cases means calling drush as root, otherwise it spews a few errors about not being able to write the file then dies.
A more packaging friendly approach would be to build a debian package for PEAR Console_Table and have that as a dependency of the drush package in Debian. The problem with this approach is that drush currently only looks in /path/to/drush/includes for the PEAR class. I have submitted a patch which first checks if Table_Console has been installed via the PEAR installer (or other package management tool). Combine this with the Debian source package I have created for Table_Console (see the file attached at the bottom of the post), you can have a modular and apt managed instance of drush, without having to duplicate code.
I have discussed this approach with anarcat, he is supportive and hopefully it will be the approach adopted for drush 3.0.
Update The drush patch has been committed and should be included in 3.0alpha2.