Gutenberg blocks

Why does your editor assemble a page from plugins instead of ready-made blocks?

I build custom Gutenberg blocks the modern way: PHP block classes through ACF Composer, dynamic blocks rendered on the server, a preview in the editor that matches the site, and a reusable block library shared across a client's sites.

Discuss the blocks Back to the home page

Most WordPress business sites look the same on the inside today: a page builder bundled with the theme, a pack of add-ons for the builder, and one more plugin just for icons. The editor then assembles a page from dozens of settings nobody documented, and every section can be built in three different ways. The result looks usable, but the HTML carries five nested wrappers too many, mobile visitors download half a megabyte of CSS for features the site will never use, and a builder update quietly breaks the layout of pages that have not been touched in years.

Gutenberg solves this differently. The editor ships with WordPress, so there is no third layer sitting between content and template. The blocks the editor sees are ones I define: exactly the fields that make sense, exactly the variants the brand has approved, and not a single setting more. I write blocks as PHP classes through ACF Composer, the content renders on the server, and in the editor it looks the same as it does on the site. Editors do not get the freedom to break the design, but they do get the freedom to publish any page without calling me first.

A custom block versus a page builder

A page builder is a general-purpose tool that has to handle every site in the world, so it brings into your project everything your project does not need. A custom block is the opposite: it does one thing, it has named fields, and it outputs exactly the markup the theme expects. Editors do not pick typefaces or inner spacing, because those belong to the design system, not to the content. Ten to fifteen blocks are usually enough to assemble an entire site, and that very constraint is what keeps pages consistent after two years and five different people in the admin.

One block, one job, named fields
Markup matches the theme, not a generic builder
Editors cannot accidentally break the design
No hundreds of kilobytes of extra CSS and JS
Ten to fifteen blocks cover a typical business site

Blocks as PHP classes through ACF Composer

I do not define blocks by clicking around the admin, I define them in code. ACF Composer gives every block its own PHP class declaring its fields, preview data and editor supports, with a Blade template alongside it. The definition therefore lives in git with the rest of the theme, it can be reviewed in a pull request, and it reaches staging and production through a deploy rather than a JSON export dragged through the admin. When a block changes, the change is visible in history and can be reverted. That is the difference between a theme another developer can take over and a theme that has to be reverse-engineered out of the database.

Block fields and settings in a PHP class
The block template as a Blade component
The whole definition in git, not in the database
The same block set on staging and production
Handover without database archaeology

Dynamic blocks rendered on the server

A static block saves finished HTML into the post content, which is fine for plain text and a trap for anything that lives. If a block is supposed to show the latest articles, products in a category, testimonials or upcoming dates, the HTML in the database goes stale the moment it is saved. A dynamic block stores only its settings and the output is rendered when the page is requested. A template change then flows through every existing page at once with no content migration, and translation stays easy because the strings come from the template instead of being frozen inside old saved output.

The database holds settings, not stale HTML
Article, product and testimonial listings always current
A template change reaches every page at once
Easier translations and language versions
No migration script after every design tweak

An editor preview that matches the site

The most common complaint about custom blocks is that the editor shows a grey rectangle with a label, so the editor has to save and reload the page to see what it looks like. That is avoidable. I render the block in the editor with the same template as on the front end, add preview data for the empty state, and load editor styles from the same build as the frontend. Editors then write directly into what the visitor will see. At handover I add a short description and an icon to every block so the inserter panel makes it obvious what each one is for.

The same template in the editor and on the site
Preview data for empty and freshly inserted blocks
Editor styles from the same build as the frontend
A description and icon on every block
No saving required just to see the result

A block library across a client's sites

The real saving does not appear on the first site, it appears on the third. For a client running several sites on the same platform I built a block library with a hero section, cards, frequently asked questions and a gallery, and it is used across all of their template sites. A new site then does not start from an empty theme but from a finished set, with only the genuinely project-specific parts added on top. I work at 40 EUR per hour including VAT. A single new block is usually 2 to 5 hours, and a base library for a site typically lands between 12 and 30 hours.

Hero, cards, FAQ and gallery as a shared base
A new site starts from a finished block set
A fix in the library reaches every site
A single block roughly 2 to 5 hours
A site library 12 to 30 hours at 40 EUR per hour including VAT

Frequently asked questions about Gutenberg blocks

Can custom blocks replace Elementor or WPBakery?

On most business sites yes, and the page usually gets noticeably faster after the swap. A builder makes sense when someone without a developer has to assemble content and the design is not fixed. If the site has brand guidelines and repeating sections, custom blocks are cheaper to maintain.

Do I need ACF Pro or can a block be built without it?

Blocks can be written in pure React without ACF, but for a typical business site that is the more expensive route. ACF Pro with ACF Composer lets both the fields and the template live in PHP, which makes the initial build and every later change considerably faster.

What happens to existing content when a block changes later?

With dynamic blocks the database only holds the settings, so a template change flows through every page at once with no migration. If a new field is added it gets a sensible default so older pages keep rendering correctly.

Can editors use custom blocks without training?

Usually yes, because a custom block has fewer settings than any builder. At handover I walk through every block, its fields and its preview. If the team is larger I also leave short written documentation inside the admin itself.

What does a set of custom blocks cost?

A single block runs 2 to 5 hours depending on complexity, which is 80 to 200 EUR including VAT at 40 EUR per hour. A base library for a business site typically lands between 12 and 30 hours. Variants and dynamic listings are what move the number.

Want an editor where a page is assembled in ten minutes?

Tell me which sections repeat across your site and what your editors struggle with today. I will propose the block set that covers it and how many hours it takes.

Discuss the blocks