One of the great things about using open source code for projects is the opportunity to contribute back to the community and get a little recognition for your hard work. Just like the code though, there's a "Drupal way" for patch contribution and the goal of this article is to help you expedite your plan to contribute module patches back to the community and to limit the difficulty you will have in getting those patches accepted.

1. Pulling the latest code.

The first step is to get the most up-to-date version of whatever module you are working on.  The checkout code I use basically follows this format:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d PATH_TO_MODULE_DIRECTORY -r DRUPAL-4-7 contributions/modules/MODULE_NAME

PATH_TO_MODULE_DIRECTORY & MODULE_NAME 

When I begin modifying a module, I will usually set PATH_TO_MODULE_DIRECTORY = MODULE_NAME.  For instance, when working on the taxonomy_menu, my PATH_TO_MODULE_DIRECTORY and my MODULE_NAME were set to taxonomy_menu.  This created the taxonomy_menu module in a standalone directory, utilizing the Drupal CVS, that I could come back and diff against at a later date.  Since all of our projects utilize CVS or SVN, this makes it easier to create a diff against the Drupal code base.

DRUPAL-4-7

Most of my contributed patches have been ports from 4.7 to 5.0, so I've been constantly pulling the DRUPAL-4-7 branch so that I could port the latest 4.7 version to 5.0.  If you want to create revisions against 5.0, you would use DRUPAL-5 in place of DRUPAL-4-7 in the example above.  

2. Updating the files

If you like, you can pull a full version of the drupal code base to work on using this command (see DRUPAL-4-7 above about pulling other versions):

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -r DRUPAL-4-7 drupal

Although this would allow me to use the latest code base at all times, most of the time I'm working on a module for a specific project and submit patches when I find code that doesn't function correctly.  Either way, copy (don't move, copy) the module directory into your project's modules directory.

The next step is finding bugs, testing functionality, etc.  There are a million ways to go about this, but I use the code as a reference and verify that all of the pages are working as intended. When porting modules, I try to make the revisions stated here for themes and here for modules, then I test each page of functionality both against 4.7 and for the expected behavior in 5.0. This process will be different for each individual, but basically, debug the heck out of the code and make sure everything is working.  There's nothing more disheartening than submitting a patch that doesn't actually help.

3. Commenting

Once you have finished all of your revisions, make sure you go back and comment any new functions that you have created and/or modify any existing comments that are no longer relevant.  For instance, hook_settings was removed between 4.7 and 5.0, so leaving the comment  "Implementation of hook_settings()" above the administrative settings function doesn't make a lot of sense. Reality check the comments to ensure that they're accurate.

4. Create a diff

Now that you have your revisions and your comments in place, let's dump the code files back into our original module checkout.  DON'T COPY THE CVS OR SVN DIRECTORIES.  We want to keep using the Drupal CVS for creating our diff, and we don't need a bunch of extraneous files meandering about; so it's important that you leave the CVS and SVN directories alone and only move the code files.  Now that we have everything in the original checkout directory for our module, navigate to the directory, and run the diff: cvs diff -u -p * >  MODULE_NAME.patch -- this will create a patch file in the current directory covering all the files and directories.  It will warn you about CVS directories, but will automatically skip them so it will not impact your patch.  Now, if you added any new files, you should have seen something like the following: "cvs diff: I know nothing about FILE_NAME".  These files will need to be added separately. Grab your patch and any new files (such as a .info in the case of the Drupal 4.7 - Drupal 5.0 ports), then head to drupal.org.

5. Submitting the patch 

Go to the project page for whatever module you are working on. Click on "view all issues", then "submit" up top if it is a new issue or click on the issue you are resolving then click "follow up" on the bottom right.  However you get there, you should now be at a page to submit your patch.  The project should be set for you, but you should set the Version to be the version you are patching against and the component to be "code".  The category will be set if you're responding to an existing issue, otherwise, you can set it as the task for your patch submission.  Set the status to "patch (code needs review)" (it's always good to have someone look over your code...don't submit it as ready to be committed no matter how sure you are of your programming skills). Set an appropriate title and message body, then attach your patch to the post.  If you added files to the project, leave a message about which files will follow in your next post, then follow the same steps as above, but you can just leave your body as the files you are including, and attach your extra file(s) instead of the patch file. In the case of a .info file, the file should be renamed .info.txt as Drupal blocks display of .info files; other than that, adding other files follows the same pattern.

6. Glory and Honor

Now just sit back and bask in the glory of having contributed to the Drupal community, then wait for honor to be bestowed upon you for your amazing contributions. Good Luck & Happy Coding!