The WordPress Block Manager is the Blocks section inside editor Preferences. It lets a user hide unwanted blocks from their inserter. Existing content and block registration remain intact.
Use it when too many choices slow everyday writing. Hide duplicates, specialised blocks, and rarely used options. Reset the list whenever a missing choice becomes useful again.
This is personal workspace curation, not site-wide governance. Other users can keep different preferences. Administrators need separate enforced rules for consistent policy.
What the Block Manager changes
Your personal inserter choices.
Existing block content and registration.
Another user’s available choices.
Lower frontend or editor weight.
How to open WordPress block preferences
- Open a post or page in the block editor.
- Select the three-dot Options menu.
- Select Preferences.
- Open the Blocks section.
- Search or browse the available block list.
- Uncheck blocks you want hidden.
- Close Preferences and test the inserter.
The Site Editor includes a similar Preferences route. Available choices depend on registered blocks and context. WordPress versions can adjust labels and layout.
The official Preferences overview documents the current interface. Check it when a menu label moves after an update.
Search before scrolling
A large plugin stack can register hundreds of inserter items. Searching by title is faster than browsing categories. Start with obvious duplicates and specialised tools.
Search uses displayed names, not always registered identifiers. Similar titles can belong to different providers. Check the description or icon before hiding anything.
Hide one group at a time. Then test your normal writing tasks. Broad first-pass cleanup can remove an occasional but important choice.
Start with genuine duplicates
Several plugins may provide testimonials, buttons, icons, tables, or tabs. Keeping every version visible slows recognition. Choose one preferred owner per job.
Do not choose only by title. Compare output, accessibility, existing usage, and team familiarity. Hide alternatives after confirming the preferred block.
Hiding duplicates does not migrate old instances. Those remain owned by their original providers. Use a separate inventory and replacement plan before removing plugins.
Hide specialised blocks until needed
A documentation writer rarely needs Site Logo or Query Pagination blocks. A theme editor may need both. Personal curation can reflect actual work.
Keep foundational blocks visible. Paragraph, Heading, List, Image, Group, Row, and Buttons cover common tasks. Your workflow may justify different essentials.
Hide advanced blocks instead of memorising their categories. Restore them for specialised projects. This keeps the daily interface smaller without permanent restrictions.
Enable the most-used blocks section carefully
Preferences can show frequently used blocks near the inserter. This helps repetitive work. It can also reinforce accidental or temporary choices.
Most-used lists are shortcuts, not governance. They do not prove a block is approved. Pair them with documented preferred components where teams need consistency.
Review the list after changing roles or projects. Yesterday’s common block may become today’s clutter. Personal shortcuts should evolve with the work.
Hidden blocks still work in existing content
Block Manager visibility does not remove the block’s registered code. Existing instances should remain editable. Their frontend output remains unchanged.
This is why personal hiding is low-risk. You can simplify discovery without damaging pages. The block remains available through restored preferences later.
Test unusual paths anyway. A pattern or transform may expect direct insertion. WordPress and plugin versions can affect exact behaviour.
Hidden is different from unavailable
A hidden block remains registered but excluded from your inserter view. An unavailable block lacks registration or context permission. Recovery steps differ.
If a block appears missing, reset personal visibility first. Then check post-type rules, roles, templates, provider settings, and plugin activation.
Do not reinstall a plugin before checking preferences. Likewise, do not blame preferences when frontend output disappeared. Personal hiding cannot cause that failure.
Use Reset when the list becomes confusing
The Blocks preference panel provides a reset path. It restores hidden choices. Use it before troubleshooting deeper registration issues.
Reset can undo intentional cleanup too. Note your preferred hidden groups beforehand. Reapply them gradually after confirming the missing block returned.
A screenshot or short checklist is enough for personal setups. Teams need enforced policy elsewhere. Do not document personal toggles as universal rules.
Personal preferences may follow your account
WordPress uses its preferences data system for editor choices. Persistence depends on the configured preference layer and environment. Verify behaviour across browsers and devices.
Do not assume one browser profile owns every setting. Managed sites can customise persistence. Log into the same account elsewhere and test.
A new user should expect their own starting state. Personal preferences are not a reliable onboarding template. Use training and enforced rules for shared expectations.
The Block Manager is not an administrator policy
Another editor can show blocks you hid. They can also hide blocks you prefer. This flexibility is intentional for personal focus.
Organisation-wide policies need server-side allowed-block rules or provider configuration. Those controls can account for post type, role, and editing context.
Our block restriction guide compares enforcement methods. Use personal preferences first when no shared policy exists.
The Block Manager is not a security boundary
Hiding an inserter choice does not revoke capabilities. It does not protect private data. It does not validate content submitted through another route.
Use WordPress roles, capabilities, authentication, and server validation for security. The Block Manager reduces cognitive load. That is valuable enough.
The Block Manager does not guarantee speed gains
Hidden blocks can remain registered. Their editor code may still load. Frontend assets depend on actual blocks and provider design.
A smaller inserter can feel faster cognitively. That is not the same as lower JavaScript weight. Measure editor and frontend performance separately.
Provider module settings may reduce code more substantially. Test existing content before using them. Module disabling can be stronger than personal hiding.
Curate for accessibility too
Long, repetitive lists increase navigation work for keyboard and screen-reader users. Removing irrelevant choices can reduce that burden. Keep names and preferred alternatives predictable.
Do not hide accessible basics while leaving decorative substitutes. Test inserted output, not merely the inserter experience. Content accessibility remains the larger requirement.
Text labels in editor Preferences can also improve icon recognition. Choose interface settings supporting the individual editor. Personal accessibility needs vary.
Review new blocks after plugin updates
Plugin updates can register additional blocks. WordPress core releases can do the same. Your previously tidy inserter may grow without any preference change.
Scan unfamiliar entries before hiding them. Read descriptions and create test instances on staging. A useful replacement might have arrived.
Also check whether an update renamed existing display titles. A “new” item may be familiar code. Registered identity reveals continuity when titles change.
Preferences and categories solve different problems
Inserter categories group blocks by broad purpose. Hiding removes individual choices from your personal view. A well-categorised block can still be irrelevant.
Categories come from block registration and editor logic. Users do not normally rebuild them through Preferences. Use search when category placement feels unintuitive.
Do not hide an entire conceptual group reflexively. Keep the one or two tools serving real tasks. Remove repeated alternatives individually.
Slash commands reflect available choices
Typing a slash opens quick block insertion. Personal visibility choices can influence which blocks appear there. Test your most common slash searches after cleanup.
Search terms can include registered keywords and titles. Hiding duplicates reduces similarly named results. It also reduces accidental selection under time pressure.
A missing slash result might still exist in saved content. Reset Preferences before diagnosing registration. Then check enforced restrictions and provider state.
Patterns are not managed like individual blocks
Patterns arrange one or more blocks into reusable compositions. The Blocks preference panel manages individual inserter visibility. Pattern management uses separate interfaces.
A pattern can contain a personally hidden block. Inserting it may still introduce that structure. Test approved patterns after changing preferences.
This is not necessarily a bug. Patterns can provide controlled access to complex structures. Your organisation should decide whether that pathway is desirable.
Variations can make the list look larger
Several inserter choices can share one underlying block type. Each variation presents a different starting configuration. Query and embed experiences use this pattern often.
A displayed choice may therefore disappear differently than expected. Hiding one item does not always remove every sibling variation. Test the actual inserter results.
Do not confuse variations with block styles. Styles change appearance after insertion. Variations can change defaults, scope, or available attributes.
Create personal sets by work mode
A writer, designer, shop manager, and template editor need different frequent tools. One personal set cannot optimise every mode. Restore specialist blocks during role changes.
- Writers prioritise text, media, links, and approved calls.
- Designers keep layout, spacing, and visual components.
- Shop managers keep commerce content and product blocks.
- Template editors keep query, navigation, and theme blocks.
- Reviewers need selection and inspection more than insertion.
These are useful defaults, not restrictions. Personal curation should follow actual responsibilities. Hide nothing needed for urgent exception work.
Teach the reset path during onboarding
New editors often assume missing blocks were removed by administrators. Show Preferences and Reset during training. This prevents unnecessary support requests.
Explain the distinction between personal hiding and enforced policy. Give one example of each. Editors then know when self-service can solve the problem.
Keep training screenshots aligned with the supported WordPress version. Menu layouts evolve. Teach the concept and route, not pixel positions alone.
When hiding too much backfires
A tiny list can force editors into inferior substitutes. They may paste unsafe HTML or misuse layout blocks. Friction often moves rather than disappears.
Watch for repeated resets and support requests. Those signals reveal hidden tools with real value. Restore them and update the preferred set.
Keep occasional high-value blocks visible when discovery matters. A rarely used Table block can still prevent inaccessible pseudo-tables built with Columns.
A practical quarterly cleanup
- List the tasks you perform regularly.
- Open Preferences and select Blocks.
- Search for obvious provider duplicates.
- Keep one preferred block per repeated job.
- Hide specialised blocks unrelated to your role.
- Preserve foundational content and layout blocks.
- Test slash commands and the inserter.
- Open pages containing hidden blocks.
- Enable most-used shortcuts if helpful.
- Record any intentionally restored specialist tools.
- Repeat after major plugin changes.
The cleanup should take minutes, not hours. Stop once daily choices feel recognisable. Perfection becomes another form of clutter.
A focused starter set for writers
- Paragraph and Heading.
- List, Quote, and Pullquote where required.
- Image, Gallery, Audio, and Video as needed.
- Buttons and social links when approved.
- Group, Row, Stack, and Columns.
- Table for simple tabular data.
- Approved specialist blocks for the publication.
This is a starting point, not a universal allow list. Writers on product sites need different blocks. Editors working with templates need broader structural access.
How to troubleshoot a missing block
- Search the inserter using its current display title.
- Open Preferences and inspect Blocks.
- Reset hidden choices temporarily.
- Check the current post type and template.
- Ask whether administrators enforce restrictions.
- Confirm the provider plugin remains active.
- Check provider module settings.
- Test another administrator account.
- Inspect browser errors when registration still fails.
Work from weakest controls toward strongest controls. Personal hiding is easiest to reverse. Plugin deactivation carries the greatest content risk.
Frequently asked questions
Where is the WordPress Block Manager?
Open the editor’s Options menu, choose Preferences, and select the Blocks section.
Does hiding a block delete existing content?
No. It changes personal inserter visibility while preserving registered blocks and saved instances.
Can an administrator hide blocks for everyone here?
No. Personal preferences are not universal policy. Enforced restrictions require separate configuration.
How do I restore hidden WordPress blocks?
Recheck them inside Preferences, or use the Blocks panel’s reset option.
Does hiding blocks improve WordPress performance?
Not necessarily. It reduces visual clutter. Registration and assets may remain unchanged.
The verdict
WP Block Suite adds focused specialist blocks, not a reason to show everything. Try the free plugins and hide unused choices. Then compare the $299 lifetime suite when several Pro tools deserve permanent inserter space.
Leave a Reply