01
Context
The Portland Group runs a network of wholesale branches, and its website carries structured content for each of them: branch locations, events and brand assets, each with custom fields, taxonomies and public archive URLs. The site was built on Elementor, with the content model held inside a plugin's settings, where it could not be versioned, reviewed or rolled back. It needed rebuilding on Bricks, on a clean install, without breaking a single public URL.
The rebuild ran in milestones from approved mockups to launch, while the existing site stayed live and needed its own production support along the way, including diagnosing a publishing outage. After launch the work continued with new content features for the branches. Every deliverable was reviewed closely, so every claim in every report had to be measured, not asserted.
02
The Challenge
- The content model lived in plugin settings: changing builders meant recreating it exactly, because every record URL depended on it.
- Records had to move into a clean install where source IDs mean nothing, and the source plugin did not expose all of its data through the standard API.
- The new design had to match the approved brand system exactly while staying fast on phones.
- Mid-project, the live site stopped publishing pages, and the first, obvious diagnosis was wrong.
03
Scope and Approach
Code-owned data layer
Content types, taxonomies and custom fields moved out of plugin settings and into version-controlled code, matching the live URL structure exactly. A field or content-type change now arrives as a reviewable diff instead of a database setting.
Evidence-backed migration
A scripted importer moved every record and its media into the new install, matched on stable keys rather than database IDs. It ran as a dry run first and produced a per-record, per-field evidence export, with anything it could not resolve logged as a failure instead of guessed.
Bricks build on one design system
Templates for branches, events and archive pages were built in Bricks from the approved mockups. All visual values live in one documented stylesheet, so the design has a single source of truth and the templates themselves are versioned.
Performance, search and structured data
Images re-encoded and capped, unused CSS removed, needless scripts turned off, and location structured data generated for every branch page from its own record, with empty values left out rather than invented.
Live support and branch events
On the live site: the publishing outage diagnosed and mitigated, regression sweeps at desktop and mobile widths, and a data completeness audit of every branch record. After launch, an events system for branch promotions and vendor demo days, built and reviewed on staging before it reached production.
04
Architecture flow
05
Technical Deep Dive
An outage diagnosed by elimination
When page publishing started failing, memory, timeouts, plugins, theme, firewall and caching were each ruled out with evidence rather than assumed. Publishing was restored with a single reversible change, and the remaining cause, below the application, went to the host as a clearly labelled hypothesis with precise questions, never as a proven finding.
One stylesheet, no specificity wars
The builder carries structure, the stylesheet carries every visual value. That split means there is exactly one place to change a colour, size or spacing rule, no overrides fighting each other, and a minified copy that can never serve stale styles.
Measuring behaviour, not proxies
Several checks nearly produced false findings: a wide screenshot that looked like sideways scrolling, text extraction that skipped collapsed content, and a missing font file that turned out not to matter. Each was settled by measuring what the visitor actually gets, not a stand-in for it.
06
Engineering Decisions
URLs are identity, database IDs are not
Every public URL and every migration match depends on stable keys, so they were preserved exactly and used as the only record key. Nothing downstream trusts a source ID.
Symptom and hypothesis are separate claims
Reports state what the evidence shows and what is suspected as two different things, and merge them only once the next layer down confirms.
Staging first, then production
New features are built and reviewed on staging, backed up before any production change, and verified as a logged-out visitor after release, so a review never happens on the live site.
07
Results
- The whole content model moved from plugin settings into reviewed, version-controlled code, with every public URL preserved.
- Every migrated record accounted for field by field: nothing guessed, every gap logged.
- Heaviest page cut by about 60 percent, page images by two thirds, and the stylesheet from 111 KB to 23 KB on the wire, all measured on the rendered pages, not estimated.
- A live-site publishing outage diagnosed and mitigated with a single reversible change.
08
Planned next
- Redesigned branch profile pages, the next phase of the branch content work.