Filing bugs and issues

This Article Needs Your Help

Reporting bugs

Well-written bug reports are incredibly helpful. However, there's a certain amount of overhead involved in working with any bug tracking system, so your help in keeping our ticket tracker as useful as possible is appreciated. In particular:

• Do read the FAQ to see if your issue might be a well-known question.
• Do search the tracker to see if your issue has already been filed.
• Do ask on testing forums first if you're not sure if what you're seeing is a bug.
• Do write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test cases, etc. A minimal example that illustrates the bug in a nice small test case is the best possible bug report.
• Don't use the tracker system to ask support questions. Use the joomla forums, or the #joomla IRC channel on freenode for that.
• Don't use the trackers to make large-scale feature requests. We like to discuss any big changes to Joomla's core on the developers forums before actually working on them.
• Don't reopen issues that have been marked "not a bug". This mark means that the decision has been made that we can't or won't fix this particular issue. If you're not sure why, please ask on developer forums.
• Don't use the tracker for lengthy discussions, because they're likely to get lost. If a particular artifcact is controversial, please move discussion to developer forums.

Reporting security issues

Report security issues to security [at] joomla [dot] org. This is a private list only open to long-time, highly trusted Joomla developers, and its archives are not publicly readable.

In the event of a confirmed vulnerability in Joomla itself, we will take the following actions:

• Acknowledge to the reporter that we've received the report and that a fix is forthcoming. We'll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
• Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases.
• Determine a go-public date for announcing the vulnerability and the fix. To try to mitigate a possible "arms race" between those applying the patch and those trying to exploit the hole, we will not announce security problems immediately.
• Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of Joomla! but in some cases it may simply be patches against current releases.