Gutenberg

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. Custom Gutenberg block development is the work of building that component set: each block stores its settings as structured data and renders its markup from PHP when the page is requested, instead of saving HTML into the database.

  • Server-rendered blocks: markup comes from PHP at request time, not from saved HTML
  • A small set of components, each limited to the options a designer approved
  • Structure and accessibility enforced by the block rather than documented in a manual
  • Editorial sidebars and tooling where the workflow needs them
Discuss your project
Approach

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.

Dynamic blocks

Blocks that query content or call an integration at render time: portfolio grids, directories, filtered listings, live data. Configured by editors, rendered by code.

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.

Evidence

Block libraries running in production

Four delivered libraries, and what each one changed for the people who use it. That is the part worth judging: a block count says nothing about whether a team can run its own site.

One fix reaches five brands

Multi-Prêts, Mortgage Alliance, Invis, Mortgage Intelligence and Intelligence Hypothécaire, the five M3 Tech brands we supported from 2021 to 2025, share one library held in a parent theme, with a child theme each. Correcting a heading level, a focus state or a card layout is one change that reaches all five, instead of the same edit made five times and forgotten on the fifth.

A shop run without a developer

On iAmEvolving® the founder publishes products, prices, course lessons and campaign pages from the WordPress editor, with no page builder and no commerce plugin underneath. The purchase flow is assembled from components rather than configured in someone else’s plugin, so changing it does not mean filing a ticket.

Permissions the editor cannot get wrong

Doolittle Lake Club separates member content from shareholder content. The download button checks who is asking before it serves a file, and the listing blocks filter by role on render, so a club administrator cannot publish the wrong document to the wrong audience by choosing the wrong block.

The page you are reading

wplook.ca runs on the same approach, which makes it the one claim on this page you can check yourself. Open the source: every section, card and accordion here was produced by PHP at the moment you requested it, and none of it is HTML saved in a database.

Start a project

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.

Tell us about your project
Practicalities

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.

FAQ

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 nineteen, 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.

  • Do custom blocks slow the site down?

    No, and usually the reverse. A page builder ships a large JavaScript and CSS runtime to every visitor whether the page uses it or not. A server-rendered block produces plain markup in PHP, so a page carries only what it actually needs and nothing is assembled in the browser. Where a block does query content or call an external service, the caching strategy is decided for that block rather than bolted on at the end.

  • Can you build custom blocks for the theme we already have?

    Usually yes, and it is a good way to start. A block library is registered independently of the theme, so blocks can be added to an existing build and adopted page by page without a redesign. The limit is the theme itself: if its templates and stylesheet fight the markup the blocks produce, you end up styling around it, and at that point rebuilding the theme is cheaper than continuing to patch it. We will tell you which case you are in after looking at the code.

  • 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.