Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough

A quicker way to apply a Drupal / contrib patch

Parent Feed: 

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.

TL;DR

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 https://www.drupal.org/files/issues/metatag-n2636348-12.patch | patch -p1

Disclaimers

  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.

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

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 drupal.org 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

Original Post: 

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web