Editable Blocks Inside the Custom HTML Block in 7.1

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.

This is one of those quiet dev notes that will look small in the field guide and then reshape three or four workflows a year from now. Worth reading 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.

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.