A good bug description is one of the most valuable contributions there is: it turns one person's problem into a fix for everyone. This page is the community-member view; the full instructions are in When something goes wrong.
Contents
- Is it a bug?
- The right tracker
- The parts of a good bug description
- What never goes into an issue
- After you file it
Is it a bug?
| It is | Then |
|---|---|
| The software does something wrong, and you can make it happen again | A bug: file it |
| You do not know how to do something | A question: ask in the forums (Asking a good question) |
| Someone could see or change what they should not | A security problem: privately to [email protected] (SECURITY.md) |
| An idea for the project, the website or the community | The community issue tracker |
| It works as designed, but not the way you want | Maybe a negative feature: a deliberate behavior, not a bug. Read Negative features before you file it |
Warning
some behavior that looks wrong is on purpose, or open to interpretation. Changing such a negative feature can affect every site that depends on it, so an issue or pull request about it needs a clear justification and may go through several rounds of review before it is accepted. See Negative features.
The right tracker
| Tracker | For |
|---|---|
| se7enxweb/exponential | The kernel, the administration, the bundled extensions, the documentation |
| se7enxweb/exponential-velocity | The Velocity application server |
| The extension's own repository | An extension with its own repository; the Report an error page lists them |
| se7enxweb/exponential-community | The project, website, ecosystem, anything that is not a software bug |
Source: When something goes wrong. More detail on choosing: Which tracker for which report.
The parts of a good bug description
- A title that names the problem, not "It does not work".
- The steps, numbered, from a known starting point.
- Expected and actual result, with the exact message.
- The environment: version, PHP version, engine (Velocity, Apache or nginx with PHP-FPM, FrankenPHP), database,
design. Setup > System information > Copy report as text or
./console exp:info --plain --no-logogive a summary that leaves out passwords, keys and server paths. - Log lines around the time, cleaned of anything private.
- A screenshot if it helps, with no private data visible.
What never goes into an issue
Passwords, keys, session cookies, database addresses, or the personal data of customers or users (When something goes wrong).
After you file it
- Answer questions from maintainers; an issue that cannot be reproduced is often closed.
- If you find a workaround, add it to the issue.
- If you can, send the fix: "With the code installed as Git clones, a fix is a branch in your fork and a pull request
away" (When something goes wrong). Mention the issue (
Fixes #123) in the pull request. - When a release fixes it, confirm in the issue.
Related pages
- Contributing as a community member
- Reporting bugs well
- Testing and reporting bugs
- Reporting problems
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner. Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster. Start with Partners: start here and How to apply.