Pages Managerfor WHMCS · Documentation
v7.0.0

How Pages Are Served

Every request — pretty or plain — ends up on the same Internal-Pages controller. SEO Friendly URLs only change the address the visitor types; the routing that resolves it is what this page explains.


One controller — regardless of format, a request resolves to index.php?m=page&display=<slug>. The .htaccess rules merely make that resolution invisible to the visitor and to search engines.

The request chain

  1. WHMCS receives the raw URL — pretty (/about.html or /about) or plain (/index.php?m=page&display=about).
  2. Root .htaccess — the module’s fenced SEO block is placed before the WHMCS-managed rules in the WHMCS root .htaccess (the auto-managed block is described in the fence below).
  3. Generated-PHP pages win the pretty, extensionless URL — when SEO is on with the without .html format you chose in Settings, an extensionless request like /test is rewritten to the module’s generated test.php first.
  4. Everything else goes to the internal controller — any other pretty or plain URL rewrites to index.php?m=page&display=<slug>.
  5. Render — the controller formats content (see Admin Usage Guide), injects SEO head tags, and returns the WHMCS-styled page.

Because the extensionless PHP rule runs first, pre-existing generated pages keep the shortest possible URL — while new pages, and any slug the core might otherwise catch, still resolve correctly.

Rule order & the two formats

With SEO Friendly URLs on, the root .htaccess holds (in this order):

#RuleExampleTarget
1 Generated .php (only with the “without .html” format) /test test.php (the module’s generated PHP file)
2 Internal pages, format A — with .html /about.html index.php?m=page&display=about
3 Internal pages, format B — without .html /about index.php?m=page&display=about
4 Core WHMCS friendly URLs /announcements, /knowledgebase WHMCS core pages (unchanged)

Rules 1–3 sit inside the fenced block the module manages automatically (see below); rule 4 is WHMCS’s own block, which the module never touches.

Exclusions matter — to avoid hijacking WHMCS core pages or causing redirect loops, the extensionless rule (#1 and #3) deliberately skips core paths such as /announcements, /knowledgebase, /download, /store, /cart, /contact and /index.php. A page slug that collides with one of these is still reachable; the core page always wins.

Automatic .htaccess management

On every Settings save, the module keeps the WHMCS root .htaccess in sync automatically:

  1. Fences its own block between the markers ### BEGIN - Pages Manager SEO and ### END - Pages Manager SEO, writing the rules for the active format (with or without .html).
  2. Replaces the previous block when you switch formats, and removes it entirely when SEO Friendly URLs are turned off.
  3. Cleans legacy unfenced rules — if a previous version or a manual edit left plain rules outside the fence, the module detects and removes them so no stale or duplicated rewrites survive.
  4. Places the fence before the WHMCS-managed rules, preserving that order every time it rewrites the file.

You never edit .htaccess by hand — the module reads, updates and repairs its own fenced block for you. This is what the Settings & SEO page drives and what the v7 changelog lists as the biggest change.

Deploying standalone? — external pages are a separate concern. See External Pages & Deployment for how those ship as self-contained sites with their own .htaccess, independent of this chain.