XenForo Engineering

XenForo theming that survives the next upgrade

A theme is a set of changes to a platform that keeps moving. Styling written where the platform expects it can be upgraded indefinitely; styling written into copies of templates is lost the first time the platform changes one.

The problem

Most XenForo themes are copies, and copies do not upgrade

The direct approach is to duplicate the templates you want to change and edit the copies. It works, it is fast, and it means the theme now owns those templates — when the platform updates them, the theme keeps serving the old version, and the update's fixes and features do not arrive. Over a few years the forum accumulates templates that are years behind, and nobody can tell which differences are deliberate.

  • A theme exists and nobody knows which templates it replaced
  • The forum was upgraded and the styling broke, or the upgrade was postponed because of it
  • Template changes were made directly and the forum no longer receives the platform's fixes
  • The design was built on a default theme and has drifted
  • The forum looks wrong on phones and the theme was built before the current version
  • Editors cannot change a colour without a developer
  • A second theme exists for a sub-section and the two have diverged
  • Nobody can say what the theme actually changes
Who this is for

The people who usually bring us this problem

A community whose design has drifted from the platform

The forum was styled years ago and upgrading is now a risk rather than a routine.

Someone planning a redesign

You want the new design built so it can be upgraded, rather than replaced again in three years.

Someone who has inherited an unupgradeable forum

The theme is the reason the platform is behind, and you need to know what it changes and what can be recovered.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

A copied template stops receiving the platform's work

The platform updates its templates for reasons: fixes, features, compatibility, security-adjacent markup. A copy freezes that template at the version it was taken from, and the forum silently stops receiving everything done to it since. This is the cost of the fastest approach, and it accumulates.

Styling belongs in properties, and it is the whole answer

XenForo exposes its styling through properties — colours, spacing, typography, borders — which the templates reference. A theme that changes properties inherits every template change the platform makes; a theme that changes templates does not. That distinction is the entire difference between a theme that upgrades and one that does not.

Upgrade difficulty grows with every year it is deferred

A forum three versions behind has a theme built against the version it was on, and the further the platform moves the larger the gap. The work does not shrink by waiting, and the postponement is usually justified by the upgrade being risky — which is true, and is a consequence of the postponement.

A design that only a developer can change is a design that stops changing

Colours, spacing and typography expressed as properties can be adjusted in the platform's own interface by whoever owns the forum. Expressed as hard-coded values in templates, every adjustment is a development task, and the design stops being maintained.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Audit of what the current theme changes

Which templates were replaced, which properties were altered and which changes were made directly. On an inherited forum this is the first deliverable, and it is what establishes how much of the theme can be recovered rather than rewritten.

Upgrade-safe styling through properties

Colours, spacing, typography, borders and the rest expressed as properties, so the theme changes what the platform renders without replacing how it renders it. Adjustable afterwards in the platform's own interface.

Template modification where a change is genuinely structural

Where the markup itself has to change, using the platform's own modification mechanism rather than a copied template — so the change is recorded, attributable and re-applied across platform updates instead of freezing the file.

Recovery of a frozen theme

Where templates were copied, establishing what each copy changed and expressing the difference as properties or modifications, so the forum can receive platform updates again. A real piece of work, and the only route out of the position.

Responsive work on the forum's real pages

Threads with long titles and embedded media, forums with deep nesting, the editor, member profiles and the moderation tools — the pages that actually break, rather than a layout tested against a homepage.

Child themes and variants

A base theme with variants inheriting from it, so a seasonal or section-specific design does not become a second theme that diverges. The relationship is explicit and changes to the base propagate.

Editor-facing controls

The settings the forum's owner should be able to change without a developer — logo, brand colours, layout options — exposed deliberately rather than left in a stylesheet.

Upgrade rehearsal

The theme exercised against the platform version it will be upgraded to, on real content, before the upgrade is attempted. The point of upgrade-safe styling is that this is a routine check rather than an investigation.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

  1. Establish what the theme changes before changing it

    On a forum with any history, the theme is the accumulated result of several people's work and nobody knows all of it. The audit is what makes the rest of the work possible, and it is also the deliverable that tells an owner whether the theme can be recovered or should be rebuilt.

  2. Prefer properties to modifications, and modifications to copies

    In that order, always. Properties are upgradable indefinitely, modifications are re-applied by the platform, and copies are frozen. Each step down that order is easier in the short term and costs more every year.

  3. Express the design as values, not as rules

    A colour is a property; a layout is a set of spacing properties; a typographic scale is a set of sizes. Written that way the design is adjustable by the person who owns the forum, and it survives platform changes because it does not describe the platform's markup.

  4. Test against real content, not a fixture

    Forum styling breaks on long thread titles, deep forum nesting, embedded media, tables in posts and the moderation interface. A theme verified against a clean installation has been verified against the case that was never the problem.

  5. Rehearse the upgrade

    Run the theme against the target platform version before the live upgrade, on a copy. With upgrade-safe styling this is a confirmation; with a copied theme it is the investigation that reveals how much is broken.

  6. Document what the theme changes and why

    Which properties, which modifications, and the reason for each. Written for whoever maintains the forum next, and it is what turns an inherited theme from an unknown quantity into something that can be worked on.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Audit

  • Which templates the current theme replaces, and what each replacement changes
  • Which properties are altered, and which changes were made directly
  • What the theme has stopped receiving from the platform, and for how long
  • What is recoverable as properties or modifications, and what is not
  • How far behind the platform is, and what that implies

Theme build

  • Styling expressed as properties, adjustable in the platform's interface
  • Template modifications where a structural change is genuinely required
  • Recovered changes from copied templates, re-expressed
  • Responsive behaviour verified on the forum's real pages
  • Child theme structure where variants are needed

Handover

  • What the theme changes, and the reason for each change
  • Which settings the forum's owner can adjust without a developer
  • How to rehearse an upgrade against the theme
  • What was recovered from the previous theme and what was rebuilt
  • What the theme deliberately does not do
Under the hood

Architecture and technology

How a XenForo change can be expressed, in order of durability

  • A property — a value the platform's own templates reference, upgradable indefinitely
  • A template modification — a recorded change re-applied across platform updates
  • A copied template — frozen at the version it was taken from, receiving nothing since
  • Direct edits to platform files — lost at the next update

Where forum styling actually breaks

  • Long thread titles and titles with no spaces
  • Deep forum nesting and long forum names
  • Embedded media, quotes and tables inside posts
  • The post editor and its toolbar
  • Moderation and administration interfaces, frequently unthemed and left broken
  • Member profiles and the account pages
  • The mobile view of all of the above
Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

The platform itself needs building on

Add-ons, integrations and the platform's own extension points.

XenForo development

The forum is being moved to XenForo

Source conversion, compatibility and reconciliation.

Forum migration to XenForo

The forum is slow rather than unstyled

Diagnosing and fixing a slow XenForo forum.

XenForo performance optimisation

The forum needs a front page

A custom portal over the community's content.

XenForo portal development
Questions

Frequently asked

Do you have a design case you can show?

No. Our published forum work is engineering rather than design, and pointing at a forum whose theme we did not design would be claiming a case we do not have. What this page describes instead is the distinction that decides whether a theme is worth commissioning at all: a theme expressed as properties survives platform upgrades indefinitely, and a theme built from copied templates stops receiving the platform's work the day it is created. That is evaluable on its own terms, and it is the part that matters years later.

What is upgrade-safe styling?

Styling expressed through the platform's own properties rather than through copies of its templates. XenForo's templates reference properties for colours, spacing, typography and borders, so a theme that changes the properties changes what the forum looks like without replacing the markup that produces it. When the platform updates its templates, the theme inherits the changes and the styling still applies. A theme built from copied templates owns those templates and stops receiving updates to them — which is why forums get stuck several versions behind.

Our forum is three versions behind because of the theme. What now?

The first piece of work is an audit rather than a redesign: establishing which templates the theme replaced and what each replacement changes. Some of those changes can be re-expressed as properties or modifications, and the template can then be dropped so the forum receives the platform's updates again. What cannot be re-expressed is rebuilt. It is real work, and it is the only route out — the gap does not shrink by waiting, and deferring the upgrade is what created it.

Can we change colours ourselves afterwards?

That is one of the reasons for building the theme this way. Colours, spacing and typography expressed as properties are adjustable in the platform's own styling interface by whoever owns the forum, with no development involved. Where a design is written as hard-coded values in templates, every adjustment is a task — and a design that is expensive to adjust stops being maintained, which is how a site ends up looking several years old without anyone deciding it should.

Will the theme cover the moderation and admin interfaces?

It can, and it is frequently forgotten. Moderators and administrators use the forum more than anyone, and their interfaces are where a design is most often left at the default because the redesign was scoped to what visitors see. The responsive work covers the editor, the moderation tools and the account pages alongside the public ones, and where something is deliberately left unthemed that is stated rather than assumed.

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.