The sole idea of having to set up an isolated site, download the module to be patched, enable it, perform the necessary changes, test them, create the patch and get it into an issue queue on drupal.org makes many people (including me) feel unwilling to do such a thing.
But the good news is that with a few tools it is possible to be contributing back to the community in a matter of minutes, yes minutes.
How many times have you been testing a module for your next awesome Drupal site and found some small issues with it that could be corrected by very simple and common procedures but, after considering all the work needed to create a patch for it and publish it on an issue queue, decided not to bother to do it? I guess quite a few, at least.
The reasons are obvious if we check, one by one, the steps necessary to set up a basic dev install:
- Download, unpack and install drupal core; which requires creating dns entry, apache directory entry, database, database user, password and then walking through the installer.
- Download, unpack and install the module to be patched. This is very annoying if you don't use a helper module as the admin_menu module to navigate around the admin interface.
- Set up sample content types/nodes to test your code.
- Use an SCM system (e.g. git, bazaar) to keep control of your changes and to create the patch that will be finally posted on the module's issue queue.
- Write and test your code.
- Post your patch at the corresponding issue, or create a new one.
Just by doing the first three steps by hand, you've spent at least 10 minutes without getting at least a one liner patch!
That's the bad news. The good news is we now have Quickstart, a very nice VM with a full fledged development environment for Drupal.
The procedure I've been using with quickstart is very simple and straightforward:
Create a makefile.make file to download the needed modules. A good example makefile could be:
core = 6.x projects = drupal projects = cck projects = views projects = poormanscron projects = admin_menu projects = devel projects = \*buggymodule\*
cd to the ~/websites folder and run:
drush qc all --makefile=/path/to/makefile.make --domain=buggymodule.dev
- Follow the on-screen instructions to install the site.
cd to the site's folder (~/websites/buggymodule.dev) and enable the modules running:
drush en -y admin_menu devel \*buggymodule\*
cd to buggymodule's folder and run:
git init git add . git commit -m "Initial commit"
- Write and test your code.
Create a patch by running:
git diff --no-prefix > ~/Desktop/buggymodule_awesome.patch
- Go to drupal.org and post your patch.
By the time you're done with step 5 it should be around 3 to 4 minutes (depending on your network connection and machine), so the hazzle of doing it manually is reduced a lot, thus giving more time to the real thing: coding!.
Bonus: mantainability of changes and future updates
Since the dev site must be deleted after the job is done (see drush help qd), the question arises: how can I use the patch easily later? The answer for that is, as many answers today for Drupal developers, drush make; by updating the base .make file for your main development site with the directives to download the module and apply the patch you'll be able to avoid some more complications. A sample makefile using this could be:
core = 6.x projects = drupal projects = cck projects = views projects = poormanscron projects = admin_menu projects = devel ; Add experimental support for lang and geocode parameters, see http://drupal.org/node/1006864 projects[twitter_pull][patch] = "http://drupal.org/files/issues/twitter_pull_lang_geocode_cvs.patch"
The indicated steps for the process are just a suggestion, of course, since each case can be different; but seeing it it's easy to understand the common tasks involved in contributing.