A knowledge base is a set of pages staff can point at instead of typing the same answer. In XenForo 2.3 that set is page nodes (HTML in the node tree — official examples: FAQ, manual, knowledge base), help pages (/help/{portion}, template syntax, optional Advanced mode), and optionally route filters so you can drop the pages/ prefix or nest URLs. An index route of pages/name/ can even make a page the site home. None of that is an articles forum. None of that is a helpdesk.
This is not the news and announcements article. That one is a newsroom: article forums, feature, notices, stickies. A KB article is stable. If you rewrite it every Tuesday it is news. This is also not the portal first screen and not the landing page with one button. A documentation tree can feed those surfaces via a link. It should not become them.
Official sources: Nodes and forums (page node type), Help pages (docs.xenforo.com/manual/communication/help), Route filters, Index page route, Terms and rules. Optional community add-on: Tickets: Help Desk and Knowledge Base, resource 7442 (NixFifty / Naz) — not required. Stock can do a useful KB without it.
Pick the object before you pick the URL
Write the sentence. Then pick the row.
| Sentence | Official object |
|---|---|
| “This is a static chapter of our manual, listed next to forums” | Page node |
| “This is reference that belongs with Smilies / BB codes / cookies” | Help page (/help/{portion}) |
| “Everyone must accept this to use the site” | Terms / Privacy help pages + Terms and rules forcing |
| “This answer started as a 40-reply thread and should become canon” | Sticky + prefix, or (optional) Tickets convert thread → KB article |
| “This is a story that expires” | Article forum, not a page |
| “Guests must file a ticket and staff must SLA it” | Optional Tickets add-on, or a private node + prefixes + conversations |
A board that uses only page nodes will look like a small manual in the forum list. A board that uses only help pages will look like XenForo’s own /help/ index. Most communities want both: help for product-shaped reference (how quotes work, how 2FA works), pages for your lore (how the whitelist works, how the raid calendar works).
Do not build a third CMS. Resource Manager is for downloads. Tickets KB is an add-on product. Articles are news.
Page nodes — the official FAQ / manual / KB
Official node types (four): Categories, Forums, Link forums / redirects, Pages. Pages: “bring general static content into your node tree.” In the ACP you define arbitrary HTML to display. Official use cases, quoted in spirit: frequently asked questions or a manual / knowledge base.
That is the mandate. A page is not a forum. It has no threads. It has a title, a URL portion, a position in the tree, permissions, and a blob of HTML.
Create the tree
Forums → Nodes → Add node. Official recommended shape for any tree is categories at the top, content underneath. For a KB:
- Category:
Handbook(orDocs, orRules and guides)- Page:
Getting started - Page:
FAQ - Page:
Account and security - Link forum:
Report a problem→/help/or your support forum - Forum (optional):
Ask the staff— questions, not canon
- Page:
Pages can nest. Official: every node has one parent and any number of children; nest as deep as you want. Deep nests are how members lose the page. Two levels is a manual. Five is a wiki you will not maintain.
URL portion on a page becomes pages/your-portion/ (friendly URLs on). Name portions like IDs: getting-started, faq, security. You can pretty them later with route filters. You cannot pretty a portion you spelled page3.
Sort the tree with the official drag-and-drop Sort on the node list. Display order exists; Sort is how humans use it.
What goes in the HTML
The page editor is HTML. Official help pages (sibling object) explicitly allow full template syntax because they save as templates. Page nodes are “arbitrary HTML”; community practice is that many boards do use XF template tags in page content. If a tag does nothing on a page node in your 2.3 build, believe the preview, not a blog. Keep the first version to HTML + internal links.
Rules that keep you out of Outdated templates hell:
- Do not paste a second
PAGE_CONTAINER. The node already sits in the site chrome. - Do not hard-code a full custom CSS file into every page. Use the style, or one wrapper class you added in extra.less.
- Do link to other pages with site-relative URLs (
/pages/faq/, or the filtered URL once you add filters). - Do put the date you last verified the steps at the top. A KB that does not admit age is how you document 2.1 on a 2.3 board.
A worked Getting started page is twenty lines: welcome, three links (create account, set 2FA, find the newbie forum), one link to onboarding if you published that process as staff-facing. It is not a 4,000-word essay. Long chapters can be additional pages, not one scroll.
Permissions on pages
Pages are nodes. Node permissions apply. Official: parent View node denied means children are invisible no matter what you set below. Private node hides the page from anyone without an explicit View node = Yes.
Use that:
- Public handbook: inherit Registered/Unregistered View = Yes
- Staff-only runbooks (“how we issue a security lock”): Private node, Yes on Moderating and Administrative
- Subscriber manuals: Yes on the upgrade group, not a custom field check
Analyze permissions as a guest after you add the category. A Handbook category with View = No on Unregistered and Yes on children still hides the children. Set View on the category first.
Node-specific moderators are legal and usually pointless on a page — there is nothing to moderate. Editors are administrators (or a custom admin permission if you created one). Do not give twenty moderators ACP node access because the FAQ typo annoyed them. Give them a staff forum thread: “FAQ change requests.”
Navigation
Official Appearance → Navigation can add a tab that points at a Node (the node plus a popup of its children). That is how Handbook becomes a first-class tab instead of a category people scroll past. The portal article already warned about tabs that fight the Home tab. One Docs tab is enough.
A link forum in the main category list can point at pages/getting-started/ if you do not want the whole tree in the forum list. Official link forums exist for “go here.” Use them.
Help pages — /help/{portion}
Official About help pages: they do not contact users; they impart useful information. A default install already creates:
- Smilies
- BB codes
- Trophies
- Cookies
- Terms and rules
- Privacy policy
Add-ons may add their own help pages. The Help page manager lists them all: add, toggle availability, delete.
This is the right home for “how this software works.” BB codes and smilies are the model. Your additions should feel like siblings: 2fa, pwa-push, warnings, prefixes. Your community law (“we do not post leaks”) can live here or on a page node. Terms/Privacy should stay on the official help pages because Terms and rules forcing is wired to those objects.
Help page editor
Click a title. Official fields:
URL portion. A short string. getting-started → /help/getting-started. This is not a page node portion. /help/ and /pages/ are different trees. You can have both pages/faq/ and help/faq if you enjoy confusing yourself. Don’t.
Title and description. Shown at the top of the page and in the manager.
Display order. Higher numbers appear later in help navigation. Same display-order concept as the rest of XF.
Page content. HTML. Official: full XenForo template syntax is allowed because the page is saved as a template. Conditionals, phrases, {$xf.visitor…} — this is why a help page can say “you are logged in as X” and a naive page node might not.
Advanced mode. Check this to omit the usual HTML block that surrounds help pages. Official: you then have complete responsibility for making the page look like the rest of the site. Leave it off until you have a reason. The wrapper is not your enemy.
PHP callback. Official: for advanced pages, PHP can generate variables for the template. Official: very powerful, not an easy option for non-developers. If you are not shipping an add-on, you do not need a callback. A page that needs a query is an add-on or a forum.
Terms and Privacy are special
Official: forcing acceptance of Terms and Privacy is documented under Terms and rules, not under the help editor prose. You can force agreement again (individually or when the text changes — follow that chapter). Do not replace Terms with a page node. You will lose the force-accept machinery.
Cookie help is also a default page. Privacy legislation talk belongs there and in Privacy, not in a notice that expires on Friday.
A worked help page: PWA push
Title: Push notifications on your phone.
URL portion: push.
Display order: after cookies.
Advanced mode: off.
Content: three headings (Android/desktop, iOS, it still does not work) that restate the official rules from push and email: HTTPS is our problem; Add to Home Screen on iOS 16.4+ is theirs; the browser remember-deny is theirs. Link Setup is not a member-facing word — say “Home screen,” not “PWA setup.”
That page will save more tickets than a Tickets install on a 500-member board.
Route filters — drop pages/ without breaking /threads/
Official Setup → Route filters. Official warning: advanced. Filters can create ambiguous URLs that steal other pages. Test after every save.
A route is the XF-significant part of the URL (threads/example.1/, pages/faq/). Friendly URLs change whether index.php? is visible; they do not change the route.
A standard filter is bi-directional: outbound links become the pretty form; inbound pretty URLs convert back so XF can dispatch. Find route = stock XF route. Replace with = what you want people to see.
Wildcards, official:
{name}— anything except/{name:digit}— digits only{name:string}— anything except/or.
Same wildcards must appear on both sides. Filters match from the beginning of the route and may replace only a prefix. They must start with a route prefix that has no wildcard (nothing wild before the first /).
Incoming URL conversion only = one-way: visiting the replace side redirects to the find side. That is how you retire an old route without renaming the new one.
Official page-node example
Page nodes always generate pages/page-name/. Official hierarchy example:
- Parent
pages/parent/ - Child
pages/child/ - Grandchild
pages/grandchild(as printed)
Filters:
- Find
pages/parent/→ replaceparent/ - Find
pages/child/→ replaceparent/child/ - Find
pages/grandchild/→ replaceparent/child/grandchild/
That is how you drop the pages/ prefix and fake a hierarchy the node tree already has.
Official warning, do not skip: the page name must not interfere with standard URLs. A page portion threads or forums or help or account will steal core routes. A page portion kb is boring and safe. A page portion resources will fight XFRM if you install it later.
Worked safe set for a Handbook category:
| Find | Replace |
|---|---|
pages/getting-started/ |
handbook/ |
pages/faq/ |
handbook/faq/ |
pages/security/ |
handbook/security/ |
Do not add a filter pages/ → `` (empty). Official requires a real prefix on both sides and you will collide with everything.
After saving, click the node in a private window. Click it from the forum list. Click an old /pages/faq/ URL — bidirectional filters should still resolve. Then click /threads/some-thread.1/ and confirm you did not eat it.
Index page route — a page as /
Official Index page route (Setup → Options → Basic board information): default forums/. You may set it to a page node: pages/page-name/ (change the name). Other official examples: recent-activity/, resources/ (XFRM), portal/ (if a portal add-on defines it).
When you change it:
- The old index (forum list or new-posts overview, per Forums default page) moves to its default URL
- Links that pointed at the new index now point at
/ - You must check that
/shows what you expect
The mistakes article already documented the casualty: forum-list widget positions stop running on / when / is no longer the forum list. The portal article told you not to do this by accident. Doing it on purpose for a documentation-first site (a product handbook that happens to have a forum behind a tab) is valid. Doing it because “the FAQ should be the homepage” on a discussion community is how nobody finds threads.
If you only want a Docs tab, use navigation. If you want / = getting started, set the index route and accept the widget move.
A route filter that turns pages/getting-started/ into handbook/ does not automatically change what you type in Index page route. Official index examples use the real route (pages/page-name/). Use that unless you have verified your build wants the filtered form. Test / after both changes.
Stock support without Tickets
Official help + pages + the report system + conversations will run support for a long time.
A pattern that does not need resource 7442:
- Help page
before-you-post— the five checks - Public page node
FAQ— the twenty answers - Forum
Supportwith prefixesAccount,Technical,Other, and a required thread fieldalready_read_faq(choice yes) - Sticky in Support: “If this is a person problem, report the post; if this is a secret, start a conversation”
- Staff private page nodes for internal runbooks
- Reports for rule breaks (moderation)
Guest-facing legal text stays on Help → Terms / Privacy. Cookie banner copy stays on Help → cookies.
When this breaks down: inbound email as the only way customers write, guest tickets without accounts, SLAs, assignment, canned responses at volume. That is the add-on, not another page node.
Optional: Tickets (resource 7442) as a KB factory
Tickets: Help Desk and Knowledge Base — XenForo resource 7442, author Naz (NixFifty line), listed $60, compatible XF 2.1–2.3, requires PHP 7.2+ and Standard Library by Xon. Branding: none listed as forced. This is not stock. Do not install it to write a FAQ. Install it when you need a help desk that can promote answers into a KB.
What the resource page actually claims for knowledge base:
- Convert a forum thread into a public knowledge-base article
- Copy a ticket message into a new article
- KB categories, permissions, attachments, advertising positions
The rest of the product is a helpdesk: email intake, guest tickets, workflows, views, assignment, internal notes, webhooks on XF 2.3+. Useful. Different article (tickets vs conversations) in this series. Here the only sentence that matters: a good thread can become a KB article without you retyping it into a page node.
Use that if:
- Support already lives in Tickets (or will)
- The same three threads are marked “this should be a FAQ” every month
- You will staff categories and permissions for the add-on KB
Do not use it if:
- You have eight static pages and a quiet support forum
- You have not installed Xon’s Standard Library and do not want another dependency
- You thought it would replace help pages (it does not replace Terms forcing)
After a convert, edit the article. A 40-reply thread is not a manual chapter until someone deletes the meandering. The add-on gives you a starting document. Staff still write.
Stock alternative to convert: copy the good post into a page node by hand. It takes ten minutes and costs $0.
Keep the newsroom out of the handbook
The overlap with news is the failure mode.
| Content | Lives in |
|---|---|
| “Patch 3.2 dropped, here is what changed this week” | Article thread, maybe featured |
| “We always require 2FA for staff” | Help or page, plus the security policy |
| “Saturday maintenance 02:00 UTC” | Notice, dies Sunday |
| “How to enable push on iOS” | Help page |
| “Read this before posting in Support” | Sticky in Support and a one-line link on the FAQ page |
If you feature a handbook page on / with the articles widget, you have mixed types. Link the handbook from the portal. Do not make the handbook an article forum “so we get comments.” Comments on a policy page are a support thread. Put a “questions? post in Support” link at the bottom of the page.
Maintenance — the part everyone skips
A KB dies when the ACP password rotates and nobody owns the tree.
Assign:
- Owner (one admin) — can create pages and help portions
- Review date on each page (HTML comment or a line at the top)
- Quarterly pass: click every Handbook link in a private window as a guest; fix 404s from route filters you renamed
- After every XF upgrade: help pages that used template syntax may show up as outdated templates (they are templates). Merge like any other style customize. Advanced-mode pages are the ones you will regret.
When a page is wrong, fix or unpublish. A toggle exists on help pages (availability). A page node can be unpublished by setting View = Never on everyone, or by deleting it and leaving a route filter incoming-only from the old URL to the new page. Do not leave a confident, false how-to.
Search: page nodes and help pages participate in XF search to the extent the product indexes them. Do not assume every HTML blob is a perfect search hit. Put the words members type (2FA, two-step, authenticator) in the title.
A weekend build (no add-on)
Saturday morning. Category Handbook. Pages: getting-started, faq, security. Help page push. Navigation tab Handbook → the category node. No index-route change.
Saturday afternoon. Write getting-started (one screen). Move the ten answers you always type into FAQ. Security page links 2FA mandate as member steps (Password and security) and tells staff to use the ACP. Push help page copies the iOS sentence from official PWA.
Sunday. Route filters to handbook/… if you care. Test collisions. Guest permission check. Link the Handbook from the onboarding welcome and from a Support sticky. Do not set / to the FAQ.
Next month. If the same thread is still the answer, paste it into FAQ. If you are drowning in email support, then evaluate resource 7442.
Checklist
- You can point at the sentence each URL answers
- Pages hold your manual; help holds product/legal reference
- Terms and Privacy are still the default help pages, with forcing from Terms and rules
- Handbook category is visible to the people who should see its children
- Staff runbooks are Private nodes, not public FAQ entries
- Portions are stable (
faq, notpage3) - Route filters do not steal
threads/,forums/,help/,account/ - Index route is still
forums/unless you meant to move/ - No articles widget pretending to be a KB
- Tickets 7442 is installed only if you need a desk, not a page
- Each page has an owner and a last-checked line
- Guest click-through in a private window after every filter
What this is not
It is not a wiki with public edits. Official pages are admin HTML. If members should draft, that is a forum, then a staff promote (by hand or via Tickets convert).
It is not custom widgets. A “random FAQ” HTML widget is a link to /handbook/faq/.
It is not streaming documentation hosted as six iframes on a page node. Link the directory.
Takeaways
- Official KB tools are page nodes (FAQ / manual in the tree) and help pages (
/help/{portion}, template syntax, Advanced mode, optional PHP callback). - Route filters can drop
pages/and nest URLs. They can also stealthreads/. Test. - Index page route
pages/name/makes a page the homepage. Widgets on the forum list will not follow. Usually you wanted a nav tab instead. - Tickets 7442 can convert a thread or ticket message into a KB article. It is optional, $60, needs Xon’s library. Stock is a page you paste.
- News expires. A handbook is wrong or it is right. Keep it out of the articles widget.
Write the ten answers you already know. Put them where the node tree and /help/ already expect them. Buy a helpdesk when the queue, not the FAQ, is the problem.