XenForo is not missing a portal. It ships an index route, page nodes, a widget manager, article forums, and — since 2.3 — featured content. What most boards are missing is a decision: what should a stranger see in the first two seconds? Until you answer that, every “portal add-on” is a second homepage fighting the first.
This is not a landing-page brief and it is not a newsroom. A landing page is a campaign screen you send once. A news system is how staff publish editions. A portal is the everyday front door: a curated first screen that still belongs to the same board, the same permissions, and the same style. Build that door with stock tools. Install a CMS later only if the door is already boring and correct.
What a XenForo portal actually is
A portal is a job for the board root, not a product type. The URL you type as the site (or index.php) has to load something. By default that is the forum list — or the new-posts overview, if you flipped Forums default page. You can point the root at a page node, the resource manager, or a custom portal/ route an add-on registered. Same option, same group: Setup → Options → Basic board information → Index page route. Default: forums/.
That option is the architecture. Widgets, featured threads, an HTML welcome, an article forum — those are feed. Skip the option and bolt a magazine template onto the forum list, and you still have a forum list. Change the option and leave the page empty, and you have a blank front door.
Members say “the homepage.” You should still think in the route. The logo almost always goes there. The Home tab is a different control: a basic link to Home page URL, which can point off-site. Logo and Home tab disagree more often than admins notice. Align them, or turn Home off, before you spend a weekend on widgets.
A professional portal loads at the board root (not at /pages/portal/ that only staff bookmark), shows guests the parts you meant them to see, and has one primary action — read this, pick a room, or see what moved. It is still the forum. The node tree stays underneath. You are arranging the first screen, not replacing the product.
If you wanted a suite with a real CMS and staff-built pages as first-class apps, that is a platform choice. We already walked that fork in the IPS vs XenForo comparison. Do not try to win it with a portal add-on.
Decide the first-screen job
Three honest jobs. Pick one. The rest of the ACP becomes obvious.
| Job | First screen | Who it is for | Stock tools |
|---|---|---|---|
| Map | Forum list, dressed | Communities where the rooms are the product | Index stays forums/. Featured + HTML above the nodes. New posts in the sidebar. |
| Magazine | Curated page | Sites that publish and then discuss | Page node as index. Featured content + article forum + a short welcome. Forum list lives at /forums/. |
| Workbench | New posts | Returning members who already know the rooms | Forums default page = New posts. This is not a portal. Do not dress it as one. |
The map is the default and, for most boards, the right one. A stranger lands, reads one featured thing, and can name the rooms. That only works if the node tree is already a map. A magazine homepage on top of forty leftover forums is a pretty curtain over a junk drawer.
The magazine is right when the first thing a guest should do is read, not pick a forum: patch notes, editorial, “how this place works.” Discussion still happens — under the article, or in the rooms you link. Do not convert every discussion forum into an article forum so the homepage looks like a blog. Article threads have a different first post, a different listing, and a messy conversion later.
The workbench is what staff secretly want. XenForo will do it: Forums default page in the same options group. Guests who have never posted then land in a firehose. Use it on an internal board. Do not call it a portal.
Write the job in a staff thread in one sentence. “Guests should see this week’s featured guide, then the four public rooms.” That sentence is the spec. Widgets that do not serve it do not ship.
Architecture A: dress the forum list
Keep Index page route at forums/. Open Appearance → Widgets. You are going to add three things and stop.
1. An HTML widget above the nodes, display-conditioned to guests. Advanced mode off, so you keep the block chrome and stay inside the style. Three or four sentences, not a manifesto. Point at the rules page and the one forum a new member should post in first. If that path is part of a wider welcome, hang the rest off the 30-day onboarding plan — the portal is the hook, not the handbook.
A display condition of !$xf.visitor.user_id is enough. Logged-in members do not need to be welcomed every visit. If you skip the condition, regulars will file a ticket titled “can we hide that box.”
2. A Featured content widget in the same above-nodes position, after the HTML in display order. Higher display order renders later. Feature three to six things a guest is allowed to open. Feature dates control order; change the date if you need to reshuffle without unfeaturing. An empty featured widget is worse than no widget. If you have nothing worth featuring this week, disable it. Do not let last quarter’s “happy launch” thread rot in the hero.
3. A New posts widget in Forum list: Sidebar. Limit it. A sidebar that lists thirty titles is a second firehose. Style it simple. If the widget offers a node filter, exclude staff rooms and the recycle bin explicitly — do not rely on “it will hide what they cannot see” as your only hygiene, even though permissions do apply.
Positions have descriptive names. On a map homepage you care about Forum list: Above nodes (sometimes labelled Above content), Forum list: Sidebar, and occasionally Forum list: Below nodes. Do not put the same New posts widget in two positions on the same page. You pay for the query twice and the visitor reads the same titles twice.
A trap that wastes afternoons: you later switch Forums default page to New posts, and the Forum list positions vanish from the first screen. Those positions live on the forum-list template. The new-posts overview is a different page. If the first screen is the map, leave Forums default page on the forum list.
Online statistics and newest members are optional sidebar colour. They tell a quiet board that people exist. Today’s birthdays can wait until you have birthdays.
Architecture B: a page node as the index
Create a Page in Forums → Nodes. URL portion: home. Title: the site name, or “Home,” not “Portal v2.” Turn Display in the node list off so it does not appear as a weird extra room. The page still has a URL. You are about to steal that URL for the root.
In the page HTML, XenForo compiles template syntax. That is the whole trick. You do not need a custom widget position (those are registered in Development) and you do not need to clone PAGE_CONTAINER. Create the widgets in the widget manager with stable keys and no forum-list position — or positions you will not use on this page — then call them by key:
<div class="block">
<div class="block-container">
<div class="block-body block-row">
<p>This week: read the featured guide, then introduce yourself.</p>
</div>
</div>
</div>
<xf:widget key="portal_featured" />
<xf:widget key="portal_new_posts" />The keys are yours. portal_featured beats widget3. HTML widgets can use Advanced mode, which drops the block container — only when you are writing the wrapper yourself and will keep it inside the style’s spacing.
Then set Index page route to pages/home/. Open the board root as a guest. You should see the page, not the forum list. The forum list is still at /forums/ — the manual is explicit: whatever used to be the index keeps its default URL. Leave Forums in the public navigation. A magazine that cannot reach the rooms is a blog with extra login.
A route filter under Setup → Route filters can turn pages/home/ into home/ for people who still type it. That is independent of the index route. Do not create a filter that steals forums/ or threads/.
Page-node portals fail in three ways: the page is still displayed in the node list; the index route is still forums/, so only staff who know /pages/home/ see the work; or the HTML is a wall of custom CSS the next style upgrade will fight. Keep the HTML small. Let widgets do the feeds. Let the style do the chrome.
Feed the portal: articles, featured, HTML
Widgets do not invent content. They fetch it. Empty fetches make an empty portal.
Article forums are the native magazine. Since 2.2 a forum can be an article forum, or mixed-type with articles allowed. The first post is the artefact: longer character limit, more embeds, distinct styling. Replies are comments. When comments paginate, XenForo keeps a compressed article at the top of later pages.
The listing has two stock looks. Preview is masonry of covers and snippets. The cover is the first [ATTACH] or [IMG]; a zero-width, zero-height image can be a cover that does not appear in the body. Expanded is the blog-style full-article stack. Preview is for scanning on a homepage. Create a dedicated article forum and name it like a section — “Guides,” “Patch notes” — not a dump. Do not convert general discussion. Staff will keep hitting Discussion in a mixed forum, and you will feature a 40-reply argument because it had a pretty image.
Featured content is the 2.3 curator. Staff with the featuring permission use thread tools to feature or unfeature. The public listing is the featured/ route; the same queue feeds the widget. Order is the featured date, not last-post date. Context options on a forum- or thread-related position narrow the widget to that forum — leave context off on a homepage. Feature things guests can open. Feature one item that tells a new member how the place works. 2.3 will not expire features for you; a calendar reminder will.
HTML is for words that are not a thread: a one-paragraph welcome, a link to the rules page. It is not a ticker, a chat iframe, and a donate button.
New posts proves the board is alive. Filter if the widget allows. Otherwise keep a tight limit (five to eight), or link What’s new instead of duplicating it. Search forums are a view in the tree, not a homepage hero. Do not set the index route to one.
Navigation, the Home tab, and the leftover forum list
Setup → Public navigation is the other half of the first screen. Defaults are Home, Forums, What’s new, Members. Rename and reorder; do not delete the defaults or change their type. Home has no children. It is a link to Home page URL.
After you change the index route, in one sitting: set Home page URL to the board root (or disable Home) so the tab and the logo agree; confirm Forums still reaches the node list; if you publish, add a Node nav item pointed at the article forum (permissions apply — guests who cannot view it will not see the tab); keep What’s new. Returning members live there.
Do not build a second sitemap in a footer HTML widget. If the board lives in a subdirectory (/community/), the index route is still a route, not a filesystem path. pages/home/ is correct. /community/pages/home/ is not.
Permissions and the guest test
Widgets inherit content permissions. A guest does not see threads they could not open. That does not save you from featuring a private-node thread — the widget just looks broken, with a hole where the hero should be. Feature from public forums only.
The HTML welcome should assume the reader is not logged in. “You must register to see this” on the homepage bounces the only people the portal was for.
Open three sessions after every change: guest (fresh cookies), a brand-new Registered account, and your admin account. If the three first screens tell three different stories, you are not done. The usual bug is a Featured widget full for you and empty for a guest, or a page node whose parent category is private. Parent View still wins. Display-in-list is not a permission: hiding the Home page from the tree does not hide it at the index route. That is what you wanted.
Keep it fast
Each widget is a query, a render, often a permission pass. Three widgets is a homepage. Twelve is a second application you did not mean to write.
Keep one “what is new” feed (sidebar or below-nodes, not both) and one curated strip (Featured or a hand-built list of three links). Limits in the 5–8 range. No PHP-callback widgets on the first screen unless you wrote them. No third-party sliders until the stock featured widget is doing the job.
If the editor offers a cache lifetime, use it. A New posts block that is ninety seconds stale is fine. Test on a phone: magazine previews become a tunnel of cards. If the first screen is four heroes before a single forum title, you picked the wrong architecture. Style work belongs in a child style. Do not clone forum_list to inject a hero — the widget position is the injection point XenForo already gave you.
When an add-on is justified
Stock tools will not give you a multi-column newspaper or a ticker that pulls five sources. Buy or build an add-on when the first-screen job is written down, the stock architecture almost does it, the gap is layout (columns, mosaic, a dedicated portal/ route), you can name the maintainer you will ping on the next 2.x, and you will test that route on every upgrade.
The official index-page examples include “a custom portal: portal/.” That sentence is permission, not a recommendation. A portal add-on that still expects you to paste HTML into a page node is a page node. Skip it. Do not install a package to paper over a messy tree, and do not install one because an old magazine skin had a hero header. The look is the last 10 percent. The first 90 is the job, the route, the three widgets, and the guest test.
FAQ
Can I set a forum itself as the homepage?
Not as a first-class index target in the same way as a page. The stock examples are forums/, pages/page-name/, recent-activity/, resources/, and an add-on portal/. If one article forum is the magazine, use Architecture B and put that forum’s latest output in widgets. Pointing Home URL at forums/your-articles.12/ without changing the index route leaves the logo and the tab in a fight.
What happened to my widgets when I switched to New posts?
They are still assigned to Forum list positions. The first screen is no longer that template. Move them, or move Forums default page back.
Should guests see online statistics?
Only if the number will not embarrass you. A “2 users online” block next to a magazine hero says the opposite of what you hoped.
Is a page-node index bad for SEO?
A thin page of three widgets and no unique words is a thin page. Write a real welcome, give the page a proper title via the node title, and keep the articles themselves as the indexable artefacts. The homepage’s job is to route humans.
Do this afternoon
- Write the one-sentence job in a staff thread. Map, magazine, or workbench. If you cannot pick, you are building a map.
- If the tree is still a junk drawer, stop and fix the nodes first. A portal will not hide that.
- Create or clean one public article forum. Post one genuine article with a cover image. Feature it.
- Map: HTML welcome (guests only) + Featured content above the nodes + New posts in the sidebar. Limits on. Same widget in one position only.
- Magazine: page node
home, widgets by key, Index page route =pages/home/, page hidden from the node list, Forums tab still reachable. - Align Home page URL with the root, or disable Home. Open guest, new Registered, and admin. If the hero is empty for the guest, unfeature the private thread.
A professional XenForo portal is a decided first screen. The widgets are furniture. If you do not know what the room is for, no amount of furniture will make it a lobby.