Overall goal and scope

PHP-only blocks shipped in WordPress 7.0 (#71792), allowing PHP-oriented developers to register a block on the server without writing a JavaScript block implementation and giving features that currently live in shortcodes or meta boxes a clearer path into the block editor.

In this first iteration, a PHP-only block is registered with register_block_type() and rendered server-side; the editor just previews it through that callback and generates Inspector controls for a set of supported attributes.

The next round of work for 7.1 falls into three areas:

• Polish rough edges in the shipped API, especially post context in editor previews and the missing block.json schema entry.
• Improve the generated Inspector controls by consolidating them with the Block Fields system (today, a separate implementation) and adding richer field types like media, link, and rich text.
• Explore making PHP-only blocks editable in the canvas.

Tasks

• Forward the current post ID to server render requests during editor previews, so render_callbacks that depend on the edited post work in the editor (#78619, PR #78909). This is WIP and should land in a 7.0.X release, before 7.1.
• Add autoRegister to the block.json schema (schemas/json/block.json) and cover it with an integration test. It is already documented in the block supports docs, but it is missing from the schema.
• Consolidate the PHP-only block DataForm with Block Fields, align the configuration with the Field API, and support richer field types like media, link, and rich text (#74438).
• Make a PHP-only block's content editable directly in the canvas, beyond the Inspector, for blocks with fixed markup and a few editable areas. The approach is still open: see the Open questions and decisions requiredsection below.
• Write the dev note for developer-facing changes that land in 7.1.

Nice to have

• Add a how-to guide and a block-development-examples sample.
• Stabilize the editor bootstrap mechanism currently exposed as window.__unstableAutoRegisterBlocks.

Open questions and decisions required

The current model previews the block server-side and keeps editable data in the Inspector: while this is enough for dynamic blocks, it is not a great editing model for blocks where the user expects to edit parts of the content directly in the canvas.

The main question for this cycle is whether PHP-oriented registration should support fixed markup with a few editable areas, and if so, how. There are two possible paths:

• Pattern-based: define the block from an arrangement of regular blocks, where most of the structure is locked while a few areas are editable or bound to data: because those parts are just blocks, they can be edited in the canvas for free. This may need a new PHP registration surface, such as a template or pattern property on register_block_type.
• innerContent-based: piggyback on the new exploration in #79115, which proposes the underlying innerContent support that would allow us to start from static HTML and place editable, locked block islands inside it. This may avoid the need for a dedicated pattern/template API, but the static HTML wrapping the editable blocks is not part of the block tree.

So lots of decisions and explorations ahead:

• Decide which path to pursue, or how the two fit together if at all. The main risk is overlap: PHP-only blocks, content-only patterns, and synced patterns feel like variations of the same behavior and should converge rather than diverge further. Before adding another path, we need to check whether the existing mechanisms already cover the use cases. To inform the decision, we should:
  • Build a few representative PHP-only use cases with innerContent and document where it falls short in terms of PHP registration ergonomics.
  • Check whether content-only patterns already cover the pattern-based case.
  • Sketch how a PHP developer would declare static markup and editable parts without writing JavaScript.
• Decide how generated controls should be grouped, especially Content vs Settings (depends on Block Attribute Groups #73845).
• Decide how to proceed with the ToolsPanel refactor for generated controls (PR #75124).

Worth noting as out of scope: free-form, fully nestable inner blocks (#75794).