3

I had to apply custom patch on Drupal 7 core and now I'm afraid that after rolling a new minor-upgrade over, it'll overwrite my changes.

Is there any way for me to preserve my changes even after upgrading to a new minor patch of core (in case that this patch haven't been applied to that version I'm upgrading to ), like creating a patched folder or something and make sure that my core stays operational?

  • 1
    drupal.org/best-practices/do-not-hack-core - are you sure you had to do it? Anyway, only stable way is to create a patch, and re-apply it to each version, with all needed testing. And sooner or later it will simply not apply anyway and you will have to recreate your changes from scratch. – Mołot Jan 15 '16 at 15:10
  • Also, if you have to do this — there may be value in your contributing back to the community. Please consider doing so. – Screenack Jan 16 '16 at 14:15
4

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
    
3

The best practice is to find some way to implement your feature that does not require patching the original core. You should try to read - Why don't we hack core?

Anyway, if you still want (or need) to maintaining your Drupal Core with a patch you can use any of this projects to manage your patches.

This project seeks to solve the following problems:

  • How do I document what patches I've applied to a project?
  • How do I reliably know what patches are applied or not without manually checking every single one?
  • How can I be reminded that I need to reapply a patch after downloading a module update?

Drush tool for helping with patch management on Drupal, which helps with patching, and upgrading modules.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.