Have you ever worked with a Drupal developer who seemed to always be able to fix bugs by finding patches to apply seemingly instantaneously? At the risk of being dispelled from the Alliance of Magicians, I’ll share how I do it.

View All Issues

The first step to find a patch to a contributed Drupal module is to get to that module’s issue queue.  The path to the queue is always drupal.org/project/issues/[machine-name]. By default when you view a module’s issue queue only Open issues are shown. This excludes you from seeing all of the patches that have already been applied to the dev branch even if they have not been included in any stable release. When hunting for patches, be sure to look at All statuses.

You can save time finding the issue queue and showing all issues with a Chrome Search Engine keyword

My Drupal search keywords.

I have an “is” Chrome keyword, so I can type “is views” into Chrome and it takes me to https://www.drupal.org/project/issues/views?status=All

Search

First look at the top most recent issue titles for something similar. If these don’t look relevant use the Search to search within the issue queue. Using just one or two keywords in this search is typically best. Again scan the first few issue titles, opening up anything that looks relevant in a new tab. Don’t worry about the status of the issues or the number of comments (any relevant issue may provide a link to a better issue).

Scan

Don’t attempt to read issues in their entirety (unless you are going to be chiming in to the issue, in which case for the love of god do read and understand the entire issue before doing so). Start by quickly reading the summary of the issue (which may be the original poster’s issue or a revised summary) and then scan down the page looking for links to other issues, patches, and the last updates on the issue. Open any links to review in a new tab.

Stereotyping the actors in the issue based on their apparent professionalism helps you scan faster. If there are no patches and all commenters seem confused, look for a different issue as it may be a duplicate: the inexperienced may not have found the other issue where the real action is. Make sure you can tell the difference between an amateur (inappropriate status changes, complaints, excess punctuation??, not enough or irrelevant details) and a struggling English speaker (unusual word choice or grammar, speling erors) as the latter is much more likely to have a useful point. If someone stands out in the issue as knowing their stuff (often the maintainer), spend your time focused on their comments.

If the issue seemed unhelpful, close the tab. If it may be related but you’re not sure yet, leave it open. If it looks like exactly your issue, proceed to try out the latest version of any patch attached.

Go through all your open tabs scanning them this way. If you’ve scanned them all without a clear solution, next try looking more closely at the issues you still have open, or try different search keywords (you likely have learned a few relevant words from what you’ve scanned so far).

Declare Victory

Once you find a promising patch, to best impress your colleagues with your amazing speed you should declare victory in your chat room at this point. This will help add to the illusion that you have unusual speed at patch hunting. It helps to have some gifs ready for this occasion.

Apply a Patch

Instead of downloading a patch and then moving it to the right location on your machine or virtual machine, if you’ve already got a terminal open to the right spot it’s faster to copy the URL of the patch and use wget to download it. Don’t worry that the patch is for the dev version but you’re running the stable version- it will often apply anyway. The steps for patching Foo module are

    cd sites/all/modules/contrib/foo

    wget http://drupal.org/files/issues/foo.patch

    patch -p1 < foo.patch

Then you can use git diff (please be using git) to check your patch applied properly.

Note that many patches only change a few lines of code. If this is the case you may find it quicker to edit the files manually.

Test a Patch

Now, slow down. This isn’t the step to save time. You need to carefully test whether the patch fixed your problem and it’s easy to get confused when you do this (did I clear the cache? was I looking at the right environment? Did I attempt to reproduce it the same way?) which will get you completely off track.

Track a Patch

If the patch didn’t help or it broke something else, use git checkout to remove it. Read the issue the patch came from and if it still seems like the right issue, add a comment on your findings. Continue looking for patches or try another problem-solving technique (google? IRC? ask a colleague? debug the code? think of a workaround?)

If the patch solved your problem, chime in to the issue to say so (unless several folks have already said the same). If you now understand the involved code enough to review it, give it a code review and mark its status as Needs Work or Reviewed. If you want your patch to survive an update and not be a dirty hack (hint: you do) you need to track your patch according to your organization’s procedures. I highly recommend using a Drush Patch File workflow.

Happy patching!

Postscript: Check the Attitude

Do you get frustrated every time there’s a bug in your open source software and you need to find a patch or some other solution? You need to accept that bugs are a normal part of all software, and work with the rest of us as a giant team finding and fixing them as a part of our working process. You will be able to find solutions much more quickly when you look for them with calm confidence rather than frustration.

Terms: DrupalDrupal Planet