canada.com had no editorial staff of its own. It aggregated coverage from eleven regional Postmedia papers under a national domain. I worked on the portal architecture and child theme build — and the hardest problem was defending why a portal needs fundamentally different architecture than any newsroom it aggregates from, even when they’re running on the same parent theme.
canada.com had no reporters. No assignment editors, no city desks, no breaking-news team writing to a house style. What it had was a national domain, a network of Postmedia regional dailies producing content, and a platform responsibility to surface the best of that coverage under one brand.
Before the portal launched, there was no clean way to surface cross-paper national coverage. Each Postmedia regional paper had its own CMS, its own taxonomy structure, its own section hierarchy. A national politics story from the Ottawa Citizen and a technology story from the Vancouver Sun existed in completely different category systems with no shared vocabulary between them. Getting them to appear coherently under a single national brand required a layer of architecture that none of the individual papers needed — and that a newsroom CMS model wasn’t built to provide.
That distinction — portal, not newsroom — decided the architecture before a template was designed.
What a Newsroom CMS Assumes
A newsroom CMS is built for a specific workflow: reporters file, editors review, articles publish. The user roles are defined — contributor, section editor, publisher — and the system enforces a path between them. Ad operations, taxonomy, and section structure organize around the newsroom’s own editorial hierarchy.
Every Postmedia daily paper ran on a version of that model. The parent theme that carried the network was built around it. Each paper’s child theme adapted it for that paper’s editorial rhythm.
canada.com didn’t fit that model. Forcing it to fit would have produced the wrong system.
The Hard Technical Problem: Taxonomy at Scale
The hardest problem in the canada.com build was taxonomy reconciliation. Eleven papers, each with their own section structure, none of them consistent with each other. The National Post organized content by section; regional papers organized by local geography and editorial beat; some papers had topic-based taxonomies that mapped poorly to either. When that content arrived in the portal’s feed, it brought taxonomic structures that didn’t reconcile automatically.
Getting cross-paper content to appear in the right sections on canada.com required an ingestion layer that normalized categories on arrival — not in the front-end template after the fact, but at the ingestion step where the damage could still be contained. Building that layer before we had seen the full range of taxonomy inconsistencies meant building it speculatively, with enough flexibility to handle cases we hadn’t anticipated yet. That required iterating on the ingestion architecture as new paper feeds surfaced new inconsistency patterns.
The Portal Architecture
The canada.com child theme on the Postmedia parent carried the portal posture, not the newsroom posture. Feed normalization, taxonomy reconciliation across papers, and aggregation logic replaced the editorial workflow assumptions built into the other child themes. The parent handled infrastructure. The portal’s child handled a fundamentally different editorial job — one without editors in the traditional sense.
Contributors, Editors, and Ad Ops Are Not the Same Role
In a newsroom, the relationship between editorial and advertising is institutional — maintained by convention and enforced by the organizational structure of a newspaper operation. In a portal, those relationships are structural. The content sources are external. The ad inventory is national. Curation is algorithmic rather than assignment-based.
Getting the role architecture right meant not inheriting newsroom assumptions about who does what. The user permissions, workflow logic, and content-sourcing model in the canada.com build reflected the portal’s actual operating model — not the model running next door at the National Post.
The Same Parent, a Different Posture
canada.com ran on the same WordPress VIP parent theme as every Postmedia paper in the network. The shared infrastructure — performance, caching, platform integrations — applied equally. What the canada.com child theme held was a set of decisions that looked nothing like any of the individual papers: how feeds were ingested, how taxonomy conflicts were resolved on the way in, how the aggregation surface was organized for a national audience rather than a local one.
canada.com and the National Post ran on the same platform and looked nothing like each other, which was exactly the intended result.
The portal operated on this architecture from launch until Postmedia retired the canada.com brand in 2014 — a business and commercial decision, not a technical one. In three years of operation, the architecture served its purpose: national coverage from eleven contributing papers, surfaced coherently under one brand, with no newsroom of its own.
This engagement in context
This is Publishing Infrastructure within the WordPress Practice pillar — the platform layer for editorial organizations operating across multiple properties or content sources. The portal-vs-newsroom architectural distinction that defined this build is misapplied regularly in publishing technology projects today. It’s not a subtle difference.
The Lesson That Transfers
A newsroom CMS and a content aggregation portal do different things, for different user roles, with different workflow requirements. Applying newsroom architecture to a portal produces friction at every seam: content ingestion breaks in ways that content filing doesn’t, taxonomy mismatches become front-end inconsistencies, and editorial tools built for human curation don’t work cleanly on algorithmically sourced content.
The right architecture starts from the operating model. For canada.com, that model was aggregation and curation under a national brand — not a newsroom with distributed bureaus. The platform worked cleanly because the architecture matched the model it was built to serve.
If you’re building or migrating a content aggregation portal, or if you’re running a multi-brand editorial network and need a clear architecture for how content flows between properties, a Site Audit is the right starting point.