Editable Blocks Inside the Custom HTML Block in 7.1

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

For a long time the Custom HTML block was the corner of the block editor where you gave up on the block editor. You dropped a chunk of markup in, you got a preview iframe, and you accepted that any editor who wanted to change a word had to open the code modal. That worked for embedded widgets and third-party snippets. It stopped working the moment a language model started generating whole page sections that included both design markup and prose the client would actually want to edit next week.

The team has been circling this problem for the better part of a year, and the reason matters. If AI-assisted content in WordPress is going to be more than a demo, the format the model writes into has to be something a human can still edit in the same UI, with the same locks and permissions, without the agency getting a support ticket every Tuesday. Either you accept that AI output goes into a black-box block, or you find a way to make static wrappers and editable slots live in the same node. WordPress 7.1 picks the second path, and I think it picked correctly.

This is one of those quiet dev notes that looks small in the field guide and then reshapes three or four workflows a year from now. Read it carefully before Beta 4 pins the surface.

What is actually new

On July 23, 2026, Riad Benguella published Editable Blocks Inside the Custom HTML Block on Make/Core. The core change: the core/html block can now hold static HTML markup interleaved with real inner blocks. The static wrapper renders inert on the canvas and in the frontend. The inner blocks are edited in place, but locked — no move, no delete, no siblings inserted. Serialization round-trips unchanged, so nothing you already have in the database is affected.

The plumbing lives in Gutenberg PR #79115 by Riad Benguella, merged June 29, 2026 against the Gutenberg 23.6 milestone. It introduces a new block support called innerContent: an array of static HTML fragments where each null marks the position of an inner block. The parser keeps the array on the parsed block, the serializer interleaves the fragments with serialized inner blocks instead of calling save, and a new private InnerContent editor component renders the static markup inert while portalling inner blocks into <wp-inner-block-slot> placeholders at their positions. The Custom HTML block adopts innerContent unconditionally in the same PR — the old content attribute is gone, the canvas SandBox iframe is replaced with the new component, and the code modal re-parses on update so any <!-- wp:* --> segments you paste in become editable inner blocks the next time you close the modal.

Two weeks later, PR #79659 by the same author brought innerContent into block variations, merged July 2, 2026, also into Gutenberg 23.6. Variations of core/html can now declare their own static wrapper plus editable slots. The Gutenberg 23.6 release post from July 22 lists both PRs, and a companion fix (#79887) preserves innerContent when the block is transformed to Group or Columns. The whole surface backports into WordPress 7.1 via the Beta cycle that pins on July 15 and ships GA on August 19, 2026.

The registration looks like this in the dev note:

wp.blocks.registerBlockVariation( 'core/html', {
  name: 'testimonial-card',
  title: 'Testimonial Card',
  icon: 'format-quote',
  innerContent: [ '<div class="testimonial-card">', null, '</div>' ],
  innerBlocks: [
    [ 'core/paragraph', { content: 'An inspiring quote.' } ],
  ],
} );

The wrapper stays exactly as declared. The paragraph inside is edited in place. If an editor rewrites the paragraph, the variation stays identifiable because the static markup is unchanged. If someone edits the static markup, the variation is deactivated — that is deliberate, per the PR description.

Why it matters for WordPress and WooCommerce people

Three specific things get easier the day 7.1 lands.

First, AI-generated page sections stop being read-only. A model asked to produce a testimonial card, a product callout, or a two-column feature block can emit one Custom HTML block that mixes arbitrary markup with editable slots for the text the client will want to rewrite. No custom block build, no ACF field wiring, no shortcode wrapper. Just registerBlockVariation and a JSON blob the model targets. This is the first time WordPress core has a shape that a language model can safely write into without generating orphaned code the editor cannot touch.

Second, agencies stop reaching for a custom block every time a client wants a slightly-branded card. The design system markup lives in the variation, editors get exactly the fields they should touch, and the whole thing serializes to a single block in the database. The migration path from a custom block to a variation is now trivial in one direction (variations replace custom blocks for pure wrapper-and-slot cases) and unchanged in the other (real interactive blocks still deserve a real block).

Third, and this one is boring but real: the Custom HTML block no longer runs scripts on the canvas preview. The old SandBox iframe is gone, replaced with an inert renderer that strips inline handlers and blocks script execution. Any workflow that relied on live third-party scripts previewing inside the editor will need a Playground pass before 7.1 GA. Most sites will not notice. A handful of ancient dashboards will.

The WooCommerce framing is small but worth noting. Woo does not ship any block that leans on Custom HTML today, but plenty of stores use it inside product description pages for embedded warranty tables, spec sheets, and legal footers. Those keep working — serialization is byte-identical for existing content — and now those spec tables can have one editable price cell without inventing a shortcode. The WooCommerce 11.0 window on July 28 stays separate from the WordPress 7.1 window on August 19; do not put both in the same triage queue.

Variation or a real block: how I decide

The question I already get from teams is where the line sits, because a Custom HTML variation now overlaps a job custom blocks have owned for a decade. Here is the rule I use, and it has held up across every project where I have had to draw it.

Reach for a variation when the thing is a shape: a wrapper of static markup with a few text slots the editor should fill and nothing else. Testimonial cards, pull-quote layouts, a branded callout box, a spec table with one editable cell. If you can describe the whole component as “this markup, with these three text holes”, it is a variation, and it should be a variation — a 40-line registration beats 300 lines of block scaffolding plus a build step every time.

Keep the real block when the thing has behaviour: attributes that drive logic, controls in the inspector, a save function that does anything conditional, data fetched at render, or interactivity beyond editing text in a fixed slot. A booking widget, a product filter, a live pricing panel — those earn their scaffolding. The tell is simple: if you catch yourself wanting an attribute the editor sets through a sidebar control rather than by typing into the canvas, you are past the variation and into real-block territory. Do not fight it.

The trap to avoid is the middle: building a variation, then bolting escalating cleverness onto it until it is a de facto custom block held together with static markup and hope. When a variation starts wanting logic, stop and promote it to a real block. The seam WordPress just drew is clean; the cost comes from ignoring which side of it you are on.

What I would do (or not do) about it

This week, on staging with Gutenberg 23.6 or a WordPress 7.1 Beta build, run three quick audits.

One, grep every plugin and theme for the string SandBox imported from @wordpress/components, plus any editor script that assumes the Custom HTML canvas preview will execute JavaScript. If a legacy analytics dashboard or embed widget relies on that behaviour, patch it now or accept a broken preview in editors as of 7.1 GA. The frontend is unaffected.

Two, take one custom block that is really just a wrapper plus one or two RichText fields and rewrite it as a Custom HTML variation. Measure the diff. If it collapses from 300 lines of JavaScript plus a build step into 40 lines of variation registration, that is your migration signal for the rest of the design system. Do not rush to migrate everything — pick the flattest cases first.

Three, if you have an AI-assisted authoring integration on the roadmap, this is the surface to build against. Give the model a small library of registered variations, teach it to emit block-delimited output the parser will pick up, and stop trying to convince it to produce well-formed custom blocks. The variation contract is narrower and easier to validate.

What I would not do: ship a plugin that ships fifty pre-baked Custom HTML variations to public repositories. The surface is one week old, the block-variations discovery UI in the inserter is going to change again before RC 1 on August 5, and any variation you register today will need a re-review against whatever ships in the field guide. Wait for RC 1 for anything you want to publish, keep staging work moving.

Two decades in, the pattern that keeps WordPress relevant is not the flashy new block. It is that the platform quietly finds the right seam between what should be code and what should be content, and lets both live in the same file. This week that seam moved a little further, and AI-generated content finally has a shape that respects it.