Gutenberg block development
The block editor is the best thing to happen to WordPress editorial work and the easiest to get wrong. Done well, editors assemble pages from components that already carry the right structure, markup and accessibility behaviour. Done badly, it becomes a page builder with a thousand settings and a site that looks different on every page.
- Server-rendered blocks: markup comes from PHP at request time, not from saved HTML
- A curated component set, not an open canvas
- Structure and accessibility enforced by the block rather than documented in a manual
- Editorial sidebars and tooling where the workflow needs them
A component system, not a page builder
The design question behind a block library is how much freedom to give. Too little and editors cannot build the pages they need, so they ask for a developer or paste in HTML. Too much and every setting is a way to produce something off-brand, inaccessible or unreadable on a phone, and after two years of that the design system exists only in the original mockups.
We build narrow, composable blocks: a layout primitive, a small set of content components, and options limited to the choices a designer actually sanctioned. Editors get real flexibility in how components are arranged and very little in how each one looks, which is the split that keeps a large site coherent.
We build them server-rendered: the block saves its attributes, and the markup is produced in PHP at render time. It costs a little more up front and it means the entire site’s markup can be changed in one place: a fix to a heading structure, an accessibility correction or a new design token applies to every existing page without an editor touching anything or a database migration rewriting saved content.
Layout primitives
A small set of section, grid and cell blocks that carry the spacing and container rules, so every page lands on the same rhythm without editors choosing padding values.
Content components
Headings, cards, service and feature items, galleries, calls to action, FAQ accordions with their structured data, each producing correct, accessible markup by construction.
Patterns and templates
Pre-composed arrangements for the page types a team builds repeatedly, so a new landing page starts from something correct rather than from an empty document.
Editor sidebar plugins
Panels for the metadata and workflow a project needs: SEO fields, publication settings, per-page data and reporting, built into the editor rather than parked in a separate admin screen.
Editorial constraints
Locked templates, allowed-block rules and required fields where structure matters, so that the correct page shape is the default rather than a convention people remember.
This site is the example
wplook.ca is built on exactly this approach, and it is the clearest first-party evidence we can offer. The theme registers a library of custom server-rendered blocks: section and grid primitives, headings, service and technology items, portfolio grids, client logos, FAQ accordions that emit their own structured data, and form blocks backed by custom REST endpoints, with every one of them rendering from PHP at request time. Two editor sidebar plugins sit alongside them for page metadata and for Search Console reporting inside the editor.
The same pattern is in the delivered client platforms. The five mortgage and brokerage brands (Multi-Prêts, Mortgage Alliance, Invis, Mortgage Intelligence and Intelligence Hypothécaire) share one block library built for their editorial teams, held in a parent theme with a child theme for each brand. iAmEvolving® carries thirty-five custom blocks and Doolittle Lake Club fifteen, both built the same way.
Building an editorial system, not just a site?
Tell us who edits the site and what they need to build without help. The block library is designed around that answer, and it is the part of a build that pays back for years.
What working this way changes
Editors stop asking for developers
New pages, new sections and new campaigns get built by the communications team, which is where the ongoing cost of a site usually hides.
The design system survives
Two years and four hundred pages later the site still looks like one site, because the components did not allow otherwise.
Accessibility is structural
Heading order, landmarks, keyboard behaviour and focus handling live in the component. Editors cannot accidentally produce an inaccessible version of a pattern that exists.
Site-wide changes are one change
Because markup renders at request time, a correction applies to every page that uses the block, including the ones published three years ago.
Migration is possible
Structured attributes rather than saved HTML means content can be re-rendered, re-themed or moved without unpicking markup out of the database.
Fewer plugins
A block library covers what a stack of layout, slider, accordion and call-to-action plugins would otherwise be doing, with one codebase to maintain instead of eight.
Frequently asked questions
-
Is this the same as Elementor or Divi?
No, and the difference is where the markup lives. A page builder stores layout and markup in the database, so changing a component later means touching every page that used it, or a migration script that rewrites saved content. Server-rendered blocks store attributes and produce markup from code at request time, so one correction applies everywhere, including pages published three years ago. Page builders also ship a large runtime to every visitor; a block library ships the markup the page actually needs.
-
What happens if we change themes later?
With server-rendered blocks, content survives the change because it was never HTML in the first place. Attributes are structured data, so the same content can be re-rendered against new templates or a new design system. That property is also what makes a future migration possible rather than an archaeology exercise.
-
Can editors still break the design?
Far less, and that is deliberate. Options are limited to the choices a designer sanctioned, spacing and containers live in layout primitives rather than in per-page settings, and where page shape matters we lock templates and restrict which blocks are allowed. Editors get real freedom in how components are arranged and very little in how each one looks, which is the split that keeps a four hundred page site coherent.
-
How many custom blocks does a site actually need?
Fewer than people expect, and the number is a design decision rather than a count. This site runs on twelve, which covers every page on it. The mortgage platforms needed more because they carry broker directories, rate tables and calculators. A library that keeps growing is usually a sign that the layout primitives were not composable enough.
-
Do you use full site editing and block themes?
Selectively. Block themes and theme.json are a genuine improvement for sites whose templates should be editable, and we use them where that is true. For platforms with a strict design system, editorial governance and accessibility obligations, a classic theme with a custom block library gives tighter control over markup and over what editors can change. We decide per project rather than by fashion.
-
We have years of content in the classic editor. What happens to it?
It keeps working, and it can be converted. Classic content renders as-is, so nothing breaks on the day the new library ships. Converting it into blocks is a scripted job, which is exactly the kind of work the migration page covers, and it is normally done for the templates and page types that matter rather than for the whole archive.