Skip to main content

Blog Post

A quicker way to apply a Drupal / contrib patch

by Damien McKenna
May 24, 2016

The normal Drupal instructions for applying patches are well used and reliable. However, I find them to be a little verbose, so I came up with a slightly quicker workflow.


The short explanation of what I do is to copy the patch's URL and run this command:

curl [patch URL] | patch -p1

Which would then become something like this:

curl | patch -p1


  1. This workflow assumes the current version of the module/theme/core being patched is up-to-date, possibly a -dev version, and that the patch was also relatively current. It is common for files to substantially change from revision to revision, so a patch written against the latest -dev version of a module may not work with an older release.
  2. I'm not touching the "always use Drush Make" or "Composer is how the cool kids do it nowadays" workflows, this is purely about spending less time mucking around with patch files to test what could be a single line change to one of the simplest, or most complex, pieces of code you've ever seen.
  3. This is written from the perspective of testing out a patch, it doesn't cover patch management as part of site maintenance, i.e. what to do with patches on an actual site codebase; we will cover this topic in a separate article.

Longer explanation

Step 1: Find the patch to be applied.

Step 2: Copy the patch's URL into the clipboard.

Step 3: In Terminal (or the Command Prompt on Windows), go to the appropriate directory for that project, e.g. sites/all/modules/contrib/metatag.

Step 4: Type the following into the terminal window: curl

  • Make sure there's a space after the command, i.e. c-u-r-l-SPACE
  • Paste in the patch's URL.
  • Type this: | patch -p1
  • (that's a pipe symbol followed by the "patch" command and the arguments "-p1")
  • The full command should look like this:
    curl | patch -p1


Step 5: If it gave any warnings, update the issue with the comment "This patch needs to be rerolled." and change the status to "Needs work".

Step 6: Presuming the change applied ok, use "git status" to see what changed.

Step 7: If any files with a file extension ".install" show as either being changed or added, run the database updates.

Step 8: Clear all of the site's caches: drush cc all

Reason to do this

  • There's no need to keep a copy of a patch file, it can always be downloaded again later from if needed again.
  • Because there are no patch files locally there's no worrying about where the patch file is stored on the computer versus which directory the command prompt is in, or how to make the path to the patch work correctly.
  • "git apply" does not apply the patch at all if it would not apply cleanly, and it often doesn't explain why the patch would not apply, even with the "-v" argument. If the patch didn't apply cleanly then it has to be manually recreated from scratch, which can be problematic and lead to mistakes. Using the "patch" command instead will apply what can be successfully applied, and anything that couldn't be applied correctly will be saved out as a separate ".rej" file, leaving much smaller pieces to be recreated.
  • There will be fewer files floating around the computer; the only patch files on my computer are the ones I actually created.

Over to you

What development processes have you tweaked to your own liking? Let me know in the comments.


Additional Resources
Mediacurrent's Contrib Committee April 2016 Update | Mediacurrent Blog
How to Add Content in an Update Hook | Mediacurrent Blog
Acquia's Dev Desktop: A Drupal Service for Beginners | Mediacurrent Blog

Meet team member, Damien McKenna

In his role as Community Lead, Damien directs internal initiatives that strengthen Mediacurrent’s commitment to open-source principles, collaboration, and sharing knowledge to strengthen the Drupal community. Regularly ranked as one of the ten most active contributors on, Damien has been a significant member of the Drupal community since 2007. In addition to writing documentation, writing & reviewing patches and mentoring others, Damien maintains Metatag, Views, Twitter, Panelizer and several other SEO-focused modules.

Prior to Mediacurrent, Damien spent five years building content management systems and frameworks using multiple languages (PHP, ColdFusion, Ruby), before he was first introduced to Drupal in 2007. A year later, he delved deeper into Drupal 5's architecture while migrating two popular skiing sites off a proprietary system. While becoming increasingly involved in his local Drupal community, Damien led the development of several successful content-rich platforms including a US radio station network spanning ten individual sites. Damien joined Mediacurrent in 2012 as a Lead Drupal Architect, where he was involved with planning the architecture of new sites, project estimates, and lots of hands-on development work.

When not working with Drupal, Damien enjoys playing ukulele and spending time with family in their home in Keene, NH.

Learn more about Damien >

Related Insights