How to build a roleplay or gaming forum with XenForo 2.3

A roleplay or gaming forum is not a dark skin and a Discord widget. It is a tree of rooms, a gate, a directory, a handful of facts about each player, and a ladder that does not pretend to be a shop. XenForo 2.3 already has those parts. The work is deciding which job each part owns before you create the twentieth “General Discussion” node.

This is not the whitelist article, not the server listing article, and not the custom user fields piece. Those own one shelf each. This one is the cupboard: how a game community hangs those shelves so a stranger can apply, find a server, pick a character name, and still know where lore lives.

If you arrived from an old Roleplay, Roleplay Dark, or Roleplay Light product page, stay. Those were skins. A dark gaming look is a style variation problem, not a product. The architecture below works on the Default style. Paint after the tree is honest.

Four jobs, four tools

Say “gaming forum” and five products answer. Mix them and you will build a directory that is also an application form that is also a lore wiki.

Job	What the member wants	Stock shape	Owned by
Play / lore room	A place to post as a character, talk patch notes, or argue the map	Categories + forums, some Private	This article + nodes
Get in	A human yes/no on a character or a FiveM slot	Apply forum + Whitelisted secondary group	Whitelist
Find a server	Connect string, version, whitelist flag	One directory forum + prefixes + thread fields	Server listing
Know who is talking	Character name, region, faction	Custom user fields	User fields

Discord and ranks are optional fifth and sixth jobs. They are not the tree. The Discord article is OAuth, webhooks, and [8WR]. The ranks article is trophies, the title ladder, banners, and promotions. Link them after the rooms exist. Do not start with either.

A landing page that says “apply, then play” is a campaign page or a portal you send. It is not a substitute for the tree.

Build the tree before you invent rooms

Official node types still hold: Category, Forum, Link forum, Page, plus the unofficial fifth — Search forum. The nodes article already told you to stop at two public levels and to pick the type before the icon. A gaming board fails that rule in a specific way: one category per game, plus a leftover “Off-topic,” plus a staff dump, plus three lore forums nobody can tell apart.

A tree a stranger can scan in ten seconds looks like this.

Category: Start here

Public. One screen of orientation.

Node	Type	Why it exists
rules	Page	The contract. One page. Not a thread that drifts
how-this-works	Page or a short Forum	Apply → wait → play. Link the apply forum. Do not paste the application here
introductions	Discussion forum	First post that is not an application. Staff answer it

Turn Display in the node list off for a page you only reach from navigation if the index is already busy. The node still has a URL. The onboarding plan owns the first-week copy. This category is where that copy lives.

Category: The game (or The setting)

This is the product. Name it after the world, not after “Forums.”

Node	Type	Who can see it
announcements	Article or Discussion	Everyone who can see the category. Staff post, members comment
general	Discussion	Public chatter that is about the game, not in-character
lore	Discussion or a Page plus one discussion	Public reference. Lock the “canon” threads if staff own canon
play	Discussion, Private node	Only Whitelisted (plus staff). In-character or in-game talk
after-action	Discussion, optional Private	Session reports. Only if you actually run sessions

One game, one play forum, until that forum is noisy enough to split by region or faction. A play-eu and play-na pair is two private nodes and two permission overlays. Do not create them on day one because a custom field named region exists. Split when staff can no longer moderate one room.

If you run two games, two categories. Do not nest Game B under Game A. Parent View still wins: a member who cannot see the parent never sees the child.

Category: Directory

Only if you list other servers, or more than one official shard.

One Discussion forum. Prefixes and custom thread fields carry the connect string. That is the entire listing article. Do not hang the whitelist form off a listing thread. A prefix that says “whitelist required” is a label. The application is a different node.

Category: Support

Public enough that a banned or not-yet-whitelisted person can still ask why the launcher fails.

Node	Type	Notes
tech-support	Question forum	Mark a solution. Not a dump of discussions with a hoped-for badge
bugs	Discussion or Suggestion	Suggestions if votes should change the sort. Bugs if staff will close them
appeals	Discussion, often Private to staff + the author workflow	If “only author + staff” is the product, stock XenForo cannot hide other threads. The whitelist article already said so

A help page under /help/getting-started is the other half of Support. Official help pages are not nodes. They live in the Help manager. Use a Link forum if you truly want that URL in the tree. Do not clone the rules onto both a page node and a help page and then forget which one you edit.

Category: Staff

Private node on the category. View node = Yes on Administrative, Moderating, and any custom staff group. Official premium-forum walkthrough: do not forget staff. A sold or gated room staff cannot open is an unmoderated bunker. The permissions primer is the Yes / No / Never map; this article will not re-teach it.

Children: ops, applications-notes, ban-reviews. Node-specific moderators on The game are how FiveM staff stay out of billing. They inherit downward. They are not a substitute for Private.

Permissions: Registered stays primary

Official groups chapter, the sentence every gaming board tries to dodge: every registered human — including admins, moderators, and the person you just approved — keeps Registered as primary. Whitelisted, Storyteller, GM, Subscriber are secondary.

What goes wrong when you “promote” someone by changing primary to Whitelisted:

• Every add-on that assumes Registered as the baseline now has two baselines
• Analyze permissions becomes a novel
• A later promotion that removes Whitelisted can leave them with a primary you did not mean
• The configuration mistakes article already listed this as item one because it is still the ticket

Fix: primary back to Registered. Put the key on a secondary group. Groups & permissions → Analyze permissions as that user, on the play node. You want View node = Yes coming from Whitelisted, not from a leftover user permission.

Private node only clears baseline View. Other permissions still inherit. If Registered has Post new thread = Yes on the parent and you only Private the child, an approved member can post; a guest still cannot see the row. Test three sessions after every overlay: guest, fresh Registered, same account after you add Whitelisted.

Do not use Never on Registered for play. Never cannot be overridden by a child or by Whitelisted. Private plus a Yes on the extra group is a room. Never is a lock.

The gate is a whitelist, not a promotion

A whitelist is a person who read the answers and said yes. Groups & permissions → User group promotions is a ladder. Official promotions: hourly cron, recently-active users only, empty criteria never award, disable does not demote.

Use promotions for “has an avatar,” “posted 30 times,” “registered a year.” Use a human for “this character sheet is not a meme and this Discord handle is real.” There is no official criterion for “thread in forum apply has prefix Approved.” If you try to fake the interview with “posted at least 1 message,” you will whitelist everyone who sneezed in Introductions.

The whitelist article owns the apply forum, prefixes (Pending / Interview / Approved / Denied), custom thread fields (backstory, age band, hours available), and the Monday-morning review. Plug it in as a public or staff-only apply node under Start here. Then:

1. Applicant posts in apply.
2. Staff decide in the thread.
3. Staff add Whitelisted on the profile’s secondary groups. Changing the prefix does not add the group. There is no stock listener.
4. Staff Analyze permissions on play.
5. One reply: “You are in. The Play forum is on the list.”

Revoke is the inverse of step 3. Banned is not un-whitelisted. A ban is a separate tool. Do both if they are done.

Privacy: stock XenForo will not hide other applicants from each other. If Registered can View apply, they can read every visible application. The four honest policies are in the whitelist article (public queue, never-approved threads, staff-only plus a conversation, or an add-on). Pick one and write it in the forum description. Do not ask for a legal name, a phone, or a school. Age band, not date of birth.

The directory is a listing, not a browser

XenForo does not query FiveM, Minecraft, or a Discord invite. It stores a declaration. The server listing article is prefixes, custom thread fields, and optional Resource Manager. Use it when members need to find a server. Skip it when you run one official shard and the connect string belongs on a Page.

A listing thread can carry a Whitelist prefix so strangers filter “EU + whitelist.” It must not be the application form. Two forums, two jobs.

If you later want live player counts, you are buying or writing an add-on. Be honest on day one so members do not treat a stale “Online” prefix as telemetry.

Fields: the character, not the sheet

Official Users → Custom user fields: an alphanumeric ID you cannot rename, then either a text family or a choice family. Display with messages or in profiles. Admin edit-user includes all of them. Contact-classified fields sit under Additional contact.

The fields article already named the eight that earn rent. On a gaming or RP board, four of them do almost all the work:

ID	Family	Where it prints	Consumer
main_character	Single-line text	With messages	“Who is this” while you read a post
region	Choice (eu, na, sa, af, as, oc, other)	Profile, searchable	Notices, promotions, member stats
faction or home_server	Choice	Profile, maybe one chip with messages	Filters. Free-text class names become “mage” / “Mage” / “frost mage”
discord_handle	Single-line text, contact	Profile, not next to every post	Fallback when you do not run Discord OAuth

Do not put the novel on the profile. A 400-word backstory is a thread field on apply, or a post in lore. Official user-fields page does not document every widget the ACP might show. It names text versus choice, editability, and display. That is enough.

Criteria: User field criteria sit on Search for users, Member statistics, Notices, Contact users, and promotions. A notice “EU maintenance Saturday 02:00 UTC” targeted at region = eu is the entire feature. Official promotions reminder: the hourly job only processes recently-active users. A region change on a lurker does nothing until they come back. Whole-register flips are Users → Batch update users.

Template path for the current visitor:

{$xf.visitor.Profile.custom_fields.fieldId}

Official note: a different variable is needed for the poster. If you paste the visitor form into message_macros you will print the reader’s character on every post. Prefer the field’s own display switches before you touch a template. Outdated templates after upgrade are a merge you will hate.

staff_notes as multi-line, admin-only, never public, never searchable, is the “spoke to them about the 12 May incident” box. The moderation article owns warnings. This field is the one-line memory warnings do not store. If the ACP will not hide it from the owner, do not put anything here you would not say on a staff forum.

Do not store a listing’s IP on the member. That is a thread field. Do not store “is VIP” as a checkbox you read in a template. VIP is a secondary group, usually from a user upgrade or a promotion.

Discord is one job

Stock 2.3 Setup → Connected accounts does not list Discord. Official 2.3 does name Discord as a place webhooks can notify. That is the honest split:

Job	Stock?	Typical extra
Announce a public lore thread in a Discord channel	Almost — Setup → Webhooks can fire thread_insert; Discord wants its own JSON	A formatter, or an add-on that posts Discord-shaped messages
Log in with Discord	No	A Discord connected-account add-on, or [8WR]
Map Whitelisted to a guild role	No	[8WR] Discord Integration

The Discord article is the integration. This article’s rule: pick one job for launch. A board that requires Discord login, syncs every group, mirrors every post, and embeds chat on the first screen has four products and one outage.

Do not make Discord the only door. Official connected-account tests fail first on Board URL. A whitelist that can only be completed in Discord is a second site you do not moderate. Put the handle in discord_handle if you need a human string. Put the interview in the apply thread so the next moderator can read it.

Voice is not a XenForo node. A Link forum to the Discord invite is fine. A page that says “we also have a Discord” is fine. A requirement that every lore post be mirrored is how you kill the forum you just built.

Ranks are not a shop

XenForo already has ranks. They are named like an admin: trophies, a user title ladder, user banners on a group, and user group promotions. The ranks article is the design. On a gaming board the usual own-goals are:

• A trophy named “Regular,” a promotion named Regular, and a ladder row “Regular” — three Regulars
• A Storyteller banner group that also has View node = Yes on play, so taking the banner off locks them out
• Trophy points treated as a currency. Trophy points are not spendable. A credits economy is a later, different product

Ship five trophies (first post, first reaction, 30 posts, a year, first approved application if you can criteria-match something honest) and one New member banner you promote off after a week. Stop until people come back without them. The engagement article already said that. A GM title is a custom title or a banner on a staff group, not a trophy you cannot revoke.

Official trophies: once awarded, not revoked. Delete the trophy to pull points from everyone. A “has avatar this week” trophy is the wrong tool. That is a promotion.

Display styling priority — title override, username CSS, banners — lives under Setup → Options → User options → User banners. If two groups both print a chip, the priority number decides who wins. Put Whitelisted below Moderating. Members should not look more staff than staff.

The look is a style problem

A dark, high-contrast “gaming” palette is Appearance → Styles. Official style properties: Color palette plus a Light / Dark style-type switch that tells intensify/mix which way to push a colour. 2.3 community practice (not the short official styles page): open the style, enable variations, and keep two palettes on one style. The style chooser and the light/dark switch are different gadgets. You do not need a third-party theme switcher for this.

Historical shop pages sold Roleplay, Roleplay Dark, and Roleplay Light as if the skin was the community. It is not. Work in a child style. Put experiments in extra.less. After any upgrade, look at both variations. Hard-coded #111 does not flip. Official xf-intensify / xf-diminish do. The 2.3 upgrade article owns the merge. The later theme-customization articles own deep paint. This one stops at: do not buy a product to get a dark header.

Per-node icons can help a hub with twenty game rooms. A support community with six forums looks calmer with one read/unread pair and strong titles. 2.3 icons are SVG sprites. Raw content: "\f019" from a 2.2 extra.less is how you get a missing glyph. The nodes article already lost that war.

First screen and first week

Do not steal Setup → Options → Basic board information → Index page route on week one unless the whole site is “apply then play.” Forum-list widgets stop running on / when you move the index. A portal of three blocks is enough: New posts from announcements, a short HTML “how to apply,” Members online. A campaign landing page is a page node you send from ads, not a week of index-route theft.

Notices with user-field criteria beat a banner template. Maintenance for region = eu. “Applications closed this weekend” for everyone. Dismissible. One week.

Onboarding is still a human answering the first post. The 30-day plan does not change because the topic is a game. A whitelist that dumps approved members into an empty play forum is a locked empty room. Seed three lore threads, one “what are you playing this week,” and a staff character who posts like a member.

Week-one map: how-this-works and the apply form live on day 1; introductions answered in-thread by day 3; first lore thread and announcement by day 5; a non-staff play thread by day 7. Staff review the first Pending application the same day it lands, never set Approved without the group, and Analyze permissions again after any overlay tweak. If day 7 still has zero approved members, the problem is the form or the review SLA, not the skin.

Moderate new threads on apply if the queue is public and you do not want half-finished sheets on the index. Do not moderate the whole tree. The 2.3 approval queue is a page at a time. The moderation article owns that queue. This board’s extra risk is applications that contain PII. Delete the field, not just the post, if you asked for too much.

A worked Monday

You run one official RP shard and a small directory of community FiveM rooms.

1. Forums → Nodes. Create the five categories above. URL portions: start, setting, directory, support, staff.
2. Create play under setting. Permissions → Private node. View node = Yes on Administrative, Moderating, and a new group Whitelisted. Leave Registered and Unregistered / Unconfirmed alone.
3. Create apply under start. Discussion. Prefixes Pending / Interview / Approved / Denied. Thread fields: character_name, age_band, availability, backstory. Moderate new threads only if the queue must stay invisible.
4. Create servers under directory. Prefixes Minecraft / FiveM / Discord. Thread fields: connect string, version, region, whitelist yes/no. Follow the listing article. Do not put an apply form on the first post.
5. Users → Custom user fields. main_character (text, with messages), region (choice, profile + search), discord_handle (contact, profile only). IDs you would type in a template.
6. Groups & permissions → User group promotions. One promotion: add New member styling group when registered fewer than 14 days. Do not point it at Whitelisted.
7. Communication → Notices. One notice for region = eu when you have a maintenance window. Not before.
8. Setup → Webhooks only if you already have a Discord channel that should hear thread_insert on announcements. Otherwise skip.
9. Three test accounts. Guest cannot see play or staff. Fresh Registered can post in apply and introductions, cannot see play. After you add Whitelisted, they can. Analyze permissions on all three.

That is a community. The skin can wait.

What not to build

A node per class, faction, and timezone. You will moderate empty rooms. Prefixes and a faction field filter one forum. Search forums can view “threads tagged EU.” They are not a home.

A character database add-on on day one. A user field plus an application thread is a character.

Discord as required login. Official connected accounts already exist for other providers. Discord is not one of them. A required Discord add-on is how a guild outage becomes a forum outage.

Credits for whitelist. A user upgrade can sell Subscribers on a private node. That is a receipt. A human interview is a decision. Two doors, one group, no audit trail — unless “paid or interviewed” is really the rule, written down.

A theme that forks PAGE_CONTAINER. Official 2.3 CSS is unbundled. Cloning the container for a hero is how the next upgrade becomes a white screen. The mistakes article already named that row.

PII you cannot defend. Official Users → Data portability XML includes all custom user field values. The member-list CSV does not. If a field matters legally, confirm it appears in an export you actually run. If you do not have a deletion process, do not have the field.

Checklist before you announce

• The public tree is two levels. A stranger can name the rooms from the titles.
• play is Private. Staff can View. Registered cannot. Whitelisted can.
• Primary group is still Registered on a staff account, a GM, and you.
• apply and servers are different forums. Prefixes do not add groups.
• Character name is a user field. Backstory is a thread field. The connect string is a thread field.
• region is a choice. You can target a notice with it.
• Discord is at most one job (announce, or login, or role sync). Not all three on launch day.
• Ranks do not grant View on play.
• Both style variations are readable. You did not buy a Roleplay product to get there.
• Three sessions: guest, fresh Registered, approved. Analyze permissions on play and staff.
• Cron last-run is today. Promotions and trophies will not fire if Tools → Cron entries is dead.
• You can name the first three threads in play. If you cannot, the room is not ready.

Takeaways

• A gaming or RP board is a tree, a gate, a directory, and a few fields. Themes are paint.
• Keep Registered as primary. Whitelisted is a secondary key to a Private node.
• Link the whitelist, listing, and fields articles — do not rebuild them inside one node.
• Discord and ranks are optional jobs. They are not the architecture.
• Historical Roleplay skins were products. Dark mode is a 2.3 style variation.
• Prove the gate with three accounts before you post the invite.

Build the cupboard. Then put things on the shelves. Then, if you still hate the header, change the palette.