Project* troubleshooting and testing

Troubleshooting

It can be difficult to isolate the cause of an error related to the project* suite of modules (Project, Project releases, Project issue tracking, git, etc.) because these modules are complicated and have numerous dependencies. Because of this, problems that at first glance appear to be caused by project* modules may in fact be caused by another module. Two troubleshooting procedures are given below. The first set of steps should be used whenever possible. However, it is sometimes difficult to start from scratch and reproduce the problem, and so if that is the case try using the second set of troubleshooting steps.

Before starting either of these procedures, it is advised that you first backup both your database and your file system.

Clean install

1. Create a fresh installation of Drupal into a different location than the installation that is causing problems. You should also create a new database for this troubleshooting installation to use. Also download a fresh version of each of the project* modules you are using.
2. Enable the core modules necessary to run the project* modules as well as other core modules that are required to reproduce the problem.
3. Enable the project* modules, one at a time, and after enabling each module test to see if you can reproduce the problem.
4. If, after enabling all of the relevant project* modules, you still cannot reproduce the problem, start to enable other contributed modules you are using on the site on which you have problems. Again, after enabling each module test to see if you can reproduce the problem.
5. As soon as you are able to reproduce the problem, write down the steps you went through and which optional core and contributed modules are enabled.
6. If you are using official releases of any of the project* modules, try downloading the most recent development snapshot for the branch. Test again to make sure that the problem you are reporting has not already been fixed in the development branch of the module.
7. Search the issue queue for the project you think is responsible for the problem you wish to report to make sure that is not already an issue regarding this problem. If not, file a bug report and make sure to include the information you wrote down in step 5 above.

Current install

1. Disable contributed modules on your site one at a time. After disabling each module, try to reproduce the problem.
2. If disabling one of your contributed modules causes the problem to stop, start disabling your other user contributed modules one at a time. After disabling each module, try re-enabling the module that initially caused your problem to stop. If the problem comes back, disable that module again and then move on to disabling the next user contributed module.
3. The goal in this troubleshooting protocol is to find the configuration in which you have as few modules enabled as possible but in which you still see the problem. Finding this configuration makes it easier for others to reproduce your problem and hopefully fix the problem.
4. At this point, follow steps 5-7 from the set of instructions above and report your problem to the appropriate queue.

Testing

Testing patches for the project* suite of modules (Project, Project releases, Project issue tracking, git, etc.) can sometimes be difficult due to the extensive interaction between these modules. Furthermore, since Drupal development and the drupal.org site rely heavily on the project* modules, it is usually a good idea to test new patches on a site installation that mimics the drupal.org site as much as is reasonably possible. The best way to do this is to use the Drupal.org testing installation profile. For further information, see the documentation for the Drupal.org testing profile.

You might also find the Setting up a mail server for development handbook page helpful if you are setting up an environment to test the e-mail subscription features of the Project issue tracking module.