Custom Gutenberg Block Plugin Development

Your editors need a block that does not exist: a pricing table tied to your products, a testimonial carousel with real controls, a form block that posts to your CRM. We write custom Gutenberg block plugin code the way core does it, with block.json, React edit components and server-side rendering, so the block survives updates and theme changes.

get a free block review

what you get when we write custom Gutenberg block plugin code

A fixed-scope plugin containing your blocks, built to WordPress coding standards and ready for your theme or a headless front end.

get a quote

Blocks built the core way
Each block defined in block.json with attributes, supports and styles, an edit component in React using @wordpress/components, and a save or render callback that outputs clean markup.
Dynamic and data-driven blocks
Blocks that pull from custom post types, ACF fields, WooCommerce products or REST endpoints, rendered server-side so content stays fresh without editing the block.
Patterns, variations and editor controls
Block patterns and variations for common layouts, InnerBlocks templates with locking, and editor-side restrictions so authors can only place blocks where they belong.

how we write custom Gutenberg block plugin code that lasts

Most custom blocks on WordPress sites are not really custom. They are ACF Blocks with a PHP template, a page-builder widget, or a shortcode wrapped in a block. Those work until the theme changes, the plugin that provides them is abandoned, or an editor needs a control that the wrapper does not offer. When we write custom Gutenberg block plugin code, we build it the way WordPress core builds its own blocks, so it keeps working through core updates and theme swaps.

when a custom block is the right answer

You need a custom block when editors repeatedly build the same layout by hand, when a design element needs data from somewhere else (products, events, team members, pricing), when the layout must be locked so it cannot be broken, or when you are moving to a headless WordPress front end built with React and need blocks that render predictably in both environments. You do not need one for a one-off layout, which a block pattern handles, or for simple styling, which theme.json and block styles handle.

how a block is structured

Every block we ship lives in a plugin, never in the theme, so it survives a redesign. The plugin is scaffolded with npx @wordpress/create-block and built with @wordpress/scripts, which handles the Babel, webpack and dependency-extraction configuration. Each block has:

block.json declaring the name, attributes, supports (colour, spacing, typography, alignment), styles, and script and style handles.
An edit.js React component using useBlockProps, InspectorControls, RichText and components from @wordpress/components for the sidebar controls.
Either a save.js that outputs static markup, or a render.php callback for dynamic blocks registered through register_block_type() pointing at the block directory.
A deprecated.js entry whenever the markup changes, so existing content migrates instead of showing the “unexpected or invalid content” error.

Attributes are typed and given defaults, the block is registered on init, and editor assets are enqueued only on screens that need them. We follow the WordPress coding standards, run PHPCS and ESLint, and ship a readme so anyone can pick the plugin up later.

dynamic blocks and data

Blocks that show products, posts, events or pricing are rendered server-side. The edit component uses useSelect and @wordpress/core-data to fetch the same data the front end will use, so editors see a live preview rather than a placeholder. Where the data comes from outside WordPress, the block calls an endpoint we build through our custom REST API integration for WordPress service, with caching so the editor does not hammer a third-party API on every keystroke. The ServerSideRender component is available for simple cases, but we prefer a proper edit preview because it is faster and gives editors real controls.

InnerBlocks, patterns and locking

Composite layouts such as cards, accordions and feature grids use InnerBlocks with a template and allowedBlocks, so an author can add a card but cannot drop a video inside a pricing column. We register block patterns with register_block_pattern() for layouts editors reuse, and block variations for the same block with different presets. Where the design must not be broken, we use templateLock and the lock attribute. The allowed_block_types_all filter trims the inserter to the blocks the site actually uses, which is the single change that most reduces support tickets from editors.

styling, theme.json and compatibility

Block styles are scoped to the block wrapper and use CSS custom properties from theme.json so they follow the site palette and spacing scale without hardcoded values. We test each block in the editor and on the front end across the current WordPress release and the previous major, on the block theme or classic theme the site uses, and alongside plugins such as WooCommerce, ACF, Yoast and Rank Math. If you also want existing ACF Blocks or shortcodes converted into native blocks, we can include that migration in the scope. Projects that need a whole site of blocks and templates are usually better handled under our full website development service.

timeline, pricing and what you get

A single moderately complex block, including controls, preview, front-end rendering and testing, is typically one to two weeks. A plugin with five to ten related blocks, patterns and a settings screen runs three to six weeks. When we write custom Gutenberg block plugin projects, each one is quoted as fixed scope and fixed price after reviewing the designs, agreed in writing before work starts. You receive the plugin in a Git repository with build tooling, documentation for editors and developers, and a handover call. Updates can be covered under a maintenance plan if you would rather not own the build chain.

If you want to see how the pieces fit before hiring anyone, read our guide on how to write a custom Gutenberg block plugin without breaking your layout. When you are ready to talk about your blocks, send us the designs or a description and we will reply within 24 hours with scope, timeline and cost.

how a block project runs

Review designs and content model

We look at the designs, the data each block needs and how editors will use it, then define the block list, attributes and controls. That becomes the written scope and fixed price.

Build with editor previews

Blocks are built in a plugin with live editor previews and reviewed by your editors on staging, so controls and behaviour are corrected before front-end polish and testing.

Test, document and hand over

We test across WordPress versions, your theme and key plugins, add deprecations for any markup changes, and hand over the repository with editor and developer documentation.

questions we get asked about custom blocks

How much does a custom Gutenberg block cost?

It depends on the number of blocks, whether they are static or data-driven, and how many editor controls they need. A single block is a small fixed-price project; a suite of blocks is scoped in phases. Send us the designs and you will have a fixed quote within 24 hours.

Will the blocks break when WordPress updates?

Blocks built with block.json, the official @wordpress packages and deprecation entries use the same approach core uses, so they are the most update-resilient option available. We test against the current and previous WordPress major releases and include a deprecation whenever markup changes.

Can the blocks work with our existing theme and ACF?

Yes. The blocks live in their own plugin and use theme.json values for colours and spacing, so they follow your theme without depending on it. They can read ACF fields, WooCommerce data or custom post types, and we can convert existing ACF Blocks to native blocks if you want.

What do you need from us to start?

Designs or wireframes for each block, a note on where the data comes from, admin access to a staging copy of the site, and someone on your team who edits content and can test. If you have an existing plugin or block code, we review that first.

need a block your editors will actually use?

Send us the design, a description of what the block should do and where its data lives. You will get a straight answer on scope, timeline and cost within 24 hours, and a fixed price in writing before we write a line of code.

start a project