Normally you should never hack the Drupal core. However, there are few exceptions:
- you're applying patch downloaded from Drupal.org which has been QA tested,
- you're applying patch implemented by people who're extremely familiar with the Drupal code base, development practices, and security model,
- you've tested the patch using unit tests (SimpleTest) included with your Drupal core and you properly document the change (e.g. by practicing proper revision control with your code).
If you decide for that, you should keep the patches well documented and ideally in your repository (e.g. one level up from Drupal docroot level, Drupal core folder, or create new patches/
folder for that).
Then each time you upgrade your Drupal core, you need to remember to apply those patches again (this should be part of your Drupal upgrade steps).
To automate this, you've the following possibilities:
using drush
command to upgrade your core (e.g. as part of the script):
drush -y up drupal
find . -name "*.patch" -depth 1 -print -exec sh -c "patch -p1 <'{}'" ';'
using drush
make, e.g.:
.make
file` (see: Full example drupal-org.make file)
api = 2
core = 7.x
projects[drupal][patch][] = http://drupal.org/files/issues/992540-3-reset_flood_limit_on_password_reset-drush.patch
projects[drupal][patch][] = http://drupal.org/files/issues/object_conversion_menu_router_build-972536-1.patch
YAML file (see: examples/example.make.yml)
core: "7.x"
api: 2
projects:
drupal:
version: ~
patch:
- "https://www.drupal.org/files/issues/add_a_startup-1543858-30.patch"
If you're not working on make files, you can still download Drupal core files into empty folder, this will automatically apply the patch files, maybe consider running some unit test, then replace your generated files into your Drupal core instance.
upgrading and patching manually in Drupal docroot:
curl https://ftp.drupal.org/files/projects/drupal-7.4?.tar.gz | tar xvf - --strip-components=1
patch -p1 < add_a_startup-1543858-30.patch