Search form

Part 2: Testing and applying patches for d7cx

I wanted to show how so-called "non-coders" can make significant contributions to the Drupal project. Probably the quickest way to make friends with a module maintainer is to help out in the issue queue. You can also help out with triage on some of the busiest projects. This requires no coding at all. (Check out the Views bug squad!) After triage, the next things you can do are:

Try to replicate bugs - are you finding the same problems under the same conditions?

Download and test patches - does the patch work as expected under your conditions?

Previously in Part 1 - I described how you can simply download and test your favorite modules to make sure they are working in Drupal 7. Even simple modules like "Environment Indicator" have alpha versions available for Drupal 7. That project has no issues for 7.x version. But has it been fully tested? Give it a whirl! If you find a bug, then say so.

In this next part, I have 2 videos which will show your how I apply and test a patch with a GUI; then how I create a new patch. Now we'll look at patches: applying, testing and submitting.

First: What's a patch?

Does the word "patch" sound mysterious to you? Never had a chance to "apply a patch"? or "Reroll a patch"? Or possibly even submit a new one?

Patches are text files they have instructions indicating differences with lines preceeded by a "-" to indicate that a line will be deleted, and a "+" sign to indicate a line will be added. This set of instructions is saved, instead of just making the changes directly. This means you can pass along this fix. By sharing this fix, other people can apply this patch and get the same fix.

When we say "don't hack core" in Drupal, it means don't change the files directly. You can however write neccessary patches, apply and share them. Patches are written to fix a bug, but sometimes can introduce new problems. Because of that, they need to be tested. And we'll see how to do that.

While patches are human readable, they are used by a program in the operating system which controls applying the patches. I know myself, before I knew how to "apply a patch" I did a few manually. It takes a long time. Let the computer do its job.

Drupal.org has great documentation on how to use Patches: http://drupal.org/patch But sometimes it just helps to look over someone's shoulder and see how they do things. I hope the next videos help.

Testing patches with a GUI (graphical user interface)

Using the command line turns out, it's not that hard. It's just weird. Addison of Lullabot has an ongoing series of Command Line Basics, where she takes the weird out of the CL. It's just strange at first. And because of that it stops many people from trying it. For me, using a GUI was an important first step to break the seal. It made it possible for me to actually test a patch. Yoroy (Roy Sholten) showed me Aptana Studio during a sprint at DrupalCon, and I was so excited! I could now test patches on D7 and be a part of all the work going on.

In the videos below, Panels is getting the attention. I made this video for a friend to show her how I actually apply a patch and how easy it is. Although I'm using Aptana studio, I'm only using it for some simple actions, to download the project from CVS and to apply a patch. Other application may differ in their UI, but they will work the same.

I used Aptana Studio 1.5, I recently tried upgrading to 2.0, ran into problems and said "feh". There are a few other good applications to make it easier to apply and test patches. Find out more on Drupal.org

Locating projects and patches for #d7cx

You can select a module to start with and search the queue. Status: Open issues (or if there are many, Status: needs review) and Version: 7.x issues. Click Search.

In most cases I'm finding there are few issues to review at this stage. And that is good news!

In the Pirate module - there were no issues found! That simply means there's no patches to be reviewed. That doesn't mean there are no bugs. You can choose to download this module and give it a go, or also

Reviewing: Downloading and applying a patch to a contributed project

In this video, I foible through downloading and applying a patch on a contributed project. I downloaded a patch and found "segments do not match", and then I show how to re-roll the patch.

After you apply a patch you want to look at your installation of Drupal, does the patch work as expected? If there are any errors, copy and paste the text so it can be searched. If it's something visible take a screenshot. If it's a behaviour, describe it.

(BTW - My wording is unclear in the video, as explained above, you're comparing the differences from the patch you made with the code you have on your server.)

Submitting: Creating a patch

In this video, I show the steps I would go through to create and submit an Advanced Help patch. It does go into a little detail about how Advanced Help creates references to new HTML files, but its a good demo showing how to create, test and then submit a patch. I also talk about how to look at an issue queue.

Think of an issue queue like a roomful of people having conversations about the project. Try to join on-going conversations, and listen to the previous discussion. This video comes complete with cat meowing and purring too, which I find soothing while creating patches.

Your turn!

So give this a try.Don't be shy, even a "non coder" can make a huge contribution by testing patches. If you'd like to learn how to help, go to your local Drupal User group (or make one) and see if someone can sit down with you and show you how to do this. Many people would be glad to help you learn.