Case Study: Running Board Rats on WordPress and Discourse

Most of what we write here is advice. This post is evidence. Board Rats is a longboard-surfing community at boardrats.com, and we run it. It has been live since June 2026 and has passed 500 users. It runs on WordPress and Discourse sharing a single domain.

One disclosure first, because our honesty rules require it: Board Rats is WP Hatch's own property, not client work. It became a WP Hatch asset in the August 2026 transfer that moved most of WP Media's portfolio to us. There's no client testimonial at the bottom. What it gives us is a production community where every decision below was ours, and every failure was ours to fix.

We're also leaving some things out on purpose. You won't find paid-member counts or revenue here, because neither has a public source and we don't publish numbers we can't point to.

What Board Rats is

Board Rats is two things that have to feel like one. The WordPress side, at the root of the domain, handles the marketing pages, membership and billing, and a directory of surf businesses. The Discourse side, at boardrats.com/forum, is where the community actually talks.

A visitor shouldn't be able to tell where one ends and the other begins. They sign in once, see the same header and the same colors, and move between a blog post and a forum thread without noticing they've crossed between two applications on two servers. Most of the work went into making that seam invisible.

One domain, two applications

The architecture fits in a paragraph. WordPress runs on its own DigitalOcean server. Discourse runs on a second one. Cloudflare sits in front of both, and a small Cloudflare Worker sends every request under /forum/* to the Discourse server. Everything else goes to WordPress.

Why a subfolder instead of forum.boardrats.com. A subdomain is the easier install, and Discourse's own community generally recommends one. We picked /forum anyway. Our reasoning was search: we wanted the site and the forum to build up one domain rather than two hostnames. That was a judgment call, not a measured result, and we haven't tested the alternative.

It cost us. A subfolder Discourse install needed about ten platform-specific workarounds that the original build plan didn't anticipate, and the forum's path is baked in when the Discourse container is built, so changing it later means a full rebuild. We wrote the subdomain down as a documented escape hatch in case the routing ever proved unmanageable. It hasn't yet, but having the exit written down made the decision easier to commit to.

Why Discourse rather than a WordPress forum plugin. We needed three things: a real forum with threads, moderation and notifications; single sign-on from WordPress, so members have one account; and a way for a membership level in WordPress to appear as a group in the forum. Discourse covers the last two through DiscourseConnect and the wp-discourse plugin, and it's a forum by design. That combination settled it.

One login: WordPress is the identity provider

Members don't have a separate Discourse password. WordPress is the DiscourseConnect provider and Discourse's own login is switched off, so every forum account is a WordPress account first.

This matters more in operations than in the demo. There's exactly one place to answer "who is this person, and what have they paid for?" The two accounts are still kept aligned in both directions. When a WordPress account is deleted, the sync suspends the matching Discourse account, so a member who leaves doesn't linger in the forum as an orphan. When a member renames themselves in the forum, a Discourse webhook mirrors the change back into WordPress, and a check at login catches any webhook that didn't arrive.

Membership: Paid Memberships Pro, synced into forum groups

On the WordPress side, membership runs on Paid Memberships Pro (PMPro), with Stripe handling payments on a Stripe account dedicated to Board Rats. Membership levels map to groups in Discourse, and a small must-use plugin keeps the two in sync when a member's level changes.

Two details about that sync plugin are worth borrowing:

It lives in mu-plugins/, not in the theme or a regular plugin. The sync contract is infrastructure, not presentation. A must-use plugin survives a theme switch and loads before normal plugins, so nobody can deactivate the bridge by accident while tidying up the plugins screen.
It finds Discourse groups by name. Rename a group in Discourse admin and the sync quietly stops adding people to it. We renamed one on purpose, because its machine name would otherwise have shown up in the badge tooltip. Even planned, the rename nearly slipped: a second place in the forum theme still used the old name, and review caught it after the rename was live. Left alone, it would have shown general ads to members who'd paid to switch them off. When two systems are joined by a string, renaming that string is a deployment, not a settings change.

The membership structure has changed once already. Board Rats opened with a free founding level, and when new tiers launched that level was closed to new signups, with every existing founding member kept exactly as they were. Today there's a free tier and a paid tier. The paid tier switches off the site's general advertising and adds a badge next to the member's name in the forum. Our own house ads can still be aimed at paying members when an offer is meant for them.

The decision that changed the most: posting isn't behind the paywall

The original plan put posting behind payment: free to read, pay to post. The sync plugin was built to enforce exactly that, by granting forum posting rights through a paid group.

That isn't how Board Rats works now. Posting moved off the paywall entirely. Any registered account can post, using Discourse's own built-in trust levels, and the paid and free groups became signals for ad-free display, badges and segmentation rather than gates.

The architectural consequence is the part that generalizes. When the sync is a gate, every sync failure locks a real person out of the thing they came for. When it's a signal, the worst a failed sync can do is show ads to someone who paid to switch them off, or leave a badge missing. That's a bug you fix rather than a support fire. If you're building a community with a paid tier, decide early whether payment buys access or extras, because that choice determines how fragile your integration is allowed to be.

Two applications, one look

The hard rule on Board Rats is that the two halves are visually identical. Change the header, the spacing or a card style on one side and you change it on the other in the same pass. A change that lands on only one side is treated as unfinished.

In practice that means one canonical token file, mirrored into the WordPress theme and into the Discourse theme, with a test that fails if one of the core design tokens goes missing from a token file or loses its dark-mode value. The current look came from a reskin that went live in October: a cool mint ground, sea-foam, steel, ink and white; Inter throughout; flat cards with no borders or shadows; and an accent color that's only ever used as a fill. It's never used for text, because as text it would be too low-contrast on the dark theme.

The two halves don't deploy the same way, and that's worth knowing before you plan the work. The WordPress theme ships when a pull request merges. The Discourse theme is pushed with its own deploy script, so merging it doesn't put it live. Any design change touches two pipelines.

Operating it: merging is deploying

On the WordPress side, merging to main deploys. A GitHub Actions workflow syncs the theme and must-use plugins to the server, reloads PHP, optionally purges Cloudflare's cache, and smoke-tests the live homepage.

We'll be candid about how that bit us. For a stretch, the repository's own context file said the deploy was manual. Two pull requests were merged on that stale reading and went live without anyone announcing them. The fix was a working rule we now apply everywhere: check the workflow's trigger, not the document describing it. Docs drift; the on: block is what actually runs.

The rest of the operating story is the same thing we tell membership clients in our guide to membership site development: launch is the halfway point.

Tests run before a merge, not after. For a while the only workflow was the deploy itself, so the test suite existed and nothing ran it before code went live. CI now runs unit and integration suites on every pull request, and branch protection won't let a red one merge.
Deploy order is a correctness issue. The theme calls helpers defined in the must-use plugins. Ship a new theme before its plugins and the site fatals; ship the plugins first and the old theme keeps working. So the plugins go first, and a check in CI guards that order, because no other test would notice if it flipped.
Know where your plugins come from. Paid Memberships Pro is no longer distributed through wordpress.org, so installing it by its directory slug (wp plugin install paid-memberships-pro) fails. A recovery script that assumes every plugin comes from the official directory will quietly leave the membership system out. Restoring it means installing the vendor's download (or its GitHub release), and our restore notes say so.
Own the server if you need to. At the end of May 2026 we moved WordPress from a managed host to a server we run ourselves. That trades convenience for control, and it's only a good trade if someone is genuinely on the hook for operating it.

What we'd tell someone planning a community on WordPress

If you're weighing a community build, here's what running this one has taught us:

Pick the forum for being a forum. Then judge it on how it integrates with your membership system: single sign-on and group sync matter more than a feature grid.
Decide subdomain or subfolder deliberately, and write down the way back. We chose the subfolder for search reasons, and it's harder to run.
Make WordPress the single source of identity. One account and one sign-in, with a sync that keeps the forum's copy aligned in both directions.
Keep the membership bridge out of the theme. A must-use plugin is the right home for an integration that must never be switched off by accident.
Let payment buy extras, not the conversation, unless your business genuinely depends on gated participation. It makes the whole integration less fragile.
Treat two applications as one design system, with tests that hold the two copies together.
Budget for operations from day one. The build is the part you can see. The deploy pipeline, the tests and the restore path are what keep it running.

FAQ

Can you run a forum alongside a WordPress site?

Yes. Board Rats runs WordPress for the site, membership and billing, and Discourse for the forum, on one domain. Members sign in once through WordPress, and their membership level syncs into forum groups. The two run on separate servers, and a Cloudflare Worker routes forum traffic.

Should a community forum live on a subdomain or a subfolder?

A subdomain is simpler to install and maintain, and it's what Discourse's community generally recommends. We chose a subfolder for Board Rats because we wanted the site and the forum on one domain. That was a judgment call on search, not a measured win. It took extra work, and we kept the subdomain as a documented fallback.

Can members log in to Discourse with their WordPress account?

Yes. With DiscourseConnect, WordPress acts as the identity provider and Discourse's own login can be switched off, so every forum account is a WordPress account. That's how Board Rats works, and it gives the community one place to answer who a member is and what they've paid for.

Does Board Rats charge members to post?

No. Any registered account can post. The paid tier switches off general advertising and adds a forum badge. The original plan put posting behind payment, but Board Rats moved away from that. Now a membership-sync problem can't stop anyone from posting.

Planning a community?

If you're thinking about a membership community on WordPress and want a team that runs one, not just builds them, get in touch. We'll tell you plainly if a hosted platform would serve you better. You can also see the rest of our work first.