Modification of contributed module and core files must implement one of the following options to ensure changes aren’t overwritten by Remote Administration (RA) updates. RA uses Drush to update both core and contributed modules for Drupal 7.x and some sites running the current Drupal version, so all modifications will be overwritten during the update process.
Note
If you are working with a third-party development team who will not be apart of your ongoing support, ensure they understand and supply the information in these guidelines.
Locking modules
If modified contributed modules must not be updated even when insecure, they must contain a
drush lockfile to ensure they are not overwritten by drush. For installation instructions, see Using drush lock files with contributed modules.This
lockmust exist on the production tag, because this is the default tag from which all RA updates begin.Locked modules won’t receive security updates. Any resulting security vulnerability is the responsibility of the subscriber’s development team.
Modified modules overwritten as a part of the update process can be reverted. Update automation does not detect differences between the installed module and its official release on Drupal.org.
Patching core and contributed modules
Acquia RA supports patches to core and contributed modules at its discretion. To give support, patch information and files must be provided and set up as expected. Update automation will try to apply the provided patches, and all results will be noted in the corresponding ticket.
How to use patch through Composer
To enable patching through Composer, complete the steps described in Patching with Composer.
How to use patch through Drush
Update automation implements a slightly modified version of the Drush Patch File extension. The following steps detail examples of each different use case.
Create the
patches.makefile in the following location:[reponame]/Ensure the
patches.makefile has the following information for the patch:A link to the patch, either on Drupal.org (preferred) or in the repository
If the patch exists only in the repository, place it in
[reponame]/patches/my_custom_patch.patch, as patches placed in the directory of the module they modify will be overwritten before automation attempts to apply the patch, and the patch will be unavailableA comment linking to the original Drupal.org issue which the patch addresses
A comment noting anything special about the applicability of this particular patch
Repeat the preceding step for each discrete patch.
Note
It is also possible to combine all patches into a single patch file. However, this method makes it more difficult to discern which part of the patch is still relevant.
A complete patches.make file with a Drupal core patch, a remote
patch file from Drupal.org, and a local patch would look like this:
; Specify the version of Drupal being used.
core = 7.x
; Specify the api version of Drush Make.
api = 2
; N/A
; Patching README.txt file.
projects[drupal][patch][] = "patches/minor_core_patch.patch"
; https://www.drupal.org/node/2408217
; Error when attempting to clear cache that is related to ctools.
projects[ctools][patch][] = "https://www.drupal.org/files/issues/ctools-cache-handler.patch"
; https://www.drupal.org/node/1713076
; Devel generate fails when generating data for a field.
projects[devel][patch][] = "patches/devel_generate_textfield_maxlength-1713076-1.patch"
Note
Acquia recommends placing local patch files in a directory called
patches, located above the docroot directory.
It is imperative that all patch-affected website features are tested to ensure that they behave as expected. All customizations are the responsibility of the subscriber’s development team.
Acquia RA recommends moving to stable, unmodified module releases as soon as possible. Acquia recommends that development teams routinely check if a patched issue was resolved by a security update or bug-fix release to move from modified code to a clean release.