Recommended Free Tools
Use the API that matches the way the style was registered. For a server-side style registered with PHP, call unregister_block_style( $block_name, $block_style_name ) on init after the registration callback runs. For a style registered in editor JavaScript—including most styles supplied by core—enqueue an editor script and call wp.blocks.unregisterBlockStyle( blockName, styleName ) inside wp.domReady(). The names must be the registered block name and slug, not the label shown in the editor.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What WordPress calls a block style variation
A block style is an alternate presentation attached to an existing block. Selecting it in the editor normally adds a class such as is-style-fancy-quote to the block wrapper. The block remains the same block; its attributes and basic markup do not become a different block type.
As an Amazon Associate I earn from qualifying purchases.
WordPress documentation also uses the phrase “block style variations” for these styles. That terminology should not be confused with either global style variations or block variations. A global style variation changes site-wide design settings. A block variation can define a different set of attributes, inner blocks, or markup for a block. The removal APIs are different, so identifying the object before writing code is the first step.
Choose the removal API from the registration source
| How the item was registered | Removal API | Where and when to run it | What it affects |
|---|---|---|---|
PHP register_block_style() |
unregister_block_style() |
PHP on init, after the registering callback; a later priority is commonly needed |
Server-registered block styles |
JavaScript registerBlockStyle() |
wp.blocks.unregisterBlockStyle() |
Editor script inside wp.domReady() |
Client-registered editor styles |
| A style supplied by core in the editor | Usually wp.blocks.unregisterBlockStyle() |
Enqueue an editor script and wait for DOM readiness | The style entry shown in the block editor |
| A block variation rather than a style | wp.blocks.unregisterBlockVariation() |
Editor JavaScript after the variation has registered | A variation that changes attributes, inner blocks, or structure |
PHP cannot remove a style that exists only in JavaScript, and JavaScript cannot remove a style that was registered only on the server. If you use the wrong side, the call can execute without changing the editor.
Before unregistering: find the exact block and style identifiers
Both APIs require machine identifiers. The first argument is the namespaced block name, for example core/image or core/quote. The second is the style slug, for example hand-drawn or large. The human-readable label—such as “Hand Drawn” or “Large”—is not a safe substitute.
- Inspect the code that calls
register_block_style()orregisterBlockStyle(). - Copy the block name exactly, including its namespace and slash.
- Copy the style slug exactly, including hyphens and capitalization.
- Do not infer a slug from the translated label displayed in the editor.
If the registration comes from a theme or plugin you did not write, search its PHP and JavaScript assets for the registration functions. Browser developer tools can also reveal the block name and style name in the editor’s registered block data, but the source declaration is the most reliable reference.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Unregister a PHP-registered block style
The PHP function has this signature:
unregister_block_style( string $block_name, string $block_style_name ): boolIt returns true when the style was successfully removed and false when no matching registered style could be unregistered. The function was introduced in WordPress 5.3.0.
Basic implementation
add_action( 'init', 'mytheme_unregister_block_styles', 999 );
function mytheme_unregister_block_styles() {
unregister_block_style( 'core/image', 'hand-drawn' );
}This example removes the hand-drawn style from the core/image block. Put the code in a theme’s functions file or, preferably for a change that should survive theme changes, in a site-specific plugin.
Why the priority matters
Action callbacks at the same hook run in priority order, with lower numbers first. A registration callback using the default priority can run before the unregistration callback above, whose priority is 999. That ordering lets the style exist before WordPress tries to remove it. The number is not magic: match the actual registration priority in your project. If a plugin registers its style at priority 20, schedule the removal after priority 20 rather than assuming 999 is always necessary.
- Locate the callback that calls
register_block_style(). - Record its hook and priority. Most registrations use
init, but verify the code. - Attach your unregistration callback to the same hook at a later priority.
- Use the exact namespaced block name and style slug.
- Clear any server and editor caches, then open a new editor session to verify the style list.
Removing several server-registered styles
add_action( 'init', 'mytheme_unregister_selected_styles', 999 );
function mytheme_unregister_selected_styles() {
unregister_block_style( 'core/image', 'hand-drawn' );
unregister_block_style( 'core/quote', 'large' );
}Keep each pair explicit. A failed call for one style returns false but does not prevent the other calls from running. If you need diagnostics while developing, capture the return value in a temporary log statement; remove debugging output from production code.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Unregister a JavaScript-registered style
Styles registered through client-side code must be removed in the editor with wp.blocks.unregisterBlockStyle(). The removal should run after editor scripts have registered their styles. WordPress’s documented pattern is an editor asset loaded through enqueue_block_editor_assets, with the removal call inside wp.domReady().
Rank #2
- Book - 1, 000 books to read before you die: a life-changing list (1000 before you die)
- Language: english
- Binding: hardcover
Enqueue the editor script
add_action( 'enqueue_block_editor_assets', 'mytheme_block_editor_assets' );
function mytheme_block_editor_assets() {
wp_enqueue_script(
'mytheme-block-editor',
get_theme_file_uri( 'assets/js/block-editor.js' ),
array( 'wp-blocks', 'wp-dom-ready', 'wp-edit-post' ),
filemtime( get_theme_file_path( 'assets/js/block-editor.js' ) )
);
}The dependencies in this pattern are wp-blocks, which provides the block APIs; wp-dom-ready, which provides the readiness helper; and wp-edit-post, which ensures the script is loaded in the post editor context. Use a stable version string instead of filemtime() if your deployment process already handles asset versioning, but always declare the dependencies that your script uses.
Remove the style after registration
wp.domReady( function () {
wp.blocks.unregisterBlockStyle( 'core/quote', 'large' );
} );wp.domReady() prevents a race in which your code runs before the block editor has registered the style. The call’s block name and style name must match the values passed to registerBlockStyle(). A label such as “Large” will not work if the registered slug is different.
Editor-only testing sequence
- Place the PHP enqueue code where it runs only for editor assets.
- Create
assets/js/block-editor.jsat the path used by the enqueue call. - Add the
wp.domReady()callback and the exact unregister call. - Open the block editor, select the target block, and inspect its Styles panel.
- Test a fresh editor session after clearing a script cache; an already-open editor tab may still contain the old registration.
Core styles generally require the JavaScript route
Many styles supplied by core are registered in the editor’s client-side code. For those styles, adding unregister_block_style() in PHP does not remove the editor entry because no matching server registration exists. Enqueue the JavaScript removal pattern instead, and wait for wp.domReady().
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThis does not mean every style associated with a core block is client-side. Confirm the registration source when a theme or plugin adds its own style to a core block. The registration origin, not the block’s namespace, determines which API is appropriate.
Do not confuse a block style with a block variation
A style normally changes presentation through a style class. A block variation can change the block’s default attributes, provide predefined inner blocks, or alter the structure presented to the editor. If the item you want to remove changes those things, use the variation API instead:
wp.domReady( function () {
wp.blocks.unregisterBlockVariation( 'core/query', 'my-variation' );
} );The variation name in this example is illustrative: replace it with the exact registered variation name. Do not substitute unregisterBlockStyle() simply because both items appear as choices in the editor. WordPress’s documentation explicitly distinguishes block style variations from global style variations and block variations.
A repeatable diagnosis and implementation workflow
When a style must disappear from a production site, separating identification, removal, and verification prevents most mistakes.
- Describe the visible behavior. If selecting the option only changes a wrapper class beginning with
is-style-, start with the block-style APIs. If it inserts inner blocks or changes attributes, investigate a variation instead. - Find the registration declaration. Search the active theme and plugins for
register_block_styleandregisterBlockStyle. A core style may be present only in the editor bundle, so the absence of a PHP declaration is meaningful. - Record hook, priority, and identifiers. For PHP, note the action hook and numeric priority. For JavaScript, note the bundle that loads the registration and the exact slug.
- Implement one removal path. Do not add both APIs as a guess. Using the matching side makes failures easier to interpret and avoids maintaining unnecessary editor code.
- Check the return or runtime state. A PHP
falseresult indicates that the requested pair was not registered at that point. In JavaScript, inspect the Styles panel after the readiness callback has run. - Verify a clean session. Close old editor tabs, refresh with the current asset version, and test the block in a new post. Cached JavaScript can make a correct change appear ineffective.
PHP and JavaScript: practical trade-offs
| Comparison point | PHP removal | JavaScript removal |
|---|---|---|
| Registration origin | Server callback using register_block_style() |
Editor bundle using registerBlockStyle() |
| Execution timing | After the registration callback on its action hook | After editor registration, normally inside wp.domReady() |
| Scope | Server-side registration state | Client-side editor registration state |
| Asset work | No additional editor bundle is needed | Requires an enqueued editor script and declared WordPress dependencies |
| Diagnostic signal | A boolean return value | The resulting editor registry and Styles panel |
Neither route is inherently faster or more correct. Registration origin, timing, and object type decide the implementation. A small PHP callback is preferable for a PHP-registered style; adding a JavaScript bundle solely to remove it adds avoidable maintenance. Conversely, a PHP callback cannot reach a style that is created only when the editor’s JavaScript runs.
Staging, deployment, and maintenance precautions
Test the change in a development or managed staging environment before applying it to a busy site. The code itself uses WordPress APIs and does not require a physical product, paid extension, or separate license. The main resource cost is implementation and testing time, especially when several plugins register similarly named styles.
Keep the removal in a site-specific plugin when it represents a site policy rather than a presentation detail tied to one theme. If the code belongs only to a theme’s design system, the theme’s functions file can be appropriate. Document the original registering plugin or theme, the discovered priority, and the slug you removed. This record makes future troubleshooting easier when an update changes registration timing or restores a style.
After deployment, check both the post editor and any other editor context in which the asset may load. Confirm that the intended style is gone, that unrelated styles remain, and that the front end still renders existing blocks as expected. Removing a choice from the editor should not be treated as proof that its CSS or saved classes have disappeared.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why an unregister call appears to do nothing
1. The registration side is wrong
Check whether the original code is PHP or JavaScript. A PHP call cannot see a style created only after the editor loads its JavaScript, while a JavaScript call cannot undo a server-side registration that was never exposed to the client in the same way. Move the removal to the matching side rather than adding more copies of the wrong API.
2. The identifier is not exact
Use core/image, not “Image,” and use the slug, not the visible label. Hyphens, underscores, and capitalization matter. Verify both strings against the registration declaration.
3. JavaScript ran before registration
If the browser console shows no error but the style remains, a timing race is likely. Wrap the call in wp.domReady() and ensure the script declares wp-blocks, wp-dom-ready, and wp-edit-post as dependencies for the editor pattern.
4. PHP ran before registration
A server-side call made on init at the default priority can precede a later registration callback. Attach the removal callback at a later priority than the registration, using the actual priority used by the theme or plugin.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →5. You are removing a variation, not a style
Look at what the choice changes. A style that only adds an is-style-… class uses the block-style API. A choice that changes attributes, inner blocks, or structure is a block variation and needs unregisterBlockVariation().
6. The editor is cached or stale
Unregistration affects registration in the editor; it does not rewrite an editor tab that already loaded the old scripts. Close and reopen the editor, clear relevant script caches, and test in a fresh session. Confirm that the new asset version is actually being served.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What these APIs do not remove
Unregistering a style controls the registered option presented by the editor. It does not remove CSS files, selectors, or other styling rules from a theme or plugin. If the style’s CSS is no longer needed, remove or conditionally enqueue that stylesheet separately after confirming that no remaining content relies on it.
It also does not edit posts that were already saved with the style class. Existing content can retain a class such as is-style-fancy-quote even after the option disappears from the Styles panel. Decide separately whether to leave those classes rendering as before, migrate the content, or remove the associated CSS. Unregistration alone is not a content migration tool.
Version and registration notes
unregister_block_style()was introduced in WordPress 5.3.0.- WordPress 6.6 added
style_datasupport for block-style registration. That registration data does not change the fundamental choice between the PHP and JavaScript removal APIs; still identify where the style was registered. - There is no performance or usage benchmark that determines one method as universally better. The correct method is the one that matches the registration origin and runs after registration.
Deployment checklist
- Identify whether the target is a block style, global style variation, or block variation.
- Copy the exact block namespace and style or variation slug.
- For PHP registration, call
unregister_block_style()on the correct hook after the registration priority. - For JavaScript registration, enqueue an editor script and call
wp.blocks.unregisterBlockStyle()fromwp.domReady(). - Use
wp.blocks.unregisterBlockVariation()for a true block variation. - Test in a new editor session, then check existing content and CSS independently.
- Check the boolean result of the PHP function during development so an unexpected
falseexposes a registration or identifier problem.
Practical decision examples
A theme adds a PHP image style
The theme calls register_block_style( 'core/image', … ) from an init callback. Add your own init callback at a later priority and call unregister_block_style( 'core/image', 'hand-drawn' ). No editor JavaScript is required for this server-registered style.
A plugin adds a quote style in JavaScript
The plugin calls registerBlockStyle() while its editor bundle loads. Enqueue your removal bundle through enqueue_block_editor_assets, declare the documented WordPress dependencies, and call wp.blocks.unregisterBlockStyle( 'core/quote', 'large' ) from wp.domReady().
A core choice inserts a predefined block structure
If selecting the choice changes attributes or inserts inner blocks rather than merely applying a style class, treat it as a block variation. Remove it with wp.blocks.unregisterBlockVariation() after the variation is registered; a block-style removal call targets the wrong object.
Frequently Asked Questions
How do I unregister a block style in WordPress?
Identify how it was registered first. Use unregister_block_style( $block_name, $block_style_name ) on PHP’s init hook after the registration callback, or use wp.blocks.unregisterBlockStyle( blockName, styleName ) in an editor script inside wp.domReady() for a JavaScript-registered style.
Why does unregister_block_style() not remove a core style?
Many core editor styles are registered in client-side JavaScript rather than with PHP. In that case, the PHP function has no matching server registration to remove. Enqueue an editor script and call wp.blocks.unregisterBlockStyle() after wp.domReady().
What is the difference between unregisterBlockStyle and unregisterBlockVariation?
unregisterBlockStyle() removes an alternate presentation that normally applies an is-style-… class. unregisterBlockVariation() removes a variation that can change attributes, inner blocks, or structure. They target different registries.
Does the visible style label work as the second argument?
No. Use the registered slug, such as hand-drawn or large, not a translated or capitalized label such as “Hand Drawn” or “Large.”
What does a false PHP return value mean?
It means no matching registered style could be unregistered at that point. Check the namespace, slug, hook, and priority, and confirm that the original registration actually uses PHP.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWill unregistering a style remove it from existing posts?
No. Saved content can retain classes such as is-style-fancy-quote. Unregistration removes the registered editor option; it does not migrate post content or delete CSS.
Do I need to buy a plugin or other product?
No physical product, paid extension, or separate license is required. The procedure uses WordPress’s built-in PHP and JavaScript APIs. A staging environment can help you test safely, but it is an implementation choice rather than a requirement.
Which WordPress versions support the PHP function?
unregister_block_style() was introduced in WordPress 5.3.0. WordPress 6.6 also added style_data support for block-style registration, without changing the basic PHP-versus-JavaScript decision.
The Bottom Line
Find the registration source, copy the exact block and slug identifiers, and remove the item on the same side after registration. Use PHP unregister_block_style() for PHP registrations, JavaScript wp.blocks.unregisterBlockStyle() inside wp.domReady() for editor registrations, and unregisterBlockVariation() when the choice changes block structure or attributes. Then test a fresh editor session and handle saved classes and CSS separately.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
