Patches are text files that end in a .patch extension. They are structured files that consist of a list of differences between one set of files and another. They are used to describe the changes between a before (clean) and after (modified) state of the code in a module, a theme, or Drupal core. The Drupal community uses patches in order to share ongoing work and solutions to issues. You’ll encounter them frequently in the issue queue as the solution to a known problem with a module or theme. As a Drupal developer you’ll use patches to contribute your own work back to the project when you solve bugs or add new features.
When working with Drupal we recommend using Git to manage the application and creation of patches. However, the standard Unix patch and diff utilities will work just fine if you’re more comfortable with those.
Example tasks
- Apply a recommended patch from an issue on Drupal.org in order to fix a bug in a module or theme
- Download and apply a patch for Drupal core to review/test a proposed new feature
- Create a new patch based on your modifications to a module that you can upload to the Drupal.org issue queue to share with others
Confidence
Drupal developers have been using patches to share code changes since the beginning. So the available resources, even older ones, are still accurate. In addition to a patch workflow, you will now notice the option to create an issue fork or merge request through GitLab. This GitLab integration with Drupal.org works alongside patches and may eventually replace a patch workflow. See Creating issue forks and merge requests for instructions.
Drupalize.Me resources
Managing a Drupal application with Composer requires a few modifications to Composer's default behavior. For instance, Drupal expects that specialized packages called "modules" be downloaded to modules/contrib rather than Composer's default vendor directory.
Additionally, it is common practice in the Drupal community to modify contributed projects with patches from Drupal.org. How do we incorporate Drupal-specific practices like these into a Composer workflow?
In this tutorial we will:
- Address all of the Drupal-specific configuration necessary to manage a Drupal application using Composer
By the end of this tutorial you should know how to configure Composer to work with Drupal, and drupal.org.
This tutorial takes a look at applying a patch from Drupal.org to your local copy of a module or Drupal core using Git. Afterwards we'll look at how you can create your own patches, using git diff and git format-patch, in order to contribute code back to Drupal or any of the module's on Drupal.org. You can see a full Git workflow using GitHub in the lesson Git Workflow: Putting It All Together.
Additional resources
Git Best Practices: Upgrading the Patch Process article
Applying a patch in a feature branch
External resources
-
Working with patches (Drupal.org)
- A guide to working with patches in the issue queue.
-
Patching projects using Composer (github.com)
- If you use Composer to manage your codebase cweagans/composer-patches is the recommended way to apply patches. We like this approach because it also means you’ve got a record of which patches you’ve applied so that when it comes time to update a module in the future you don’t forget to reapply them.
Issue forks and merge requests
-
Creating issue forks and merge requests (Drupal.org)
- As of November 2020, a new issue fork and merge request workflow is available (in addition to the long-standing patch workflow).