Last Updated: February 25, 2016
·
1.524K
· timfernihough

Work-around for when self hosted Drupal patches don't apply because of home networks

PROBLEM:
It's fairly typical (at least in Canada) that your ISP at home or your work (if you work for a large company like a bank) will set a default search service page to redirect your browser to if you request a URL that doesn't resolve anywhere. You'll get this response instead of an HTTP 404 error (not found) which is what will happen in all other cases.

For those that use .make files for their Drupal development; this can cause a problem if you've decided to self-host a patch that gets built by running the make file. Once in a while, especially when developing on a private repository for a client, you might not have the luxury of waiting for a .patch file to be approved on drupal.org. Or perhaps, for confidentiality reasons, you can't post it.

Enter, the self-hosted patch. In your .make file, it'll look something like this:

Picture

The make process will take the URL specified in the .make file for the patch and attempt to download it from the internet (i.e., as a fully qualified domain name) in order to put it into the Drush cache.

Of course, because this is a self hosted patch, the path of "/tmp/patches/my-issue-###.patch" will not respond with an HTTP 200 response. Instead, it'll get a 404 error and the make process will instead look for it locally; which in most cases will work just fine.

However, consider the scenario where you're at home and requests for malformed URLs actually don't give the 404 error Drupal is depending on as a check to switch over to searching locally. Instead, an HTTP 200 response is provided. At this point, the HTTP 200 response is actually not correct, but Drush caches the response of the patch; which is not actually the diff you'd be expecting. Instead, its the HTML markup of the default search page which will fail to apply during the .make process.

See below the Drush cache folder that contains cached versions of patches specified in the .make file.

Picture

So how do I deal with this? I don't want to go into the office at 11pm or on a weekend just so I can run the .make process successfully.

WORKAROUND:
- Navigate to your Drush cache folder (on Mac it'll be something like /Users/{user_name}/.drush/cache/download).
- In there, you will see files with filenames similar to the file path of the patch as referenced in the make file. (i.e., /tmp/patches/my-issue-###.patch becomes tmp-patches-my-issue-###.patch in the cache folder).
- Open that file in an editor.
- Copy the contents of each self-hosted patch file into that cached version of the file.
- Re-run your build/make process.
- Patches will apply this time successfully.

Note: When you clear your drush cache (i.e., drush cc drush), that will likely remove the contents of this folder and you'll need to repeat these steps the next time you need to run the make process.

1 Response
Add your response

I ran into this on a VPN where the the local resolver returns a host for 'tmp' (e.g., tmp.vpn.example.com). The host didn't send any response, so drush just spent a long time waiting for a timeout before proceeding.

Another solution that should be more persistent was mentioned in a drush issue: https://drupal.org/node/840540#comment-6039634

Adding an entry for 'tmp' (or whatever directory your patches are in) to your hosts file that points to 127.0.0.1 will cause the request to fail quickly, causing drush to fall back to the local file.

It also looks like Drush 6 will handle local files natively.

over 1 year ago ·