When building Drupal sites you often do some core hacks which means you change Drupal core sources. Too many hacks and painful Drupal upgrade may arise. You should find all the patches, reapply them against sources, besides do you always remember what was applied?
Generally it is not a hard task to patch Drupal core when some module wants you to patch some file in order to make it working. You simply run
patch < patch-name.patch
in Drupal's root. The same can be done for other contributed modules. Then problems arise when you want to upgrade Drupal to newer security update (6.11 to 6.12) or even new version (6.x to 7.x):
- You need to keep track of all patches you have applied.
- You need to to reapply all the patches manually from console.
To simplify these tasks I use patchdoq module. It provides a simple administration page with the list of all registered patches:
Clicking on "apply" link will patch your Drupal sources.
Installing module
- Make Drupal files writable for web-server. Usually this can be achieved using command:
chmod -R o+w path/to/drupal/root
- Enable patchdoq module on Modules page.
- Go to Administer -> Site building -> Patch (
admin/build/patchdoqpage) page to see the list of patches modules provide. Probably it'll be empty if you haven't installed any module that provide patches and depend on Patchdoq. - Apply / unapply patches you want.
- Don't forget to remove write permissions from web-server on your Drupal files:
chmod -R o-w path/to/drupal/root
Adding new patches
To add new patch to the list on Administer -> Site building -> Patch page you need to implement hook_patch() callback. See patchdoq.module file for example.
Download and more information
Download Patchdoq from drupal.org. More information can be found in project issues.
Comments
Ack! File permissions!
Correct me if I'm wrong, but won't running the second chmod command recursively remove write permissions from directories that should have them (e.g. sites/all/default/files, etc.)?
Having to perform these commands on the Drupal root is inviting disaster. Hopefully patchdoq (side note: bleh on putting your name in the module name, that's kind of taboo naming conventions) forces you to have your site in maintenance mode before applying the patches and also performs some kind of hook_requirements check to warn users if they didn't un-apply the write permissions on the root folder.
Solution: never run on production
Right, it will remove write permission from files directories. But for such case I always have makefile script to set / restore sites/all/default/files write permissions.
But I suggest you to change permissions only locally on development server. Then you go to Administer -> Site building -> Patch, apply patches you need, commit your sources into source control repository. Branch / tag them. Checkout / update and use on production server.
I use it the way described.
So, NEVER run
on production server. For most security you even need to disable patchdoq module on production. Patches are applied already so it's not required.
Dave, please give your suggestions about module name if you find it useful and valueable.
Post new comment