One parent theme. Eleven distinct child themes. A national flagship daily on top of the stack. In 2011–2012, Postmedia® migrated its network of major Canadian daily newspapers onto WordPress®, and I was on the team that built the platform. The National Post® went first; it was the flagship, and everything else in the network followed behind it. What we shipped on the Post had to work before any of the other papers could move.
WordPress VIP in that era was not a commodity purchase. Onboarding required direct vetting from Automattic®’s VIP team and a codebase review before the first deploy. For publishers at this scale, that gate mattered. Nothing shipped that hadn’t been pressure-tested by another set of senior engineers before it hit production on a national newspaper.
The architecture: one parent, eleven children
The technical approach was a parent-child theme architecture. Each of the eleven Postmedia papers ran as a distinct child theme on a single shared parent. Infrastructure, performance optimisation, and platform-level concerns lived in the parent. Brand identity, editorial controls, and paper-specific layout decisions lived in the child.
When the parent earned a fix — a performance improvement, a caching change, a new upstream compatibility update — all eleven properties inherited it on the next deploy. That was the operational ROI for the publisher. One codebase to maintain at the infrastructure layer, eleven distinct publishing experiences on top of it.
For the engineering side, it meant the National Post’s performance ceiling effectively set the ceiling for everything downstream. The Post was the most demanding property to ship against first: largest audience, heaviest ad load, most complex homepage curation cycles. Clearing that bar meant the parent was proven before a single child theme started.
What theme engineering means on a flagship daily
The customisation decisions tracked the newsroom, not the design system. Homepage curation cycles, breaking-news cache behaviour, ad-load budgets, the latency between a column leaving the CMS and landing in front of a reader — those drove the brief. Theme engineering on a flagship daily is making sure publishing rhythm holds up under load.
Doing this on WordPress VIP, in 2011–2012, was the part that is hard to fully convey now that VIP is a more familiar option. At the time, whether WordPress could carry a national daily was still an open question. Putting the National Post on it, and then canada.com and the rest of the Postmedia network beside it, answered that question in production. Most of the rest of the network followed because the flagship proved it was possible.
Paper by paper: the specific problems
Each paper’s child theme carried a different set of editorial constraints. The shared parent handled infrastructure; the children handled the things that made each paper what it was.
Calgary Herald. If you’re building a newsroom platform for a Calgary paper, “business news” and “energy news” are basically the same beat, and both move on a different schedule than the rest of the country. Earnings cycles for major energy producers, regulatory decisions, commodity-price movements — the Herald’s homepage absorbed traffic and ad load on patterns the rest of the network didn’t see. Performance work here meant tuning to the days when a commodity-price move and a contentious regulatory decision land in the same hour.
Montreal Gazette. Publishing an English daily in Montreal is a different SEO and content-discovery problem than publishing one anywhere else in Canada. The Gazette’s reader searches in both languages. Neighbourhood names, politicians, institutions, streets — every one has a French canonical form and an English working form, and readers move freely between them. The theme engineering had to let an English-language template live comfortably in a search environment that is bilingual whether the publisher acknowledges it or not.
Language metadata, taxonomy slug decisions for place names, how headlines referenced bilingual proper nouns, internal linking that handled the same entity under two names depending on the writer — none of it is exotic engineering, but all of it compounds.
Ottawa Citizen. The Citizen’s reader checks the references. A federal-policy beat reader is, often professionally, going to follow a link to a tabled document, an Order Paper item, or an Auditor General report — and if that link is dead or stale, the trust hit lands harder than it would on a civic story. VIP-grade SLAs and the production discipline that came with the platform mattered for exactly this reason. The child theme carried the editorial weight a federal-politics front page demands: section prominence for federal politics, public service, and national affairs; CMS and theme decisions around document links and inline source attribution that carry more consequence here than on a regional general-news page.
Vancouver Sun, The Province, Financial Post, Windsor Star, Edmonton Journal, Regina Leader-Post. Each carried its own variation of the same challenge: a distinct editorial voice and audience on a shared platform that had to perform consistently across all of them. The tabloid voice of The Province and the broadsheet long-form of the Sun running on the same parent codebase is the engineering proof of concept the architecture was built to deliver.
What this proved
The Postmedia migration answered, in production, the question of whether WordPress could be the platform of record for major national journalism. The answer was yes — but only if the architecture was designed for the newsroom’s actual constraints, not for a generic publishing use case. Homepage curation under breaking-news load, bilingual discovery, source-attribution integrity, energy-sector news cycles, tabloid vs. broadsheet editorial identity on the same codebase: all of it was in scope.
This is the kind of WordPress engineering that happens upstream of design. If the platform doesn’t hold up under the newsroom’s real conditions, nothing else matters.
Where this transfers
The parent-child pattern at this scale applies to any organisation operating multiple distinct publishing surfaces that share infrastructure: publisher networks, multi-brand parent organisations, and higher-education systems running multiple branded sites. The discipline is the same — centralise what should be uniform, isolate what must be distinct, and make sure changes to the shared layer propagate cleanly.
If you’re building a multi-site or multi-brand WordPress architecture and the decision has been made to share a platform, the architecture question is not “how do we customise each site?” The architecture question is: what is the minimum the parent must own to make the child themes sustainable? Getting that answer right on the National Post and the rest of the Postmedia network is the proof of work.
Talk through your multi-property WordPress architecture
If you’re running a multi-property WordPress operation — a publisher network, a multi-brand parent, a higher-education group — and the architecture decisions are about to get expensive, that is the conversation worth having. Book a 20-minute discovery call. I’ll tell you in the call what the parent must own and what the children should keep, before you commit to a build.
