Support
Support that goes to the right place first.
Three channels, and the one you want depends on what you are looking at. Code in a free plugin goes to GitHub, a paid plugin comes straight to us, and so does everything else.
Start here
Pick the channel
One of these three is yours. Each card links to the detail further down the page.
Public plugin
A bug, a crash or a missing behaviour in one of the plugins we publish openly.
GitHub
Paid plugin
A plugin licensed to you through our registry, such as Last-mile delivery pricing.
Contact form
Everything else
Questions, an existing project, a new brief, or anything you cannot place.
Contact form
Check the documentation first
Installation, configuration, the settings each plugin adds and what changed in the last release. Most of what arrives as an issue is answered there, and reading it first gets you moving in minutes rather than days.
Public plugins
Issues and fixes live on GitHub
Every plugin we publish has its own repository. Report the problem against that repository rather than by email: the discussion then sits next to the code, and the next person with the same failure can find it without asking.
Open an issue on GitHubWhat to put in the report
- 01
Versions
Shopware, the plugin and PHP. A surprising number of reports turn out to be one of the three being older than the plugin expects.
- 02
What you did
The steps that got you there, what you expected, and what happened instead. A screenshot of the result beats a description of it.
- 03
The log lines
The stack trace, or the relevant lines from var/log. Redact API keys and customer data before you paste.
- 04
Whether it reproduces
On a clean install, or only in your project. That one line is often the difference between a day and an hour.
Pull requests
A fix reads faster than a description of one.
If you have already found the cause, send the change rather than the report. You do not need permission to open a pull request, and the commit keeps your name on it.
- 01
Fork
Your own copy of the repository, under your account.
- 02
Branch
One change per branch, named for what it does.
- 03
Test
Cover the behaviour you changed. A fix without one tends to come back.
- 04
Pull request
Opened against main. The review happens in the open, on the diff.
# fork the repository on GitHub, then clone your copy
$ git clone git@github.com:<you>/<plugin>.git
$ cd <plugin>
# one change, on a branch named for what it does
$ git switch -c fix/refund-rounding
# cover the behaviour you changed
$ make test
$ git commit -m "fix: round refunds per currency"
$ git push origin fix/refund-rounding
# then open the pull request against KommandHub/<plugin>The shape of it. Swap the placeholder for the repository you are fixing.
Public plugins only
Paid plugins
Paid plugins are supported by us directly
A paid plugin is licensed to you through our Composer registry, so support comes from us rather than a marketplace. Use the contact form, name the plugin and the version you are running, and we will pick it up.
On a care plan, plugin support is part of it, within your plan's response time.
Response times on a care planEverything else
One form for the rest
Support that is not a plugin bug, and anything that is not support at all, goes through the contact form.
Go to the contact form- General questions about what we build and how we work
- Anything on a project we are already running for you
- A new brief, a quote, or a technical review
- Anything you cannot place — we would rather route it than have you sit on it
Found a security issue?
Do not open a public issue for a vulnerability. Send the details straight to us and give us the chance to ship a fix before it is public.
info@kommandhub.comStill not sure where it goes?
Send it to us and we will route it. A misfiled request beats one nobody sent.