From time to time, it becomes clear that there is a bug in a module or some other aspect of Drupal. This is especially a concern whenever there is a major overhaul of the software and everyone is working frantically to keep up—since Drupal is only just moving to the new 4.7 version at the time of writing, this is more pertinent now than at any other time. When this happens, invariably people head to the forums to find out if anyone else has had the same problem. Often, as is the case with a bug, other people have also been stricken with the same problem and it may be that someone has been able to fix the problem.
If some kind soul has sorted out the problem on their machine, then it is most likely that they will submit a patch file to the forum so that it can be used by everyone else in order to fix their code. At this point it is important to realize several things:
- If you don't want to have any problems, ensure you only download well-tested and stable software for use on your site. Often CVS versions of a module still contain bugs or errors, and so it may be better to wait until a module is released and tested for your specific version of Drupal.
- Patch files are not specific to Drupal. They are simply files that explain a list of lines of code that should be added or removed in such a way that it is possible for a patch utility to implement those changes without the need for human intervention.
- Patch utilities are not native to Windows machines—they come with Unix-based operating systems such as Linux.
Linux users will need to take some time to learn how to make use of the patch utility if they find they need to implement it. Windows users need to go a step further and download a patch utility first. Luckily there is a download of common Unix utilities available at http://unxutils.sourceforge.net/. This contains the patch utility among other things, and you will need to extract the content to a folder—the patch.exe file will be within the usrlocalwbin folder in whichever directory you extracted the files to.
The patch.exe file can now be used just like any other command-line utility. We have already used the mysql command utility several times, so you have some experience with this. The general syntax when using patch is as follows:
C: patch [options] [originalfile [patchfile]]
In this case the originalfile is the file to which the changes should be applied, and patchfile is clearly the patch file that contains the changes to be implemented. There are a host of options that you can look through, so check out the man page for the patch before working with it. You can find one at http://www.hmug.org/man/1/patch.php. A typical command might look something like this (of course, you need to ensure that you enter the correct file paths to your files if you are not working in one directory):
C:patch buggy_code.php buggy_code.patch
Now there is an important path-related issue that needs to be resolved here. If you would like to use patch from anywhere on the command line, you need to add its file path to your Path system variable—otherwise, you would have to navigate to the usrlocalwbin folder on the command line before using patch each time (you could alternatively add patch.exe to a folder already in your Path, but it is probably better to keep everything separate).
- Open up the Control Panel and click on System.
- Click on the Advanced tab and click on Environment Variables
- Add the path to the
patch.exefile into the Path environment variable in the System variables section as shown here:
- Once you are done, click OK.
Note that each path set in the Path environment variable is separated by a semi-colon. You must ensure that you do not change anything other than adding the single path; otherwise you may well break other important applications.
With that done, you now have access to the patch utility from anywhere on the command line. The important question now becomes whether or not to use a patch file. How do you know whether you need a patch? The answer to this really lies in searching Drupal for an answer to any given problem you might have—often there are patches submitted on the module's download page, so make sure you search through this as well as look through the forums for more info.
Finally, just because a patch has been made available does not necessarily mean that it will fix the problem. Often, you will find that patches themselves create other problems. For example, viewing the issues page for the Flexinode module shows the following:
At the time of writing, there were several patches available for several different things. Depending on what you needed done, you would:
- Find the relevant patch file.
- Download it to your machine.
- Use the patch utility to implement the patch.
- Attempt to use the updated code.
Make sure that it is in fact a patch file you are downloading and not an entire file that is intended as a replacement. Patch files will more often that not end with a .patch extension. As mentioned, the best way to avoid problems is to only use code that has been proven to be reliable, failing which, it is more than likely you will need to practice implementing patches—enjoy!