How to fix just one bug without upgrading
This page requires updating. Please do so and remove this template when finished.
Suppose:
- You are running an older Moodle version.
- You are experiencing a particular bug.
- You have searched in the tracker, and found that your problem is MDL-abc, and that it has been fixed in the latest version.
- For some reason, you cannot upgrade your whole site, even though the latest version probably has security fixes.
This page explains how to extract the bug fix and apply it to your site.
Finding what has changed
In the tracker, at the top of the comments section (underneath the description) there are a row of tabs: All, Comments, Change History, Version Control.
The information we want is on the 'Version Control' tab (and also in the all tab). So click on it. You will see something like:
What you see there is:
- A summary line "Someone committed n files to 'Moodle CVS' on branch BRANCH_ID - date.
- Some text (in this case "forum subscriptions: MDL-14876 - followup - use the right table prefix ..."). This is the comment that the developer made while committing their changes to the version control system, to explain what they done.
- A list of files, showing what changed.
The important part here is the (+n -m lines) link. This is a link to a patch showing exactly what changed in that file, as part of this commit. The link goes directly to a pretty HTML view of the changes. At the top of that page is a link 'Patch' which goes to a machine-readable version of the same information.
You need to collect together all the changes that relate to the version of Moodle you are on. For example, if you are running Moodle 1.9.x, you need to look for all the "on branch 'MOODLE_19_STABLE'" changes, and gather together all the changes to all the files.
Back everything up
You are about to edit the code of your Moodle site. Something might go wrong. You must make a full backup. The recommended approach is:
- Copy the entire site to a test server.
- Practice making the changes to the copy running on the test server.
- Test, to ensure both, that the changes you made have fixed the particular problem you were trying to fix, and also that the changes have not broken anything else.
- If everything is OK, make a full backup of your live system.
- Then make exactly the same changes to the code, that you made on your test server, to the live server.
- Test again, to make sure the problem is fixed, and nothing else is broken.
- Monitor your server logs and help-desk, etc. more carefully for the next few days, in case they show a problem that slipped through your testing.
Of course. Sometimes you cannot afford to be that careful, but the above is the ideal, and you should at least be aware when you are cutting corners compared to that.
Making the same changes to your site
Now you know which files have changed, you need to make the same changes in your copy of Moodle. There are two approaches:
- Particularly if the changes are small, it may be easiest just to change your copy of the code by hand.
- If the changes are large, you can save the machine-readable patch file (for example, you might save it as mdl-abc.patch.txt). Then, follow the instructions on How to apply a patch to have exactly the same changes made to your version of Moodle.
What can go wrong
Commits without an issue id
If the developer failed to mention the issue id (MDL-abc) when committing their changes to the version control system, then the tracker will not be able to associate those changes with the tracker issue. Of course, developers should always mention the issue id, but sometimes mistakes happen. The other mistake is to typo the issue id, for example to type MDL-14875 when you mean MDL-14876.
This bug fix relies on other changes
Suppose you are running Moodle 1.9.2. Some other bug was fixed in Moodle 1.9.3. And you are looking at a bug that was fixed in Moodle 1.9.4, and you want to apply that second bug fix for your site. It may be the case that that the bug fix in Moodle 1.9.4 relies on changes that were made to fix the other bug for 1.9.3.
In this case, trying to apply the bug fix you are interested in directly to Moodle 1.9.2 will not work.
To minimise the chance of this happening, you need to investigate a bit more.
- In the version control tab of the bug, click on the name of a file (for example, the 'mod/forum/lib.php' link in the screenshot above).
- This will show you the full version log for that file. In fact, you don't want the full log, so
- Near the top of that page, there is a 'Sticky Tag:' select. Change that to say MOODLE_19_STABLE, or whichever stable branch you are interested in. That will then show you only the changes that relate to your version.
- Scroll down the page to find the version of the file you currently have.
- Read through all the changes between that version, and the version that fixes the bug you are interested. You will notice that every time a tracker issue id is mentioned, it is a link to the tracker issue. If necessary, follow the link and read the tracker issue.
Based on all that research, you may be able to determine whether the changes you care about depends on other changes.
As a short-cut, instead of doing the research yourself (or in addition to it) you could try posting in an appropriate forum on moodle.org, asking whether anyone else knows how 'safe' a particular bug fix might be to apply independantly.
Which version of a file do you have?
To find exactly which version of each file you currently have, look inside the file. The first line will probably look like:
<?php // $Id: lib.php,v 1.609.2.89 2009/03/03 06:46:28 dongsheng Exp $
the number there after 'v', in this case 1.609.2.89, is the version of this file. You should be able to match that up with the version numbers in the CVS log.
Final note
Remember that what is described here is really Plan B. Plan A is always to upgrade your entire site to the latest stable version. That will get you all the bug fixes, including all the latest security fixes. However, sometimes the steps here are necessary.
