How we handle Bug Reports
This document explains how we manage Bug Reports regarding the WHMCS Software.
WHMCS is a powerful and feature rich product used by tens of thousands of companies, of varying sizes, all around the world. From time to time, users may identify reproducible examples of unintended behaviour and we encourage users to report these using the Bug Report form so they can be investigated further.
Making a Bug Report
We welcome Bug Reports via our the form here: https://www.whmcs.com/members/bugreport.php
Tips for Submitting a Good Bug Report
- Clearly explain the problem you are experiencing and how you expected WHMCS to work
- Provide detailed steps of how to reproduce the issue - detailed steps (or even a video!) avoids the need for our team to ask further questions so we can try and reproduce the issue and ensure faster handling of the bug report
- State any relevant configuration option setting values which relate to the feature you're having an issue with
- Provide real world examples where possible
How we handle Bug Reports
When we receive a bug report, we will go through the steps below to verify the issue and where confirmed we will then create a case internally to have the issue investigated further and gather further information.
Once issues have been identified, we will then monitor the issues and gather further information so that our team can consistently monitor and prioritise the issue with the development team.
Step 1: Validation
The first step in our Bug Report process is to attempt to verify the reported issue on our testing environment. This may require us to ask for further details if necessary to enable us to reproduce the issue described.
We will use the details provided to try and replicate the settings used and the steps provided to replicate the issue. Should we confirm the behaviour described, we will then confirm if this is as designed, or if it does indeed represent a defect against how the product is designed to operate.
Step 2a: Issue Confirmed
When we are able to replicate the reported bug and confirmed it is unintended behaviour we will then create an internal bug case with the steps to reproduce, and details of the issue so it can be investigated by our developers.
We will provide the reporter with the case number which will also be shown on future Changelogs once the issue is resolved.
Our team will monitor and review bug reports, ensuring sufficient detail is available for our development team to investigate and resolve the issue, as well as re-prioritising issues based on the impact and prevalence of the problem.
Step 2b: Not Reproducible/Not a bug
When we are not able to replicate the issue described or have determined it is by design, we will then transfer the bug report ticket to our support team to assist the customer further in resolving the issue on their installation or possible ways to achieve their ideal outcome.
Bug Report Status Definitions
Below is a list of all bug report statuses along with an explanation of what they mean.
| Status | Description |
| UNCONFIRMED | All reports start life in this status. At this stage we have not yet reviewed and verified the reported issue. |
| NOT A BUG | We have determined the reported issue is intended behaviour. |
| NOT REPRODUCIBLE | We have been unable to reproduce the issue in our test environment, the ticket will then be transferred to the support team to assist further. |
| CONFIRMED | We have been able to reproduce the issue and have confirmed it is not intended behaviour. We will raise an internal bug report for our developers to investigate further. |
Known Bugs and Hotfixes
When we identify issues between releases, we publish individual patches (hotfixes) outside of the update structure. You can apply these if you are encountering issues.
- For solutions to known problems, see our Hotfixes Forum.
- For hotfixes prior to WHMCS 7.0, see HotFixes.