Reporting Issues

Found a bug or have an idea? Thank you! Please follow these rules so every report can be handled quickly and nothing is discussed twice.

1. Search first

Before you open anything, look through the existing issues: open and closed issues.

• Search for the error message, the admin section (e.g. checkout, invoice, shipping) and a few words that describe the problem.
• Check closed issues too: the problem may already be fixed in a newer release, or answered.
• Read the Troubleshooting page.

Already reported? Do not open a new issue. Add a 👍 reaction to the first post (that shows how many people are affected) and only comment if you have new information: another version, other steps that trigger it, a log line. Comments like "same here" or "+1" notify everyone without helping; use the reaction instead.

2. Bug reports

Open a bug report only for something that does not work as described. One issue per problem.

Include:

	Example
Version and channel	v1.5.0 stable or v1.6.0-beta.2 beta (Settings → System & Updates)
What you did	Numbered steps that reproduce it, starting from a page in the shop or admin
What you expected	"The order shows as paid"
What happened instead	"The order stays pending", the exact error message, a screenshot
Logs	The relevant lines of docker compose logs backend (or storefront, admin, updater)
Setup	Built-in HTTPS proxy or own reverse proxy, payment provider in test or live mode

Never post private data. Remove passwords, API keys, tokens, the content of .env, customer names, addresses and email addresses from logs and screenshots before you upload them. Security problems are not reported in public issues: see Security and contact the maintainer privately.

3. Feature suggestions

Ideas for new features or changes go into a feature request, also after searching first. A good suggestion explains:

1. The problem, not only the solution: what are you trying to do, and what stops you today?
2. Your proposal: how it could work in the shop or the admin.
3. Alternatives you considered or use today (workarounds, other settings).
4. Who it helps: only your shop, or shops in general (e.g. a legal requirement in your country, with a link to the law).

One idea per issue: several ideas in one issue cannot be planned or closed separately.

If the same idea already exists, add your 👍 and, if your use case is different, describe it in a comment. Requests with many reactions and a clear use case are planned first. Not every idea is implemented: the maintainer decides what fits the shop, and a request may be closed with an explanation.

4. Want to implement it yourself?

Great, but comment on the issue before you start, describe how you would build it and wait for an answer. That avoids work on something that is already in progress or will not be merged. Pull requests go to the beta branch, not to master (see Release Channels).

5. Testing betas

Bugs found in a beta are especially welcome. Mark them with the beta version (e.g. v1.6.0-beta.2) in the title, so they can be fixed before the stable release.