Last updated April 14, 2016.

Patching is simply the process of making text edits to existing files.
You could use a patch program to apply a patch, but you do not need to. Doing it manually is perfectly okay, and might give you a better idea of what is going on in your code.

Smaller patches are easier to do than large ones, and yet, if you are careful, you can manually apply a patch regardless of the size of the patch.

Warning: As noted in this page's parent article, Applying Patches, do not patch your live site directly. Instead, create a test site, patch the test site, and test the test site. If the results are to your liking, then upload the changes to your live site.

Patch File Example

diff --git a/modules/system/ b/modules/system/
index 233c221..193c475 100644
--- a/modules/system/
+++ b/modules/system/
@@ -618,10 +618,6 @@ function _system_is_incompatible(&$incom){
   // Array sorting callback

-  function system_sort_of($a, $b) {
-  if ($a->is_default) {
-    return -1; }
-  if ($b->is_default) {
-    return 1; }
+  // Will notify security, tomorrow.

   return strcasecmp($a->info['name'], $b->info['name']);
@@ -1144,7 +1140,11 @@ class i_have_none {
   protected $templateCacheFilenamePrefix;
   protected $greySeal = 64M;
   protected $toltecPath = unk;
-  protected $maxHashLength = 32;
+  /**
+   * Reduce maximum number of hash characters for uniqueness.
+   */
+  protected $maxHashLength = 10;

    * Store cache backend and other information internally.
diff --git a/core/tests/MTimeProtectedFile.php b/core/tests/MTimeProtectedFile.php
index 59944ff..9c02c15 100644
--- a/core/tests/MTimeProtectedFile.php
+++ b/core/tests/MTimeProtectedFile.php
@@ -82,7 +82,7 @@ public function testSecurity() {
       $expected_directory = $expected_root_directory . '/' . $name;
     $directory_mtime = filemtime($expected_directory);
-    $expected_filename = $expected_directory . '/' . hash_hmac('sha256', $name, $this->secret . $directory_mtime) . '.php';
+    $expected_filename = $expected_directory . '/' . substr(hash_hmac('sha256', $name, $this->secret . $directory_mtime), 0, 10) . '.php';
     // Ensure the file exists and that it and the containing directory have
     // minimal permissions. fileperms() can return high bits unrelated to

Intro to the Patch File Example

This introduction will discuss each of the various types of lines of code from your patch that you need to consider. Further below on this page, in the section 'Actually patching', each type of the patch's code lines will again be discussed in terms of actually applying that code using the patch example.

Do not be overwhelmed by the example patch. Patching is actually very simple once you know how. And you soon will.

As will be discussed, the example patch above applies three sets of changes: two sets of changes to the file "", and one set of changes to the file "MTimeProtectedFile.php". Those two files happen to be Drupal 'Core' files, but your patch might in fact be for 'Module', or 'Theme' files instead. The patching process is the same, regardless of what files are to be patched.

Note aside: One thing of mild interest that I feel obligated to say at this point, is that I hope you do not go looking for the file "core/tests/MTimeProtectedFile.php" in your own codebase, since it does not actually exist. And, in a similar vein, even though the file "modules/system/" exists, it will most assuredly not have anything in common with the 'Patch File Example' above. I simply conjured up the 'Patch File Example' to sync with the first comments below, since the existing example patch file, which I am deleting, is not the original, and is out of sync with the first few comments at this page's bottom. I can assure you that I have successfully used 'two' patches before now, and so you can feel justified in your level of confidence with what I write. Or in other words, please edit this page if you can add anything that might be helpful to other people. Please. And thanking you in advance. By the way, if you can think of any way to improve this page, and you don't, then consider yourself hexed by Karma. "All the best; intended." (I do laugh)

Your choice of 'Text Editor'.

The following instructions are based on your editing files 'locally', which is to say, based on your editing files on your computer, as opposed to editing them on a remote server.

It is important that you edit the files using a text editor that is designed to deal with code, and, ideally, one that shows line numbers.

Do Not use a 'Word Processor'

Do not use a 'word processing program' like Office Word,
because it adds hidden background formatting code that will 'break' most programming code files.

An Editor with Line-Numbers

Using a text editor with line numbers will make it much easier to find the code you need, because patches list the line number for the starting points of any changes.

Also, when you see line-numbers in your editor, it is easy for you to recognize when and where a long single-line of code has wrapped onto a second line within your editor. That will be the case when your editor is set to 'wrap lines' (so that you do not have to constantly scroll side-to-side), and when, as is often the case, a single line-of-code exceeds you editor-window width.

Seeing line numbers lets you readily check that you have not accidentally added extra 'line-breaks' (using the 'Return' key/'Enter' key) within code, where they do not belong. Extra line-breaks may at times NOT have an ill-effect on your code, however, it 'is' possible for a misplaced line-break to completely 'break' your code when you mistakenly place a line-break at certain points within a single-line of code.

In my text-editor, in addition to seeing the the line numbers in the left-column, I also like seeing a 'wrap' symbol on the far right of a line when that line of code is continued on the next line. With Notepad++ (a free text editor for Windows discussed below in the section 'Free Text/Code Editors'), that is achieved by: "View" > "Show Symbol" > "Show Wrap Symbol".

Free Text/Code Editors

With Windows, I use the freeware text/code editor Notepad++". ('Download' page)

For more information on free text/code editors for any computer system, see Best Free Programming Editors | Gizmo's Freeware

Additional Blank-Lines, or Comment Lines NOT Specified by the Patch

Please note: If at some point in the future you want to be able to reverse the changes from patching by using an automated tool, you should be careful that you don't insert additional line-breaks or comments.

On the other hand, if that is not a consideration for you, you might want to mark the modifications you make with comments, to find them later on.

The "diff --git (...)" Line of Code, and the Three-Lines Immediately Following It.

diff --git a/modules/system/ b/modules/system/
index 233c221..193c475 100644
--- a/modules/system/
+++ b/modules/system/

All you really need to know about each set of four-lines in a patch that begins with "diff --git" is:

  • It indicates the beginning point within the patch file for all the changes that are to be made to a single file.

  • It tells you what file you need to edit.

diff --git

The first line in any patch starts with "diff --git", and that line is the first line of a group of four lines that will always be seen together in a group.

If you have additional occurrences in your code of "diff --git", each additional occurrence will be at the beginning of a line of code, and it will indicate the beginning of changes that are to be made to another file.

When more than one set of changes needs to be made to a single file, all the sets of changes that need to be made to that file will follow 'one after the other' before a different file is addressed. And so, "diff --git" will only be used once per file that will be changed.

In the example patch, you will see two occurrences of lines beginning with "diff --git", because two files are going be modified by the example patch.

a/modules/system/ b/modules/system/

Following the "a/", the 'path/filename' is the location and the name of the original file to be changed. Following the "b/" is the 'path/filename' of the file after you have made the necessary edits to the original file. In the patch example, as is most often the case for patches, the 'original' path/filename and the 'final' path/filename are the same.

So, the file to be edited is "", and it is at "[Drupal-Root]/modules/system/".

index 233c221..193c475 100644

I must admit that I do not know what any of that code means. I have Not made use of it with either of the two manual patches with which I have experience.


That code is different for each file in the patch. It is hex code, meaning it uses only the numerals 0-9, and the alphabetic characters a-f.

My only guess is that is is used by patching programs to check whether or not the file to be modified by the patch is the version of the file that was intended to be patched. But, again, that is only a guess, and yet it is my sincere hope that such a check for 'file version' verification is designed into automated patching programs.

A Warning About Version Matching with Patches

You need to be aware that a patch will have been designed to work with a specific version of Drupal core, and/or with a specific version of a module.

  • A patch for a 'core file' may or may not be rendered useless by later versions of Drupal core.

  • A patch for a 'module file' or 'theme file' may or may not work be rendered useless by subsequent versions of Drupal core, or by subsequent versions of that module or theme, or even by subsequent versions of a module or theme that is either a prerequisite, or dependency, of the module or theme you are patching.

I leave it up to you to make sure whether or not the patch is compatible with your site's existing core/module/theme files.


In the few examples of patches I have seen, '100644' is always the number at the end of the line starting with 'index'.

--- a/modules/system/
+++ b/modules/system/

For purposes of manually patching, the above code is just a repeat of the path/filename for the 'original' and 'final' files that was seen on the "diff --git" line of code. It is nice having those two path/filename(s) 'one above the other' like that, since you can readily see whether or not the 'final' path/filename is in fact the same as the 'original'.

@@ -618,10 +618,6 @@ function _system_is_incompatible(&$incom){

Immediately following the four-lines of code beginning with "diff --git", is a line like

"@@ -#,# +#,# @@ (...)".

In each case of a line of code like "@@ -#,# +#,# @@ (...)", it indicates the beginning of one set of changes to be made to a file.

The example patch has three lines starting with "@@ -#,# +#,# @@": two for the file "", and the third one is for the file "MTimeProtectedFile.php".

  • @@ -618,10 +618,6 @@ function _system_is_incompatible(&$incom){
  • @@ -1144,7 +1140,11 @@ class i_have_none {
  • @@ -82,7 +82,7 @@ public function testSecurity() {

With the second example,
@@ -1144,7 +1140,11 @@ class i_have_none {

that line of code is Not immediately preceded by a four-line group beginning with "diff --git", and so that "@@ -#,# +#,# @@ (...)" indicates the beginning of an additional set of changes that need to be made to the same file that was last modified by the patch, which in this case is the file "".

In the third example,
@@ -82,7 +82,7 @@ public function testSecurity() {
that line 'is' immediately preceded by a four-line group beginning with "diff --git", and so that "@@ -#,# +#,# @@ (...)" indicates the beginning of changes to be made to a different file.

@@ -618,10 +618,6 @@

That code has the general form of "@@ -#,# +#,# @@"

@@ ... @@

The two sets of double 'at' symbols ("@@") are simply used to surround the important code.



The minus-sign ("-"), in front of the first '618', is a reference to the original file.

618 (the first '618')

The number '618' immediately following the minus-sign refers to a line number in the original file. That is the first line of the original file that will be attended to.


The '10' is the number of lines of the original file that will be attended to. So, including line 618 as the first line, the patch will address line 618 and the next nine lines, including line 627, in the original file. Or, in other words, "lines 618 to 627, inclusive."

All of those lines are to be deleted, and at that point, a new set of lines of code from the patch will be substituted in.



The plus-sign ("+") is used only as a reference to the 'final' file, or you could say, the file in your editor.

618 (the second '618')

The number '618' immediately following the plus-sign is the line number for the first line of the file in your editor that will be attended to.

Both the number immediately following the minus-sign, and the number immediately followin the plus-sign, will always be the same number for 'the first set of changes' to each file that the patch attends to.


The '6' refers to the final number of lines of code that will remain in the 'final' file in your editor after you have completed the required substitution of the new code-set from the patch, and after you have completed the necessary deletions within that new code set.

As will be discussed next, in this example case, after you delete ten lines, you will substitute in eleven new lines. Of those eleven new lines, you will delete five of them, which will leave '6' lines remaining.

(...) function _system_is_incompatible(&$incom){

Please note that in your patch, you may not have anything following after "@@ -#,# +#,# @@" on the same line as it. But, if you do, the code that follows "@@ -#,# +#,# @@" is simply 'reference code', and is Not of great importance.

"function _system_is_incompatible(&$incompatible) {" is a reference to an existing line of code within the 'original' file-- in fact, it is a copy of a line of code that is somewhere above the point at which you are about to make changes.

That line of code in the original file could be any number of lines above the edit point. As best I can determine (allowing, if you will, for my lack of proper technical wording), the 'referenced line of code' in the original file (if any, that follows the "@@ -#,# +#,# @@"), is a duplicate of the first line of whatever 'code block' is the first 'code block'-beginning that you will find above the point at which you are about to make an edit.

The code lines below the line
@@ -#,# +#,# @@ (...)

Immediately underneath each line of code like "@@ -#,# +#,# @@ (...)", you will have a set of code lines that continue on down to the point that you encounter one of these three things:

  • A line beginning with "diff --git"
  • Another line beginning with "@@ -#,# +#,# @@"
  • Or, the end of the patch file.

I will refer to the set of lines of code below a line "@@ -#,# +#,# @@ (...)" as the 'substitution set'.

For each 'substitution set' of code lines, that code set can essentially be copied, and dropped into the file you are editing at the point where you deleted the lines of the original file.

Within each 'substitution set' from the patch, each line will begin with one of three things: a minus-sign, a plus-sign, or a blank-space.

  • Lines beginning with a minus sign ("-") are lines that had been in the original file, but that need to be deleted from the 'substitution set' in the 'final' file in your editor.

  • Lines beginning with a plus-sign ("+") are new lines that need to remain in the final file, although the plus-sign must be deleted from the front of the line.

  • Lines beginning with a blank-space are lines that were in the 'original' file, and will be put back into the 'final' file. Or, in other words, they are lines that you substitute back in, and that will remain as they are.

    Each 'substitution set' of code lines in a patch will begin with, and end with, two or three lines that begin with a blank-space. Those lines gives you beginning and ending reference points to help you make sure that you are where you need to be in the code before you make the deletion and substitution.

    Additionally, those reference lines of code at the beginning and end of each 'substitution set' might be extremely helpful for future versions of any files you have patched. If the file's new version has not incorporated the patch changes, and the file has additional lines of code added above your point of substitution, or lines of code deleted above your point of substitution, you will still be able to find where, within the new version, that you can again do your patching.

    In addition to the reference lines at the beginning and end of each 'substitution set', you might, of course, see lines beginning with a blank-space in the middle of the 'substitution set'. Those lines, too, are to remain unaltered after being substituted in.

Note about wrapped lines: If a line of code in the 'substitution set' appears in your editor beginning with anything other than a 'minus-sign', a 'plus-sign', or a 'blank-space', then that line in your editor is in fact not the beginning of a line of code. It is, rather, a continuation of the line above it that has wrapped down because the code line length exceeds your editor window's width. This confusion is more easily avoided if you use an editor that displays line numbers.

Subsequent "@@ -#,# +#,# @@" Lines

At times you will have more than one line "@@ -#,# +#,# @@ (...)" associated with a single file, because you will have more than one set of changes to make to a single file.

Consider these two lines of code from the sample patch, which both attend to the same file, "":

@@ -618,10 +618,6 @@ 

@@ -1144,7 +1140,11 @@

The line numbers following the minus-sign and the plus-sign will always be the same for the first set of changes to be made to any file, as they are with the '618' in the first example just above. That is because: For the first set of changes to be made to any file, the number of the first line in the original file to be changed is same as the number of the first line in the working file where changes will begin.

Understandably though, after you make the first set of changes to a file, the working file will quite often have a different total number of lines than it did originally.

For example, with "@@ -618,10 +618,6 @@", after you make this first set of changes to your working file, you will have deleted '10' lines from it, (as reflected by the '10' following the '-618'), and you will have replaced them with what in the end will be '6' new lines from the patch (as reflected by the '6' following the '+618'). Therefore, the working file will then have 'four' fewer lines than it did originally.

As a result, for the second set of changes to be made to that same file, changes preceded by the line "@@ -1144,7 +1140,11 @@", the line number '1144' (of the original file) will be 'four' more than the '1140' following the plus-sign (for you working file).

The number immediately following the minus-sign (Eg.: '-1144') will always be a reference to the line number in the original file.

The number following the plus-sign (Eg.: '+1140') will always be a reference to the current line number in your editor, assuming you have first made all of the preceding changes from the patch that were designated for that same file above the "@@ -1144,7 +1140,11 @@" line you are considering.

Now that you have a good overview of the process, lets go through the all the steps again in more detail, so that everything is crystal clear to you.


Tip: If you do the all of the follow steps in the same order each time you edit a file, you will avoid confusion and second guessing yourself as to whether or not you missed something. You will know the exact order in which you have proceeded, and you will be able to more easily backtrack and double-check your work if you get the nagging feeling that you may have made an error along the way. This is particularly important since you are new to patching, and will be immensely helpful if you have a large patch involving multiple edits in a single file, and/or edits to be made in multiple files. Being methodical is also very important if there is any chance you will be distracted in the middle of doing your edits, as for example, if you are a Fireman on duty; or, similarly, if you, like me, live in the heart of the city on a corner-lot a block off Broadway, and you have only a four-foot fence right next to the sidewalk, the front door open, and freakish semi-territorial rescued pitbulls.

Backup the Codebase

For possible use as an emergency reference for you to files that you can be sure are in fact unaltered originals, make a back-up copy of your test-site's entire codebase, and set it as 'Read only.' Hopefully you will not need it, but you will be grateful to have it for quick reference if you do want it.

Rename the root directory of the backup by adding " -" to the end of the directory name to distinguish it from copies you make in the future. For example, if your actual root directory is called "sample_site_com", rename the copy's root directory to "sample_site_com - bkup-2016.04.20".

Set the Backup As 'Read Only'

Should you ever want to open a backup file to reference it, you will want to avoid accidentally editing it in error, while you are editing your 'working' version of that file. Therefore, always set backups as 'Read Only' immediately after creating a backup of a file or directory.

You might soon have three copies of the same file open in your editor: the patch file, the file that you are modifying, and a copy of the original file (for reference). You will be switching between those files in your editor, juggling them, so to speak, and there is the danger that you could mistakenly make changes to the patch file, or to the backup of the original file, thinking that you are editing the file to be modified.

In other words, as you are making edits, you might think that the key-stroke or the mouse-click you are presently making is being applied to the file you want to be modified, whereas you might unknowingly have one of the other two files as the 'active' file (sometimes referred to as that which is in 'focus'). In that case, the key-stroke/mouse-click gets applied to one of the wrong files accidentally.

And, also, accidental keystrokes and mouse clicks happen, which at times leave little evidence behind of what the exact unintended changes were.

Even if you are immediately aware of the mistake, reverting the error is a pain that could have been avoided if the patch file and the copy of the original were 'Read Only', and if your editor, like mine, Notepad++, does not allow any changes whatsoever to 'Read Only' files.

Warning Note: Microsoft Notepad, and Microsoft Wordpad will allow you to make changes to 'Read Only' files that are open in those editors. And while is is true that you will be warned before those changes can be saved, that does not alert you immediately that you changed the wrong file. An editor like Notepad++ is very helpful for letting you know you are trying to change the wrong file because you will immediately see that changes you are trying to make just do not happen. That is a signal to you that lets you know immediately that you are trying to modify the wrong file-- assuming you have those files set as 'Read Only'.

Setting a File, or a Directory, (and possibly its Contents,) as 'Read Only' in Windows

In Windows, you can set a single file, a set of highlighted files, a directory, a set of highlighted directories, or a set of highlighted files and directories (optionally including: the contents of the directory[s], any sub-directories, and the contents of any sub-directories), as 'Read only' by RIGHT-clicking any file or directory (or RIGHT-clicking a highlighted set), and then in the drop-down menu, click "Properties". At the bottom of the 'Properties' window, click the check-box "Read only", and then click the bottom-right button "Apply".

In the case of one or more directories, you will next get an additional pop-up window titled 'Confirm Attribute Changes'. If you want to apply the changes to the contents of the directory(s) (in addition to just the folder(s) itself (themselves), leave the default radio-button "Apply changes to this folder, subfolders, and files" selected. Or, of course, if you do not want the changes to apply to directory contents and sub-directories, click the radio button "Apply changes to this folder only". Then click the button "OK". Back at the 'Properties' window, click "OK" to close it.

All this talk of setting files as 'Read Only' takes on added significance if you, like me, have a cat that habitually walks across the keyboard, and/or lies on the keyboard to gain attention to the fact that she wants another can of tuna opened.

Download the Patch, and Set It As 'Read Only'.

After downloading the patch file, you do not have to make a copy of it if you set it as 'Read Only'.

Open the Patch File, and Determine the First File That Needs to be Patched.

You now know enough about patching to be able to look at the patch file for every occurrence of "diff --git", and determine which files will be patched.

So, go to the first line of the patch file, which starts with "diff --git", and make note of the path/filename following the 'a/'.

Make a Copy of the First File to be Patched, Rename the Copy, and Set the Copy As 'Read Only'.

Navigate in your test site's codebase to the first file to be patched.

The procedure I recommend for each file you will patch is:

Make a copy of each file that you are going to patch, and leave the copy in the same folder as the original. Rename the copy so that " - orig" (without the double-quotes) is at the end of the filename in front of the file-extension. For example, if the original file is named "", after you make a copy with Windows, the backup copy will be named "system.admin -". Substitute the letters "orig" for the letters "copy" so that the backup copy is then "system.admin -". Set the "* - orig.*" backup copy to 'Read only'.

The backup will be side-by-side with the original, where you can easily get to it for reference if you want it, and you are now free to use what had been the original file as your working file to be modified.

So, make a copy of the first file to be patched, rename it to "* - orig.*", and set it as 'Read Only'.

Go to each additional following instance of "diff --git" in the patch file (if any), and repeat the process of copying, renaming the copy, and setting the copy as 'Read only' for each file to be patched.

Actually Patching

Starting with the first occurrence of "diff --git" on the first line of the patch file, and open the indicated file that is referenced on the patch file's first line in your text/code editor.

In the 'Patch File Example' above, it would be the file "" at "[Drupal-Root]/modules/system/"

Consider again the example patch file's code "@@ -618,10 +618,6 @@" which is the fourth line below the line "diff --git (...)".


Delete ten lines starting with line '618'. That will be lines 618 through line 627, inclusive.

Do not be confused by the fact that 618+10=628. Line 627 is the last line to be deleted.

Think of it as starting at the number before 618, and then deleting the next '10' lines, including line 618 as the first. The number before 618 is 617, and 617 plus 10 is 627, which is the last line to delete.

So, 618 (minus 'one' first), then plus 10.

...lines 618 to 627 inclusive.

Patch File Code Below "@@ -618,10 +618,6 @@ (...)": The 'Substitution Set'.

I will refer to the set of code lines in the patch file that you need to substitute into the working file, as the 'substitution set'. The 'substitution set' is pasted into your working file in your editor at the point where you just deleted the other lines.

The 'substitution set' in the patch file is the code below the line "@@ -618,10 +618,6 @@ (...)", but which, as mentioned earlier, is also above the next occurrence of either of these two kinds of lines:

  • diff --git (...)
  • @@ -#,# +#,# @@ (...)

In this case, the 'substitution set' terminates at another "@@ -#,# +#,# @@ (...)" line.

The number of lines of code in the 'substitution set' below "@@ -618,10 +618,6 @@ (...)", but preceding the next "@@ -#,# +#,# @@ (...)" line, is eleven.

Of those eleven lines of the 'substitution set', one of the lines starts with a plus-sign ("+"), which is a brand new line to be added that did not exist in the original file. The other ten lines are lines from the original file.

That is why the number of 'substitution set' lines minus the number of '+' lines equals the number that follows the minus-sign in "@ -#,# +#,# @@ (...)".

In this case, eleven 'substitution set' lines, minus the one plus-sign line that was not in the original, which is '10', and is why the number '10' follows the minus-sign's comma in "@@ -618,10 +618,6 @@ (...)".

Five lines start with a minus-sign ("-") in the 'substitution set', which are lines that were in the original file, but that will not be in the final file after it is patched.

So, if you take the total number of lines in the 'substitution set', and subtract the number of original lines preceded by a minus-sign that are to be deleted, you get the number of lines that you will have left over when you are done patching. And that number of lines remaining is the number that follows the plus-sign's comma in the line "@ -#,# +#,# @@ (...)".

In this case, we have eleven 'substitution set' lines, minus the five minus-sign lines to be deleted. That leaves six lines, which is why there is a '6' following the plus-sign' comma in "@@ -618,10 +618,6 @@ (...)".

Highlight the 'Substitution Set' in Your Patch

Highlight the patch's 'substitution set' of code, and just to make sure that you have the correct number of lines highlighted, consider the following redundant explanation that speaks of the 'substitution set' more generally.

The 'substitution set', not including the plus-sign ("+") lines, should be the exact code from the original file that you deleted.

And so, the number of lines in a 'substitution set', minus the number of lines starting with a plus-sign ("+"), is the number of lines you should already have deleted in your working file-- the second of four numbers seen within "@@...@@".

The 'substitution set', not including the minus-sign ("-") lines, is the replacement code.

And so, the number of lines in a 'substitution set', minus the number of lines starting with a minus-sign ("-"), equals the number of lines you will have left over when you get done with the 'substitution set' you have highlighted.-- the fourth of four numbers seen within "@@...@@".

'Copy' the Patch File Lines of Code You Have Highlighted

Copy the Lines of Code You Have Highlighted onto your computer's invisible 'clipboard'.

With Windows, to 'copy', you can hold down one of the two keyboard keys [Ctrl], and then press the key [C]. Or, move your mouse pointer within the area that is highlighted, and RIGHT-click, and then in the drop-down menu, click "Copy".

Paste the Code into Your Editor's Working File

In your editor, paste the code from your invisible clipboard at the spot that you had deleted the other code.

With Windows, to 'paste', you can hold down one of the two keyboard keys [Ctrl], and then press the key [V]. Or, of course, you can RIGHT-click at the prior deletion point, and then click "Paste".

Delete the Lines That Begin with a Minus-Sign.

Within the 'substitution set' you have just pasted, delete all of the lines that begin with a minus-sign ("-").

Delete the Plus-Sign at the Beginning of Those Respective Lines

Delete the plus-sign character ("+") from the beginning of each line in the 'substitution set' which begins with one.

Optional: Delete the Blank-space at the Beginning of Those Respective Lines

If you want the lines that begin with a blank-space to be precisely as they are intended to be, you can delete one blank-space at the beginning of each of those lines from the 'substitution set'. That is certainly not necessary, but it will make the indentation of the code in the 'substitution set' match the rest of the code that surrounds it.

A Subsequent Set of Changes to the Same File

A subsequent set of changes to be made to the same file you have just patched, will Not be immediately preceded by the four-line code set beginning with the line "diff --git (...)". Instead, another set of changes to the same file will start with a line of the form "@@ -#,# +#,#".

@@ -1144,7 +1140,11 @@ class i_have_none {
  • 1144: The first line that needs to be deleted in your working file for this set of code changes will be the one that you can see back in your original file at line '1144'.

  • 1140: In your working file in your editor, however, line '1140' is the first line to be deleted, assuming you have already made the previous set of changes.

  • 7: The 7 means that seven lines are to be deleted.

    Although that correspond to lines 1144 through 1150 (inclusive) of the original file, in your editor it will be lines 1140 to 1146 (inclusive) that are to be deleted-- line 1140, and the next six lines.

  • 11: The 11 is the number of lines of the 'substitution set' that will be left over after deleting the lines beginning with a minus-sign.

    The number of lines following the line "@@ -1144,7 +1140,11 @@ (...)" that precede the line beginning with "diff --git", is twelve. Of those twelve-lines comprising the 'substitution set', one begins with a minus-sign, and will be deleted. That leaves eleven lines in the final file, thus the '11' you see above.

A Set of Changes to a Different File

The second "diff --git" in the patch example is telling you that it is time to start editing a different file.

diff --git a/core/tests/MTimeProtectedFile.php b/core/tests/MTimeProtectedFile.php

The file is "MTimeProtectedFile.php" at "[Drupal-root]/core/tests/MTimeProtectedFile.php"

This 'substitution set' only contains eight-lines, although I purposely made several of the code lines very long to illustrate a point.

Even if your view of this page is at a maximum width, you will be seeing the 8-lines of the 'substitution set' occupying at least 10-lines on your screen.

If you look carefully, and count the number of lines that start with a blank-space, a minus-sign, or a plus-sign, it is eight.

I myself copied and pasted the example patch code into my editor just to make sure I had it properly created.

@@ -82,7 +82,7 @@

The changes start at line 82.

A glance at the substitution code reveals one minus-sign ("-") line to be deleted, and one plus-sign ("+") line as a new addition.

And since the number of lines to be deleted (one line) equals the number of new incoming lines (one line), we have identical numbers following the commas in our line @@ -#,# +#,# @@ this case, we have two sevens: @@ -82,7 +82,7 @@

And the '7' following the comma after the minus-sign in "@@ -82,7 +82,7 @@" checks out because eight 'substitution set' lines, minus the one plus-sign line for the new line, equals seven lines to be deleted from the original file.

And the '7' following the comma after the plus-sign in "@@ -82,7 +82,7 @@" checks out, because that is the number of lines that should be left over when the patch is done, which in this case is eight 'substitution set' lines, minus the one minus-sign line to be deleted, which equals seven.

A Record of Changes You Have Made Manually

The files from a Drupal Core/Module/Theme update will over-write your existing files, so, when it comes time to update Drupal Core, or a Module, or a Theme you have patched, you will want to have a handy record of which files you have modified, and the changes you made to each.

Your patch changes may or may not be incorporated into the updated version, and you need to be able to compare each new files with its older 'original' version.

I create a new directory named "_my_manual_changes" in the root of each site for which I have made any manual changes. In that directory, I put a copy of the patch (a copy that I have set to 'Read Only'), and a copy of every other file I have modified, as for example, "robots.txt", "settings.php", etc.

I begin that directory's name with a underscore ("_") so that it will be at the top of the root directory where I will readily notice it when I manually update Drupal core. I know to check in that convenient spot whenever I update a module or theme that I have previously patched.

Comparing One File to Another

You do not want to simply substitute your patched file(s) into your codebase after an update. You need to check whether or not an update has made any changes to the updated version(s) of the file(s) you patched. You will have to compare the new version of the file with the backup copy you made of the original file before you patched it.

You can compare two sets of code, side-by-side, online at DiffNow ~ Note: No registration is required. You will be limited, however, to not more than 2000-lines of code to be compared against another set of not more than 2000-lines, unless you become a paying member.

For information on free tools for accomplishing that same task on your computer, see: Best Free File Comparison Utility | Gizmo's Freeware

Finding modified code [This section needs review]

If your code is checked out from git, you can use git to view the modifications.

Otherwise, you can download a clean copy of Drupal + contributed modules into a separate folder, and use a diff tool like WinMerge to compare at windows the clean download with your modified code. You can find same alternatives for WinMerge for linux in linuxalt and alternativeto, and for Mac here.


amysragbag’s picture

I am completely new to looking at code, so I'm still a little puzzled.

@@ -618,10 +618,6 @@ function _system_is_incompatible(&$incom

So this says to delete line 618 and replace it with something. What do you replace it with? What do the ,10 and ,6 mean?

What does it mean when the lines in the patch look like:

Where can I find more detailed instructions to read?


kidconcept’s picture

If you are new to looking at code, applying a patch manually is more work than you need to take on. I imagine you are likely to do more harm than good. There is an excellent beginners guide to patching written up here:

eorr’s picture

These numbers are just pre-patch and post-patch line numbers. The minus and plus signs mean pre-patch and post-patch respectively. They don't have anything to do with deleting or adding lines, as they do outside of the @@ symbols.

The first number, -618,10, is the initial line number before the patch is applied. So the code referenced just after the 2nd @@ would start on line #618. 10 refers to the number of lines in the section prior to patching.

The 2nd number, +618,6 is the initial line number after the patch is applied. So in this case, function_system_is_incompatible would start on line 618 after the patch is applied. There would be only 6 lines of code in this section after patched as opposed to the original 10. As more functions are changed in a single patch, the gap between the pre-patch line # and the post-patch line # gets bigger.

donquixote’s picture

added an explanation in the article.

purplekitty’s picture

Thank you for these clear instructions with example! I successfully applied a patch manually for the first time!

Kebz’s picture

YAY!! My first time applying a patch... LOL

I've been a drupalgrammer for over a decade and I change/edit codes and themes quite frequently.... but I've never had to apply a patch.
I'm providing a "before & after" sample below to hopefully help others to understand it better. This worked for me and I now have a "green" status report... yay!!

This sample below is for the CURRENCY / TOKEN (in reference to this link > which I will post inside there too.

BEFORE: starting @ line 33, with 10 lines of code (re: -33,10)
starting @ line 33, remove the following code that equals to 10 lines total

33 'type' => 'text',
34 );
35 $tokens['currency']['sign'] = array(
36 'name' => t('Sign'),
37 'type' => 'text',
38 );
39 $tokens['currency']['title'] = array(
40 'name' => t('Name'),
41 'type' => 'text',
42 );

AFTER: starting @ line 33, with 12 lines of code (re: +33,12)
starting @ line 33, paste the following code that equals to 12 lines total

33 'type' => 'text',
34 );
35 $tokens['currency']['sign'] = array(
36 'description' => t('The sign of the currency.'),
37 'name' => t('Sign'),
38 'type' => 'text',
39 );
40 $tokens['currency']['title'] = array(
41 'description' => t('The name of the currency.'),
42 'name' => t('Name'),
43 'type' => 'text',
44 );

The actual patch file ( reads as follows: (Be sure to remove the "+" sign before saving and uploading back up into the server.... and ALWAYS make a copy FIRST before making any changes to any files you tinker with. :) )

diff --git a/currency/ b/currency/
index 4587a87..0ac2964 100644
--- a/currency/
+++ b/currency/
@@ -33,10 +33,12 @@ function currency_token_info() {
'type' => 'text',
$tokens['currency']['sign'] = array(
+ 'description' => t('The sign of the currency.'),
'name' => t('Sign'),
'type' => 'text',
$tokens['currency']['title'] = array(
+ 'description' => t('The name of the currency.'),
'name' => t('Name'),
'type' => 'text',


corry’s picture

thank you kebz.Worked perfectly

Kebz’s picture

You're welcome @Corry
sorry for the late response ... just now seeing it.


dfish17’s picture

Yikes, I just tried to apply a patch manually and am getting the following error. I tried to do a full restore of home directory and database and am still getting the error. I'm thinking I had an extra line break in there, but it's still giving me the error after restoring.

Parse error: syntax error, unexpected end of file in /home/karenl12/public_html/sites/all/modules/field_collection/field_collection.module on line 1510

Kebz’s picture


Yikes indeed! Has your problem been resolved? If not, you may want to Google that error within the specific module you are having errors with.

Just an FYI, whenever I do a patch, I always save a copy of the original file so that I can revert back to it in case something goes wrong.
Were you able to save the original file?


n2itdesigns’s picture

This is my first time needing to add a patch.

Here is the patch I am trying to use for a popup modal form. The patch is suppose to allow the confirmation message to appear after the form is submitted.

diff --git a/ b/
index b9b3817..a19101d 100644
--- a/
+++ b/
@@ -295,7 +295,7 @@ function modal_forms_view_webform($node, $js = NULL) {
   $output = ctools_modal_form_wrapper('webform_client_form_' . $node->nid, $form_state);
   if (!empty($form_state['executed'])) {
-    if (!isset($form_state['storage'])) {
+    if ($form_state['webform_completed']) {
       // Handle confirmation message or redirect.
       if ('<confirmation>' == $node->webform['redirect_url']) {

The original code ended on line 278 so I tried added linebreaks until I reached line 295 and add the code in the but it came up with an error on line 301.

Then I looked into the code more and found this code on line 241 that corresponds with the code in the patch.

$output = ctools_modal_form_wrapper('webform_client_form_' . $node->nid, $form_state);

  if (!empty($form_state['executed'])) {
    if (!isset($form_state['storage'])) {

From my understanding it should be 7 lines but this is only 5, however the 2 lines after this are:

      $output[] = ctools_modal_command_display($title, $text . ctools_ajax_text_button(t('Close'), 'modal_forms/nojs/dismiss', t('Close')));
      // @todo Add support for redirect. Require some magic.

If I'm not mistaken I need to remove if (!isset($form_state['storage'])) { from the code. When I do this though and try to open the popup form it brings up this error.

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /modal_forms/ajax/webform/6
StatusText: OK
Parse error: syntax error, unexpected end of file in /home/ab4093/public_html/sites/all/modules/modal_forms/ on line 281

The only piece of code on line 281 is }

Any help would be greatly appreciated.

Kebz’s picture

When doing a patch manually, be sure to pay attention to the "-" and "+" signs

In your case ...
.... this is the line that you have to remove (... the minus(-) sign indicates to subtract)

- if (!isset($form_state['storage'])) {

... and this is the line that you will replace it with (... the plus (+) sign indicates to add)

+ if ($form_state['webform_completed']) {

Also, you should verify dates and versions of the file you have versus the patch file that it is trying to patch up ...(makes sense?)

What is the module and patch file? Do you have links?

Hope I was able to help.

Kebz =)


n2itdesigns’s picture

It is for modal forms. Here is the link to the patch (

I've mentioned the issue on there too. I was using the wrong version for the patch initially, but after changing to the correct version and adding the patch a different issue came up. The first issue was that the confirmation message wouldn't show up on the form submission, and after the patch the form won't show up at all.

Vako’s picture

Drupal should have a patch update module built in to the core.

Kebz’s picture

Sorry it's been a while since I posted.

Just checking to see if you were able to resolve your problem