Voting starts in March for the Drupal Association Board election.
Last updated March 12, 2016.
This information deals with applying patches without git. For information on using git to apply patches, please see the git patch contributor guide. For more generic information about patches, please see the Patch section of the Getting Involved Guide.
Applying patches, modifying files according to instructions in the patch file, is the domain of patch programs. There are many different programs with this functionality, some stand-alone (patch), some integrated in IDEs (Eclipse, XCode).
Warning: Patching is something that should never be done on your production site unless you first have a complete backup of your site, including the codebase and database; and you have tested that backup First. While patching itself is relatively easy, it is important that you fully understand that a patch can possibly lead to the loss of data and/or site instabilities.
In fact, the ideal way to proceed is to download a backup of your production site, make a second copy of it on your computer, and test the second backup on your computer to make sure it works, and that you know how to do it. Then, patch that test site, test the patch results, and then upload the changes to your production site.
This page only deals with some basic principles using the command line utility
patch. Patch can be found on most UNIX systems and is included in the packages UnxUtils and Cygwin for use on Windows. There is also a video on Applying and Creating patches with Git.
Provided that the patch was made relative to the root directory of the concerned project, navigate to that directory (using
cd). For a patch on Drupal, that will be the Drupal directory; for a contrib module or theme, that is the root directory of the project. Once there, issue the command:
You can use Git to apply a patch to a project's repository:
git apply -v path/file.patch
You can also use --index setting to track modified files:
git apply -v --index path/file.patch
If you are not using git, or if the repo isn't a local checkout of the project you wish to patch:
patch -p1 < path/file.patch
Note: git apply will fail to do anything when used within a local checkout of a git repository (other than the one for the project the patch is made for), such as if you are patching a module that is within a site that is in Git version control. Use
patch -p1 < path/file.patch instead. Patches created before git might need to be applied with: patch -p1 < path/file.patch
You can find more information about applying patches with Git in the Git handbook
The -p option tells patch how many leading prefixes to strip. For patches created using git, -p1 is normally the right option, and is the default for
git apply. If that doesn't work, try either of the above commands with -p0 instead.
If the patch was not made relative to the project's root directory, you can place the patch in the same directory as the file being patched and run the patch command without the -p option. To do so,
cd to the directory and type:
patch < file.patch
Patch will usually auto-detect the format. You can also use the
-u command line option to indicate a unified patch, and the
-b option creates a backup copy of the file before modifying it. In case of problems, you can then easily restore the backup file.
You can also reverse the patch if you want to.