Including Patches in Drupal Contrib Modules

Very occasionally in building a Drupal module (especially for 7.x), you can't actually quite do what you want to do without a change to another module or core. Every effort should be made to avoid that but there are instances that it is truly required and the right method. If on your own site it is pretty easy to document, commit to version control etc - still questionable but doable. However if it is for a public module, it has been problematic at best but there is a way to reduce the pain.
 

The traditional method has been in your read-me and/or module pages stating that it requires x changes to x files or sometimes giving a link to an issue in the queue or patch (for example see OOE). This does work but is an annoying method and is verging on killing kittens (hacking core) territory. The problem is that many of your users may do the change, then forget about it when updating core and then suddenly module doesn't work, possibly even causing dreaded WSOD. Providing those instructions, warnings and all is something you will still have to do because unfortunately the better method will not work for all users.

The better method: use Composer's patches functionality (provided by cweagans/composer-patches).

Most people using composer to manage their Drupal installations are already using it as it is required in the Composer template for Drupal Projects. So how is it better:

• Patch is automatically applied (if possible) every time an update is downloaded.
• Almost no end user work is required to apply/use.

You basically have to add very minimal of instructions to your project readme/project page. For example:

This module requires x patch: <link>
You can manually make the required changes (probably a bunch more detailed instructions on how to apply/manually make changes) or if you are using composer, enable patching. To enable patching just run

composer config extra.enable-patching true

prior to installing this module and the patch will be automatically & safely applied.

So that is very simple for anyone already using composer and doesn't add much noise for non-composer users. It is also very easy to set up on your end; add a composer.json to your module (if it doesn't have one the Drupal packagist endpoints will generate one, otherwise it will automatically use your own) and add a few specific settings. For example here's a minimal one, used in the Field States UI module (mostly written by myself):

{
  "name": "drupal/field_states_ui",
  "description": "Provides a UI for applying field states.",
  "type": "drupal-module",
  "homepage": "https://www.drupal.org/project/field_states_ui",
  "authors": [
    {
      "name": "Nick Wilde",
      "homepage": "https://www.drupal.org/u/nickwilde"
    },
    {
      "name": "See other contributors",
      "homepage":"https://www.drupal.org/node/2776325/committers"
    }
  ],
  "support": {
    "issues": "https://www.drupal.org/project/issues/field_states_ui",
    "source": "http://git.drupal.org/project/field_states_ui.git"
  },
  "license": "GPL-2.0+",
  "require": {
    "cweagans/composer-patches": "~1.0",
    "drupal/core": "8.x"
  },
  "extra": {
    "patches": {
      "drupal/core": {
        "multi-value field widget hook": "https://www.drupal.org/files/issues/no_hook_to_edit-2822460-2.patch"
      }
    }
  }
}

You must require cweagans/composer-patches and then add the patches. To add the patches, you just add them as individual "description" : "link to patch" lines under the project they are patching under patches in the extra section.

So in summary it is very easy to set up on your end, will save time for some of your users and won't affect the others so why wait? If you have to patch core or contrib use this method now. Any questions? Feedback? examples of use? We'd love to hear from your below, or on Twitter!