Renderer final class

The dynamic core blocks that ask block_default_classname even when they render nothing (generatedClass()).

The dynamic core blocks that never ask it (the tabs and accordion blocks edit their saved markup instead).

Whether the next block renders without the block filters around it (renderNativeUnfiltered()).

Whether the next block renders as its render callback called alone would (renderNativeAsCallback()).

Promoted from the constructor.

The numbered companion of a block style variation the block's class names (is-style-{name}--N), consuming the counter: a variation with styles of its own, the theme's or a registered style's (the facade answers the private minn_block_style_variation filter), whose CSS the facade prints once numbered (minn_block_style_variation_used). Null when none applies.

The per-request rendering state: counters, containers, variations, the images seen.

What is being rendered.

Sets what is being rendered.

The image tag builder.

A renderer with every dynamic block wired over the database door.

Registers the engine's own renderer for a dynamic block. A plugin's callback that already took the block over (bridge()) keeps it, as a replaced render callback does on the reference.

Hands a block to a plugin's render callback; the engine's own renderer for it stays for renderNative().

One block as HTML through the engine's own renderer for its name (its static markup when it has none), even where a plugin's callback took the block over: what a core render callback gives, so a plugin's callback that calls the one it replaced does not call itself.

Block markup as HTML, texturized.

A tree of blocks as HTML.

A core block as renderNative() renders it, without the block filters around this one block (its inner blocks keep theirs): its caller, the facade's WP_Block::render, applies them once.

A core block as its render callback called directly renders it: not a block being rendered, so enqueue_empty_block_content_assets is not asked for it (its inner blocks are), as the reference asks it only in a block's render (probe plugin-surface2).

What the runtime does to an image block's markup once the engine has rendered it: the lightbox, when the image's settings or the theme's ask for one.

The context render_block_context already gave the next block, when render_block() or a WP_Block renders it: a block that provides its own context (a tabs block's id) reads it with ownContext() rather than asking again.

The context render_block_context gave the block that has just begun to render; null when nothing did. A block's renderer reads it first, before its inner blocks begin.

One block as HTML, with the filters around it (unless renderNativeUnfiltered() asked for this one without).

The context a block's bindings read: the post being rendered (postId, postType) and what enclosing blocks provide (a synced pattern's overrides).

Renders with context provided to the blocks inside (render_block_context's job on the reference). @param array<string, mixed> $context

Whether the engine's own renderer answers for a block: a core block no plugin's callback took over. It applies the block supports it knows itself (layout, element styles); the facade's render_block filters do the rest, and all of them for any other block.