Submitting patches

Here is a list of things to look for when getting ready to submit a patch to a project, be it Drupal core or a contributed project. Following these tips will give your patch a better chance at being reviewed and committed. You can find information about actually creating a patch in the Creating patches section.

Search the issue queue first

If you've found a bug, and have a fix for it, then there's always a chance that someone else has found the same bug, posted a bug report, and maybe posted a patch for it. If you find an existing issue for your bug - you can save a great deal of time by either reviewing existing patches on the issue, or posting your own there rather than starting a new issue. This has several benefits: patches only get committed when they've been reviewed and verified to work (usually by someone other than the project maintainer) - so if you post to an existing issue, then the other people who've commented will be notified that there's an update, and you have a much higher chance of someone else looking at your patch. Reviewing existing patches is also a great way to build your reputation in the community and get your own patches reviewed quicker later on. Make sure you also search issues without limiting the version since the same bug can be in multiple versions but only reported for one and bugs should be fixed in the latest version first.

Always post against the most recent development version

Patches against both core and contributed modules should always be posted against the most recent development version. If you find a bug in Drupal 5, there's a good chance that the same bug can be found in Drupal 6 or Drupal 7 (HEAD).

Wherever possible, we fix bugs in the latest development version first, then backport patches to stable branches. This ensures a consistent code between versions, that bugs fixed in older branches don't reappear in new releases, and because development versions usually have more activity - so the work of refining patches and ensuring the best solution can be most efficiently carried out in the queue for that branch. This is often the case for contributed modules, although you should research the issue queues for those modules first in case they use a different system.

If your bug doesn't exist in the latest development version, then there's a chance it's been fixed there, and the patch needs backporting to the version you found it in - so again, search the issue queue first. If you can't find an existing issue, post to the most recent version where the bug can be found. If you find a bug in more than one version, you should not file an issue for each version. Instead submit the issue against the latest development version and attach a patch for each version you have fixed to the issue.

Coding style and security

If your code deviates too much from the Coding standards, it will be rejected without further review. You may want to check your code with the code-style.pl helper script or the Coder module to help you find style errors. Well commented/documented code will also be looked upon favorably. Make sure your code follows the security guidelines! Obviously code that introduces security issues will be rejected.

Describe your changes

Describe the details of the change(s) your patch includes and try to be as specific as possible. Note that we prefer technical reasoning above marketing: give clear reasons why "this way" is good. Justify your changes with solid reasoning. It is important to note the version to which this patch applies. To help people test your patch (vs. reviewing the code itself) you should also provide some basic instructions about what problems to look for or specific steps to take to see the effect of the patch in a test site.

Name your patch

This is an optional step but makes managing patches easier for people who work with many patches at once. Adopting a standardized naming convention such as "module-issue#-comment#.patch" e.g. forum-12345-15.patch for the patch attached to comment 15 of issue 12345 is helpful.

warning Please do not include number signs (#) in your patch naming scheme until the issue #284899: Drupal url problem with clean urls has been fixed.

Verify your patch

Reviewers are overloaded reviewing and testing patch submissions. Please make their lives easier by assuring the following:

• Your code works! Test your code.
• If your patch is just a proof of concept or work in progress, then don't set your issue to "patch (code needs review)" status, instead set it to "active" or "patch (code needs work)".
• For core Drupal, patch against HEAD. If the patch is accepted into HEAD it can then be ported back to specific versions. If the patch is for a core bug, you can help speed things along by attaching back-ported versions. For contributed projects, you should patch against the latest development version (which may or may not be HEAD - check with the project).

Submit your patch

Patches should be submitted via the issue tracker. Create a bug report or feature request, attach your patch using the file upload form. Set the issue's status to "needs review" or "needs work". Setting the status to one of these options is important as it adds the issue to the patch queue.