There are five places to get Drupal help, they are good at different things, and asking in the wrong one is the most common reason a question goes unanswered.
This page used to be an essay about community culture. It is now a directory, because "where do I ask" is the question people actually have and a directory answers it in thirty seconds.
Where to ask, and for what
| Channel | Best for | Expect |
|---|---|---|
| Drupal Slack | Quick questions, orientation, "am I thinking about this right" | Fast when someone is awake; not searchable later |
| Drupal Answers (Stack Exchange) | A specific, reproducible problem with an answer worth keeping | Strict formatting; a well-posed question does well |
| A project's issue queue on drupal.org | A bug or feature request in a specific module or theme | The right place for anything module-specific; the wrong place for "how do I" |
| Drupal.org forums | Open-ended or discussion-shaped questions | Slower; quieter than the other channels |
| A paid maintainer or agency | Anything with a deadline or money attached | Fast and accountable, because it is someone's job |
The distinction that saves the most time is the third row against the second. A question about your configuration goes to Stack Exchange. A defect in the module's code goes to that module's issue queue, where its maintainer will actually see it.
How to ask so you get an answer
The difference between a question that gets answered in an hour and one that sits for a week is almost always the question, not the community.
- Give the versions. Drupal core version, the module version, and PHP. Half of all Drupal problems are version-specific and the answer changes with them.
- Paste the actual error. The full message, from the log, not your summary of it. "It doesn't work" cannot be answered.
- Say what you already tried. This stops three people suggesting a cache rebuild.
- Describe the goal, not just the blocker. Frequently the useful answer is that you are solving the wrong problem, and nobody can see that if you only show the symptom.
- Reduce it. If you can reproduce it on a clean install, say so. If you cannot, that is itself information.
When to stop asking and start paying
Free support is people volunteering their evenings. It works well for bounded problems and badly for anything urgent, anything that needs someone to look at your actual site, and anything where being wrong costs you money.
Three signals it is time to hire:
- The site is down or insecure right now.
- You have asked twice and the answers do not fit your situation, which usually means the problem is in the part of your site nobody outside it can see.
- The fix requires a decision about architecture rather than a snippet.
That third one is worth naming, because it is where free advice does the most damage. A working answer to the wrong question becomes technical debt, and unpicking it later costs more than the consultation would have. It is the situation a Drupal architect exists for.
Common questions
Is Drupal support free?
Community support is free and volunteer-run. Paid support exists from agencies, freelancers and some module maintainers, and it is a different product with different guarantees.
My Stack Exchange question was closed. What now?
Closure is usually about the question's shape, not its worth. Add versions, the exact error and a reproduction, then edit it — edited questions get reopened routinely.
Can I file an issue against a contributed module?
Yes, and it is encouraged. Search the queue first; someone has usually hit it. A clear reproduction is the most useful thing you can give a maintainer.
How do I know if a module is well supported before I use it?
Look at the issue queue's recent activity, whether releases are covered by the security advisory policy, and whether the last commit is measured in weeks or years. Usage statistics matter less than whether anybody is home.
If you would rather not do this yourself
Learning to navigate the community is worth it if Drupal is going to be part of your work — the learning roadmap is the wider picture. If Drupal is just the thing your site happens to run on, that time is better spent elsewhere.
For the second case, Drupal services covers ongoing support, and describing the problem is usually faster than posting it and waiting.