WordPress register_block_style Example: Add Editor Variations Cleanly

Last reviewed: April 29, 2026

The block editor gets messy when every visual variation becomes a custom block or a one-off CSS hack. register_block_style() gives themes and plugins a lighter option: keep the core block, but add a named variation editors can choose directly in the interface.

This guide shows how to register a custom block style and attach a predictable class name to the saved markup.

Register a style variation on init

<?php
add_action( 'init', 'vulnwp_register_block_styles' );

function vulnwp_register_block_styles() {
	register_block_style(
		'core/quote',
		array(
			'name'         => 'signal',
			'label'        => __( 'Signal', 'vulnwp' ),
			'inline_style' => '.wp-block-quote.is-style-signal{border-left:4px solid #14532d;padding-left:1.25rem;background:#f3f8f4;}',
		)
	);
}

Editors then keep using the core Quote block, but WordPress adds the is-style-signal class when that variation is selected.

Use block styles for presentation, not for new content structure

If the difference is visual, block styles are usually enough. If the difference changes the block’s data model, controls, or render logic, that is closer to a custom block than a style variation.

Keep the style name stable

The machine name ends up in saved content as a CSS class fragment. Renaming it carelessly later can orphan older content visually.

Prefer shared design vocabulary over ad hoc labels

Names like signal, muted, or highlight age better than labels tied to one landing page campaign or one quarter’s design experiment.

Production checklist

• Register block styles on init.
• Use stable machine names because they map to saved CSS classes.
• Reserve style variations for visual differences, not new block behavior.
• Keep the label understandable for editors.
• Test the saved class output in both editor and front-end contexts.
• Document which variations belong in the design system.

Common mistakes

• Using styles as a substitute for a real custom block. Visual variations are not a data model.
• Renaming the style slug later. Saved content can lose the intended presentation.
• Creating too many near-identical variants. Editorial UI becomes noisy fast.
• Relying on vague labels. Editors need clear choices.
• Forgetting front-end CSS coverage. Editor-only styling is not enough.

Related reading

If the block itself is custom and registered from metadata, pair this with the block.json guide. If editors need reusable starter layouts instead of visual variations, continue with the block pattern article.

References and further reading

• WordPress Code Reference: register_block_style()
• WordPress Block Editor Handbook: Block Styles
• WordPress Code Reference: unregister_block_style()