Submitting Drupal Pull Requests and Applying Them Immediately

A big reason Drupal developers don't contribute back to the projects they use is the intimidation of getting started.  This is especially true for developers who need to bill their time in order to get paid. First off, let me be honest, I don't contribute back to Drupal much. I use and create patches to get me past the next hurdle, but rarely take the time to submit a pull request to the project's maintainer. One of the main reasons for this was that my code would not be immediately usable in my current project. The workflow I describe in this article makes getting the change immediately applied a little easier.

Forks and Merge Requests vs. Patch Files

In 2020 the Drupal project revised the workflow for how contributed code is updated.

For those who aren't familiar, previously code changes were made by attaching a patch file to an issue associated with the project being updated. It was then applied and reviewed by the community/maintainer.

The new way is far more structured, and makes it easier for the project maintainer to accept code changes. This process is discussed and explained at length at the following page: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupal/creating-issue-forks-and-merge-requests. In short, a new project is created as a 'fork' of the original where the changes are made and a pull request is initiated when the changes are complete. This "Pull Request" model follows a very common practice popularized by Github. While it might seem a lot more complicated than simply creating a patch file, its far more flexible as it relates to being applicable as a project changes. Patch files become unusable once the code it's 'patching' changes, which required 're-rolling' the patch against new code. A fork with a pull request on the other hand can simply be 'Rebased' to get the change back inline with the trunk of the project.

Applying your change immediately to your active project

One inconvenience to making a change to a contributed project is that the change isn't available in the project you happen to be working on, which provides the use case for the issue in the first place. It isn't practical to wait till the change has been accepted and merged in. Here is how I address this–

I'm going to assume first that you have followed the steps provided in the official Drupal documentation.

At this point, you have the project cloned locally and have made the updates needed.  You are able to push these changes and submit a pull request, but you really want to use this change in your current project. 

Let's assume you have the cloned contributed module sitting next to your active Drupal project.

~/Projects/MyProject/
~/Projects/commerce/

If you don't already have a place to put patches in your active project, make sure you do this by creating a specific directory for patches, and add the appropriate composer section. The 'patches' section should be directly under the 'extras' property, and the cweagans/composer-patches project should be required.

  "patches": {
      "drupal/commerce": {
          "Log all payment failure responses": "patches/payment-log.patch"
      }
  }

You should also know what branch you are using for the base of your change. In this example, I know that I am using the 2.x branch as my base. This can be determined by looking at what you have declared as a requirement in your composer file.

In the updated contributed project source issue a command like the following:

git diff origin/2.x > ../MyProject/drupal/patches/payment-log.patch

This will create a patch file that consists of all changes made in the contributed project and place the patch file in the patches folder located within your custom project.

Now you can run

composer update

... and the patch should apply, allowing you to immediately test your change from within the context of your custom Drupal project.