Northbound
WordPress Multisite (subdirectory) demo for a fictional PNW travel publication — one install, one TLS cert, one A record, four sites with their own content and admin.
Overview
A WordPress Multisite (subdirectory mode) demo for a fictional Pacific Northwest travel publication. One install, one TLS cert, one A record, one database, four sites: a network root landing + three city editions (Seattle, Portland, Vancouver). Each city edition has its own home page, posts, settings, and /wp-admin/ but inherits a shared theme + chassis. Twelve sample posts across the three cities, each with city-specific narrative.
Subdirectory over subdomain:
Subdomain multisite needs wildcard DNS on the parent zone plus a wildcard TLS cert — neither of which the platform carries. Subdirectory multisite gets four sites under the single A record + single cert that already exist. URLs become /seattle/ instead of seattle. — arguably more readable for editorial publications anyway.
Post-provision conversion sequence — three commands:
wp config set WP_ALLOW_MULTISITE true --raw --path=...
wp core multisite-convert --path=...
# Then manually flip SUBDOMAIN_INSTALL to false in wp-config.php
# (the --subdomains=false flag was parsed as truthy in this wp-cli version)
Then four wp site create --slug=<city> calls bootstrap the sub-sites.
One theme, network-activated, with per-site static-page front pages:
The northbound theme is enabled at the network level (wp theme enable northbound --network) and explicitly activated on each site. Each sub-site sets show_on_front=page and pins a static "city home" page containing the city-specific hero + an inline core/query block listing recent posts.
This is the workaround for a multisite-specific template-hierarchy gotcha that cost ninety minutes during the build — front-page.html wins over home.html for the front page even when show_on_front=posts. Removing front-page.html made WP fall back to the chassis's front-page.html (a shop-style pattern composition), and the demo's network root suddenly rendered Library content. Fix: restore front-page.html in the demo theme rendering core/post-content, switch each sub-site to show_on_front=page with a static city-home page. Documented as gotcha #25 in the platform guide.
Content per edition:
- Network root — landing page with three city cards plus an /about/ page describing the multisite model
- /seattle/ — Static city-home with hero + 3-column grid. Three posts including a 90-minute Ballard Locks walk and a Saturday on Bainbridge
- /portland/ — Forest Park (not Lower Macleay), the Portland bookstore that isn't Powell's, a Southeast Saturday walk
- /vancouver/ — Walking across the Lions Gate, Cantonese in Richmond, Stanley Park seawall clockwise
The Challenge
The multisite use-case is the one where the alternative isn't a different CMS — it's ten separate WordPress installs. A university with twenty departments, a franchise with thirty locations, a publisher with five imprints — without multisite the answer becomes spin up ten installs, run ten deploys, push the same theme update ten times, hope nobody's admin password drifts.
The Solution
WordPress Multisite is the WP feature most freelancers skip on portfolios because the setup involves wp-config constants, .htaccess rewrites, network-admin awareness, and a wp-cli vocabulary not in the standard tutorial flow. Northbound is the worked example — provisioned as a normal single-site install, then converted to multisite via a three-command sequence reproducible on any future build.
Results
Lighthouse 100 / 91 / 100 / 92 on the network root — multisite imposes no front-end perf overhead
One install, one TLS cert, one A record, one database serving four distinct sites
Subdirectory routing:
/seattle/,/portland/,/vancouver/— no wildcard DNS requiredPer-site content seeding via
--url=targeting in wp-cliDocumented two new platform-level gotchas: chassis-front-page fallback (gotcha #25) and wp-cli
--subdomains=falseparsed as truthyReproducible three-command conversion playbook for any existing single-site install
Gallery
