Composer en Including Patches in Drupal Contrib Modules <span class="clearfix field field--name-title field--type-string field--label-hidden">Including Patches in Drupal Contrib Modules</span> <span class="clearfix field field--name-uid field--type-entity-reference field--label-hidden"><span lang="" about="/user/1" typeof="schema:Person" property="schema:name" datatype="">NickWilde</span></span> <span class="clearfix field field--name-created field--type-created field--label-hidden">Tue, 01/24/2017 - 18:43</span> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>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.</p> <p>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 <a href="">OOE</a>). This does work but is an annoying method and is verging on <a href="">killing kittens</a> (<a href="">hacking core</a>) 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 <abbr title="White Screen of Death">WSOD</abbr>. 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.</p> <p>The better method: use Composer's patches functionality (provided by <a href="">cweagans/composer-patches</a>).</p> <p>Most people using composer to manage their Drupal installations are already using it as it is required in the <a href="">Composer template for Drupal Projects</a>. So how is it better:</p> <ul> <li>Patch is automatically applied (if possible) every time an update is downloaded.</li> <li>Almost no end user work is required to apply/use.</li> </ul> <p>You basically have to add very minimal of instructions to your project readme/project page. For example:</p> <blockquote> <p>This module requires x patch: &lt;link&gt;<br /> 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</p> <pre> composer config extra.enable-patching true</pre> <p>prior to installing this module and the patch will be automatically &amp; safely applied.</p> </blockquote> <p>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 <a href="">Field States UI</a> module (mostly written by myself):</p> <pre> { "name": "drupal/field_states_ui", "description": "Provides a UI for applying field states.", "type": "drupal-module", "homepage": "", "authors": [ { "name": "Nick Wilde", "homepage": "" }, { "name": "See other contributors", "homepage":"" } ], "support": { "issues": "", "source": "" }, "license": "GPL-2.0+", "require": { "cweagans/composer-patches": "~1.0", "drupal/core": "8.x" }, "extra": { "patches": { "drupal/core": { "multi-value field widget hook": "" } } } }</pre> <p>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.</p> <p>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 <a href="">Twitter</a>!</p> </div> <div class="clearfix field field--name-field-audience field--type-entity-reference field--label-inline"> <div class="field__label">Audience</div> <div class="field__item">Module Developers</div> </div> <div class="clearfix field field--name-field-difficulty field--type-entity-reference field--label-inline"> <div class="field__label">Difficulty</div> <div class="field__item">Moderate</div> </div> <div class="clearfix field field--name-field-recommended-skills field--type-entity-reference field--label-inline"> <div class="field__label">Recommended Skills</div> <div class="field__items"> <div class="field__item">Command Line</div> </div> </div> <div class="clearfix field field--name-field-tutorial-subject field--type-entity-reference field--label-above"> <div class="field__label">Tutorial Subjects:</div> <div class="field__items"> <div class="field__item"><a href="/tutorials/drupal" hreflang="en">Drupal</a></div> <div class="field__item"><a href="/tutorials/composer" hreflang="en">Composer</a></div> <div class="field__item"><a href="/tutorials/patches" hreflang="en">Patches</a></div> </div> </div> <section class="clearfix field field--name-comment field--type-comment field--label-above comment-wrapper"> <h2 class="title comment-form__title">Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=13&amp;2=comment&amp;3=comment" token="IpQiXavlekgUkoMY55I96KcK_vUoClR5uCQ4Y4laa90"></drupal-render-placeholder> </section> Wed, 25 Jan 2017 02:43:13 +0000 NickWilde 13 at