Stop showing staff's black bar to every customer
Hide Admin Bar hides the WordPress admin bar for whichever roles you choose, on the front end, in wp-admin, or both — so a shop's own customers stop seeing a toolbar that was never meant for them.
- Frontend and backend controlled completely separately, per role.
- Works with any registered role, not just WordPress's built-in five.
- A CSS fallback backs up the backend hide for a real timing quirk.
- No effect on any role or context left unselected.
Frontend
Backend
What does Hide Admin Bar do?
When the hide_admin_bar module is active, TOWP_Hide_Admin_Bar filters WordPress's own show_admin_bar hook to return false for any role selected in either the Frontend or Backend group, checking each context separately depending on whether the current request is inside wp-admin or on the public site. Because show_admin_bar alone isn't always enough inside wp-admin due to a timing issue at priority 0 on init, the module also injects a small inline stylesheet that hides the bar with CSS specifically for backend-hidden roles, as a fallback that catches cases the filter alone might miss.
The admin bar was built for staff, not for everyone logged in
Since WordPress shows the bar to any logged-in visitor by default, a shop's own customers end up seeing a toolbar meant for the people running the site.
Every logged-in visitor gets the same black bar
WordPress shows the admin bar to anyone logged in by default, whether that's an editor working on the site or a customer who just created an account to check an order.
It shifts the layout and offers links nobody there can use
The bar pushes the page down, looks like part of somebody else's software, and links to dashboard screens a shop customer or forum member has no reason, or ability, to visit.
Frontend and backend, controlled completely separately
The module hides the bar exactly where and for whom it should disappear, without touching it anywhere else.
Hide it from customers, keep it for staff
Select which roles lose the bar on the front end, independently of what happens for the same roles inside wp-admin.
Two contexts, two separate settings
A role can be hidden from the bar in one context and left untouched in the other, since Frontend and Backend get configured entirely apart.
A backup for a real WordPress timing quirk
An extra CSS fallback catches the backend cases where the native filter alone doesn't fully take effect in time.
Native filter, backed by a real fallback
Every capability below is present in the supplied PHP class and its settings registration.
Any registered role, in either context
Every role actually registered on the site gets its own Frontend toggle and its own Backend toggle, independent of each other.
Built on show_admin_bar
The module hooks WordPress's own native filter for controlling the admin bar's visibility, the same mechanism WordPress core uses internally.
A documented timing issue, handled
Since the native filter can arrive too late for wp-admin in some cases, an inline stylesheet specifically hides the bar and removes its layout padding as a backup.
An untouched context stays untouched
With no role checked in a given context, the module changes nothing there at all, for any role.
Checks every role a user actually has
Role matching runs through the same towp_user_roles filter a Multi Role module can extend, so a user with more than one role gets evaluated against all of them.
The current user is fetched only once
The current user gets loaded and cached internally the first time it's needed, rather than being fetched again for each check.
Where hiding the bar helps most
The module supports any site where logged-in visitors shouldn't see a toolbar meant for staff.
Membership sites and online shops
Hide the bar from customers and members entirely, leaving it visible only for the staff who actually manage the site.
Community and forum sites
Remove the bar for regular members while keeping it for moderators and administrators who need quick access to it.
Sites where only a few roles ever touch wp-admin
Hide the backend bar for roles that never actually work inside the admin area, even if they occasionally need frontend access.
Precise where it counts, invisible where it doesn't
The module combines a genuinely cleaner visitor experience with a fallback that closes a real gap.
One check, nothing when unused
The verified implementation stays lightweight in every configuration.
One filter check per admin-bar decision
The show_admin_bar filter runs once per request, and the role comparison inside it is a lightweight in-memory check.
Nothing added when no roles are selected
With both Frontend and Backend left empty, the check exits immediately and no visible change occurs.
A tiny inline stylesheet, only when needed
The CSS fallback only gets added for users whose role is actually in the Backend hidden list, not for every wp-admin visitor.
Visibility, not access control
The code changes what a role sees, never what it's actually capable of doing.
A visibility setting, not an access-control mechanism
Hiding the admin bar changes what a role sees, not what that role is capable of doing if it reaches a URL directly.
Configuration requires the same access as any other setting
Choosing which roles lose the bar happens through the standard TheOneWP settings screen, available only to an administrator.
No role is automatically exempt
Any role, including Administrator, can be selected in either context if that's genuinely the desired configuration.
Respects roles exactly as WordPress defines them
The module reads roles directly from wp_roles(), never redefining or overriding what a role actually is.
Built directly around WordPress's own admin bar system
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
show_admin_bar
The exact WordPress core filter used to decide whether the admin bar renders at all, for the current request.
wp_add_inline_style()
The core function used to attach the fallback CSS directly to the existing wp-admin stylesheet, rather than loading a separate file.
towp_user_roles filter respected
Role checks run through the same filter a Multi Role module can extend, so multi-role users get evaluated correctly.
TheOneWP versus common alternatives
Compare the verified Hide Admin Bar implementation with a typical single-toggle solution.
| Capability | TheOneWP Hide Admin Bar | Other common solutions |
|---|---|---|
| Frontend and backend control | Configured completely separately, per role | Often a single site-wide toggle covering both contexts |
| Backend reliability | A CSS fallback covers a documented timing gap | A filter-only approach can occasionally fail to take effect |
| Role coverage | Any registered role, including custom ones | Frequently limited to a fixed set of roles |
| Performance when unused | No change at all with nothing selected | Some approaches always run extra checks regardless of configuration |
| Administration | One settings screen, checkboxes per role and context | Requires a code snippet or a dedicated plugin |
Hide the bar in four steps
Test both contexts separately before considering the change final.
Enable Hide Admin Bar
Activate the module from the TheOneWP Backend settings tab.
Select frontend roles to hide the bar from
Check the roles, like customers or members, that shouldn't see the bar on the public site.
Select backend roles separately, if needed
Check any roles that should also lose the bar while inside wp-admin.
Confirm from an affected role's own login
Log in as, or switch to, a selected role to confirm the bar no longer appears in the intended context.
Match the selection to how each role is actually used
The right configuration depends on what each role genuinely needs from the bar.
Leave staff roles untouched in the context they need the bar
Keep the bar visible for whichever roles actually use its quick links to navigate the site.
Match the selection to how each role actually uses the site
A role that only ever visits the front end doesn't need its backend setting touched at all.
Test both contexts separately after configuring
Since Frontend and Backend are independent, confirm each one behaves as expected rather than assuming one implies the other.
Revisit the selection after adding a new role
A newly created role won't be selected automatically in either context, so decide deliberately whether it should see the bar.
Avoid assuming one setting covers both contexts
A couple of details are easy to overlook when configuring this for the first time.
Assuming one toggle hides the bar everywhere
Frontend and Backend are independent settings; hiding the bar in one context has no effect on the other.
Forgetting a custom role needs its own selection
A custom role doesn't inherit the setting from a similar built-in role; it needs to be checked separately in each context.
Treating a hidden bar as a security boundary
Hiding the admin bar changes visibility, not capability; a role that can't act on a link still can't act on it whether the bar is visible or not.
Hide Admin Bar FAQ
These answers come directly from the verified class and its settings registration.
What does Hide Admin Bar do?
It hides the WordPress admin bar for whichever roles get selected, with frontend and backend visibility controlled completely separately.
Can I hide the bar on the front end but keep it in wp-admin?
Yes. Frontend and Backend are two independent settings for the same role.
Does this work with custom roles, not just WordPress's default ones?
Yes. The role list comes from every role actually registered on the site, including custom ones.
Why does the module use CSS in addition to the native filter?
The native show_admin_bar filter can arrive too late inside wp-admin in some cases, so an inline stylesheet backs it up specifically for backend-hidden roles.
Can I hide the bar for Administrator?
Yes. Any role, Administrator included, can be selected in either context.
Does hiding the bar affect what a role can actually do?
No. It only changes visibility; a role's actual capabilities stay exactly the same.
Will a role I don't select notice any change at all?
No. Behavior continues exactly as before for any role left unselected in both contexts.
Does this affect performance on a site that leaves everything unselected?
No. With no roles selected in either context, the check exits immediately and nothing changes.
Will this work correctly for a user with more than one role?
Yes. Role matching checks every role a user has, so the bar gets hidden if any of their roles is selected for that context.
Who can configure which roles lose the admin bar?
Only an administrator with access to the TheOneWP settings screen.
Stop showing staff's toolbar to every logged-in visitor.Hide it exactly where it doesn't belong.
Use Hide Admin Bar to remove the bar for chosen roles on the front end, in wp-admin, or both, with a reliable fallback backing up the backend hide.