wp hatch

← Writing

Build an Online Community Website: WordPress + Discourse

If you want to build an online community website that people pay for, sign in to and come back to, the hard part isn't installing software. It's the handful of decisions that are expensive to change later: where the forum lives, who owns a member's identity, what payment actually buys, and how two applications end up feeling like one site.

This is the how-to. It covers the stack we'd choose for a membership community, which is WordPress for the site and membership plus Discourse for the conversation, along with the decisions in the order they bite and the build steps in the order we'd do them. We run a community on exactly this stack, Board Rats, our own property rather than client work. The story of how it runs, including what went wrong, is in the Board Rats case study. We won't retell it here. This post is the plan you'd use to build your own.

Start with what members will do there

Before any software, write down three answers. Most of the technical decisions below fall out of them.

  1. What is the conversation for? A community where members talk to each other is a different product from a content library with a comments box. If the conversation is the reason people show up, you need a real forum. If it's incidental, you may not need a forum at all.
  2. What does payment buy? Either it buys access (you have to pay to read or post) or it buys extras (an ad-free view, a badge, perks) while the conversation stays open to anyone with an account. This one choice decides how fragile your integration is allowed to be, so make it on purpose.
  3. Who operates it after launch? Two applications means two things to update, monitor and back up. If nobody is on the hook for that, a hosted community platform's monthly fee is buying you something real.

If you're still deciding between community, content and hybrid models, our membership site development guide covers that choice and the systems behind it. This post assumes you've landed on a community, with WordPress handling membership.

Why WordPress plus a dedicated forum

The shape we recommend splits the work along a clean line.

WordPress runs the public site, the content, the membership levels and the billing. It's where a member signs up, pays, manages their account and reads what you publish. It stays the system of record for who someone is and what they've paid for.

Discourse runs the conversation: threads, replies, moderation, notifications and member profiles. It's a forum by design, so you aren't bending a content system into a discussion tool.

What makes the pairing work is the integration, not either application on its own. Discourse supports single sign-on through DiscourseConnect, and the wp-discourse plugin lets WordPress act as the identity provider. Membership levels in WordPress can be mapped to groups in Discourse. Those two capabilities, one login and levels that show up as groups, are what we'd judge any forum on. A long feature grid matters less than how cleanly the forum joins your membership system.

The stack decisions, in the order they bite

1. Subdomain or subfolder

The forum can live at forum.yoursite.com or at yoursite.com/forum. A subdomain is the simpler install, and it's what Discourse's own community generally recommends. A subfolder keeps the site and the forum on one hostname, and on Board Rats we chose it for that reason. That was a judgment call, not a measured search win.

Choose with your eyes open. A subfolder install took us extra platform-specific workarounds that the original plan didn't anticipate. The forum's path is also fixed when the Discourse container is built, so changing it later means a full rebuild. Whichever you pick, write down the way back. We kept the subdomain as a documented escape hatch, and having it written down made the harder option easier to commit to.

2. Who owns identity

Make WordPress the single source of identity. With WordPress as the DiscourseConnect provider and Discourse's own login switched off, every forum account is a WordPress account first, and members have one password. You get exactly one place to answer "who is this, and what have they paid for?"

One login isn't the end of it. Decide what happens when the two sides drift: when a member deletes their WordPress account, or renames themselves in the forum. Pick a direction of sync for each field before launch, not after the first support email.

3. How membership reaches the forum

Membership levels need to show up in the forum as groups, so that the forum can treat paid members differently. That sync is code you'll own, and two placement rules save trouble:

  • Put it in a must-use plugin, not the theme. The bridge between membership and forum is infrastructure. A must-use plugin survives a theme switch and can't be deactivated by accident from the plugins screen.
  • Treat the names it depends on as part of the deployment. If the sync finds forum groups by name, renaming a group in the forum admin silently breaks it. A rename becomes a change you plan and ship, not a settings tweak.

4. What payment controls

This is the decision from the first section, made concrete. If payment gates posting, every sync failure locks a paying member out of the thing they came for. If payment buys extras, the worst a failed sync can do is show ads to someone who paid to hide them. Discourse's built-in trust levels can handle "any registered account can post", which leaves your membership groups free to act as signals rather than gates. The case study covers why Board Rats moved from gating to extras.

5. Routing (subfolder installs only)

With a subfolder, something in front of both servers has to send /forum/* to Discourse and everything else to WordPress. On Board Rats that's a small Cloudflare Worker. Two lessons from setting it up:

  • The Worker needs a hostname for the forum server, not a bare IP address. Plan a separate DNS name for the forum's origin.
  • Make the hop to the forum HTTPS end to end. When the router talks to the forum over plain HTTP, Discourse's secure session cookie can be dropped on the way back. Single sign-on then fails with an error that looks like a configuration mistake but isn't one. We lost time to exactly this.

6. Hosting

Discourse runs as its own application, so plan on two servers, or WordPress on whatever host you already use plus a separate forum server. Board Rats runs each on its own server. That's more control and more responsibility, and it's only a good trade if someone is genuinely operating both.

How to build an online community website, step by step

With the decisions made, this is the build order we'd follow. The order matters: each step is easier to test when the one before it is already solid.

  1. Write down the access rules. Who can read, who can post, and what each membership level adds. One page. Every later step tests against it.
  2. Build the WordPress side first. Set up the site, the membership levels and payments, and get signup, upgrade, downgrade and cancellation working before the forum exists. Membership bugs are much easier to find without a second application involved.
  3. Install the forum at its final address. Subdomain or subfolder, decided above. Don't install at a temporary address with plans to move it later, because moving it is the expensive part.
  4. Wire single sign-on. Make WordPress the provider, turn off the forum's own login, and test with a brand-new account in a private browser window, not your admin account.
  5. Add the level-to-group sync. Put it in a must-use plugin. Then walk every membership change through it: a new member, an upgrade, a downgrade, a cancellation and a deleted account. Check the forum after each one.
  6. Route and verify (subfolder). Confirm that forum assets load from the forum path, that a login made on one half holds on the other, that the full sign-in flow completes end to end, and that live updates in the forum keep arriving.
  7. Make the two halves look like one site. Keep one set of design tokens (colors, type, spacing) and mirror it into both the WordPress theme and the forum theme, with a test that fails if the copies drift. Treat a change that lands on one side only as unfinished.
  8. Set up deploys before launch, not after. Run tests on every pull request before anything merges. Know that the two halves usually deploy by different routes. On Board Rats the WordPress theme ships when a pull request merges, and the forum theme is pushed separately. If your theme depends on code in your must-use plugins, deploy the plugins first.
  9. Launch, then operate. Updates verified against the sign-in and checkout flows, backups you've actually restored, and someone reading the forum's moderation queue. Our guide to WordPress maintenance covers what that should include.

What this stack costs you to run

We won't quote a price for a community build, because no two do the same work. Scope drives it: how many membership levels, how much the forum has to do, how much content moves in.

The cost that surprises owners is ongoing, not upfront. You're running two applications, so you have two update cycles, two things to monitor and two sets of data to back up, plus the integration between them, which is yours alone. Budget for operations from day one. If you can't, that's a strong signal that a hosted community platform suits you better. We'd rather tell you that before you build than after.

When not to build it this way

This stack earns its complexity when the community is central to the business, you want to own your member data and payment relationships, and someone will operate it. It's the wrong call when:

  • Nobody will operate it. An unmaintained two-application stack is a liability, and a hosted platform's operating floor is worth paying for.
  • The conversation is incidental. If members mostly come for content, build the content site well and skip the forum until people ask for one.
  • You need it live this week. The decisions above take time to make well, and rushing the subfolder, identity or sync choices is how you end up rebuilding.

FAQ

How do I build an online community website?

Decide what members will do and what payment buys, then pick a stack. For a membership community we use WordPress for the site, membership and billing, and Discourse for the forum. Build the WordPress side first, install the forum at its final address, wire single sign-on with WordPress as the provider, sync membership levels to forum groups, and verify the whole sign-in flow before launch.

Do I need a separate forum, or can WordPress do it on its own?

It depends on how central the conversation is. If members come mainly for content, a forum may be more than you need. If the conversation is the product, we use a dedicated forum, because it's built for threads, moderation and notifications, and judge it on how cleanly it integrates with WordPress membership.

Should only paying members be able to post?

Only if gated participation is genuinely what members pay for. Letting payment buy extras instead, such as an ad-free view or a badge, keeps the conversation open and makes the membership-to-forum sync far less fragile, because a sync failure can no longer lock a paying member out.

What should I test before launching a community site?

Test sign-up, upgrade, downgrade, cancellation and account deletion, and check the forum after each one. Sign in with a brand-new account in a private window, confirm the login holds across both halves of the site, and confirm the forum's live updates work through your routing.

Planning a community?

If you're planning a membership community on WordPress and want a team that runs one rather than just building them, get in touch. We'll tell you plainly if a hosted platform would serve you better. You can also see our work first.