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.
