Place to put patched module under contrib or custom

Question

I am using a contrib module which has a patch in queue to be reviewed, the patch solves my issue. Where should I keep the patched module, keep it inside contrib module or should I move it under custom module directory and keep a watch on issue till it approved and then move it again to contrib? What is the preferable place to keep such module.

Answer 1

You may leave it in place (a good reason for doing this is given in the reply from alexkb).

However, this is not all there is to working with patches. Sometimes the maintainer is reluctant to include the patch in the official branch. This means that there may be new releases (security fixes!, bug fixes, feature enhancements) of the module without the patch. You need to think about how you deal with that.

Here is what I do: I set up staging area for where I keep all my custom modules. For the patched contrib modules, I connect those to the origin repo using git. I also setup a Makefile (or some other script file) to pull from the origin repo and semi-automate the reapplication of outstanding patches. Then, when a new release of the module is issued, the Makefile will pull and patch, and then send an email to me with the result. If the patch applies succesfully, I test and if the test turns out OK, I manually copy from staging to production. If the patch fails to apply due to some conflict, I try to resolve conflicts and try again.

This has two advantages:

1. Even when you're using a patched module, you're able keep up with the official branch.
2. You don't have to watch the issue queue, just set up your local repo to sync with origin at regular intervals (using CLI cron or similar).

The above workflow assumes some familiarity with the CLI and tools such as git, cron and make. It also takes some times setting this up to run semi-automatically. But if you need to work with patches, it is - IMHO - well worth doing.

Answer 2

Moving modules around in the file system means you have to perform some additional tasks before Drupal picks up the new path. This can be inconvenient and take your time.

Instead what we do is leave the module in the contrib folder, apply the patch and then create a new file in the module folder called .drush-lock-update. Inside this file we put some notes containing the drupal issue queue page URL and a quick summary of why it was applied. Drush detects these .drush-lock-update files and then ignores them when you run a drush up.

There is some more information over on d.o about this lock file and how it works.

It should be noted that the drupal core update module still monitors the version of your locked modules so you'll know when a security update comes out and can then manually review and apply the update separately.

Answer 3

For applying patch go through the following links

• Apply patches on Mac OS
• Apply Patches on Windows
• Applying a Patch Manually
• HowTo: How to apply a patch to a contributed module - Beginner's version (Windows)
• Making a Drupal patch with Git