How to keep the WordPress admin menu expanded

How to keep the WordPress admin menu expanded becomes useful when you want the full wp-admin navigation to remain visible instead of collapsing into a narrow column of icons.

WordPress allows each logged-in user to collapse the administration menu using the control at the bottom of the sidebar.

In its normal expanded state, the menu looks conceptually like:

Dashboard
Posts
Media
Pages
Comments
Appearance
Plugins
Users
Tools
Settings

When collapsed, the same navigation becomes primarily icon-based:

⌂
✎
▣
▤
●
◐
◆
♟
⚒
⚙

For experienced WordPress users, the compact version can free some horizontal space.

For clients, editors, occasional administrators and users working with many plugin menus, it can instead make navigation harder because menu labels disappear and users must identify sections by icons or hover behavior.

This is closely related to the wider problem discussed in Reducing WordPress Admin Confusion for Clients: administration should make common tasks obvious rather than requiring users to memorize WordPress interface conventions.

This guide explains how WordPress stores the collapsed-menu preference, how to keep the administration menu expanded, how the mfold user setting works, why CSS-only solutions are incomplete, how to apply the behavior selectively by role, and how to combine it safely with other wp-admin customizations.

What does “collapsed WordPress admin menu” mean?

The WordPress administration area contains the main navigation along the left side of the screen.

WordPress identifies this navigation in its administration markup as the main menu.

At the bottom of the menu, desktop users normally have a control for switching between:

Expanded menu
↕
Collapsed menu

The expanded state displays:

• menu icons;
• menu labels;
• current-section information;
• submenu interactions.

The collapsed state reduces the width of the sidebar and hides the normal text labels.

The admin menu is different from the WordPress Toolbar

These two interfaces are often confused.

The admin menu is the vertical wp-admin navigation:

Dashboard
Posts
Media
Pages
Plugins
Settings

The Toolbar, often still called the admin bar, is the horizontal bar displayed across the top of WordPress.

For a detailed explanation of that separate interface, see What Is the WordPress Admin Bar, and Who Sees It?.

Keeping the admin menu expanded does not control Toolbar visibility.

Why does WordPress allow the menu to collapse?

Collapsing the sidebar gives the main administration workspace additional horizontal room.

This can be useful on screens where administrators work with:

• large tables;
• wide editors;
• plugin dashboards;
• analytics reports;
• complex settings screens.

WordPress administration list tables can become particularly wide when plugins add many custom columns. See WordPress Admin List Tables, Explained for the wider interface model.

Why keep the admin menu expanded?

The expanded menu provides one major usability advantage:

icons
+
labels

instead of:

icons only

This makes the interface easier to understand for users who do not work in WordPress every day.

Icons are not always obvious

Some WordPress icons are relatively easy to recognize.

Others become less obvious when plugins add their own menus.

A client may encounter something like:

▣
◉
◆
◫
◌
⚙

and need to remember which one represents:

Forms
SEO
Products
Backups
Security
Settings

Displaying the labels avoids that unnecessary memorization step.

Expanded navigation can help client websites

A typical client may log into WordPress only occasionally.

Their workflow might be:

Login
↓
Pages
↓
Home
↓
Edit

If the menu is collapsed, the first step becomes:

identify the Pages icon
↓
hover
↓
confirm label
↓
click

That is a small amount of friction, but repeated interface friction accumulates.

For the broader client-dashboard strategy, read Reducing WordPress Admin Confusion for Clients.

WordPress stores the menu state as a user preference

The collapsed state is not normally a global site setting.

It belongs to the individual WordPress user’s interface preferences.

WordPress provides a general system for storing interface settings through functions such as:

get_user_setting()
set_user_setting()
get_all_user_settings()

The official get_user_setting() documentation explains how WordPress retrieves one of these saved interface preferences.

The corresponding set_user_setting() function updates one.

The admin-menu setting is called mfold

WordPress uses the user-interface setting:

mfold

to represent the state of the administration menu.

The relevant values are:

o
→ open / expanded

f
→ folded / collapsed

The official set_user_setting() reference even includes a contributed example showing how the mfold preference can be forced into the folded state.

To keep the menu expanded, the opposite state is required:

mfold = o

WordPress user settings are synchronized through cookies

The interface-setting system is slightly more sophisticated than simply adding a CSS class.

WordPress maintains user-interface settings through a combination of:

• user settings;
• user options;
• browser cookies.

The official wp_user_settings() documentation explains that WordPress saves and restores interface settings using a cookie and the corresponding saved user option.

This allows a user’s preferences to be restored when appropriate.

The preference belongs to the user

Suppose a website has:

Administrator A
Administrator B
Editor C

Administrator A can normally use:

expanded menu

while Administrator B prefers:

collapsed menu

WordPress can remember those interface choices independently.

This is important if you are deciding whether to:

provide a default
or
force a state

Simply clicking “Expand menu” normally persists the preference

If only one user wants the normal expanded navigation, the simplest solution is normally to use WordPress’s built-in menu control.

At the bottom of the administration navigation, activate the control that expands the menu.

WordPress then saves the corresponding interface setting.

No custom PHP is necessary if:

the user is allowed to choose
+
WordPress successfully stores the preference

When forcing the menu open makes sense

Custom code becomes useful when the requirement is stronger:

The menu must remain expanded
for selected WordPress users.

This may be appropriate on:

• agency client sites;
• editorial installations;
• internal business systems;
• training environments;
• WordPress dashboards designed for occasional users.

Force the WordPress admin menu to remain expanded

You can check the current mfold setting and return it to the open state.

A practical implementation is:

add_action(
    'admin_init',
    function () {

        if (
            'o' !== get_user_setting(
                'mfold'
            )
        ) {
            set_user_setting(
                'mfold',
                'o'
            );
        }
    }
);

This checks the current user’s interface preference and sets:

mfold = o

when necessary.

The get_user_setting() and set_user_setting() functions are WordPress’s native interfaces for this type of user preference.

Why use admin_init?

The WordPress admin_init hook runs during administration initialization.

The official admin_init documentation explains that it fires when an administration screen or script is being initialized.

This gives the code an opportunity to update the interface setting before normal administration output is sent.

set_user_setting() must run before output begins

This requirement matters.

The official WordPress documentation states that:

set_user_setting()

needs to run before headers have already been sent because the function can update the user-settings cookie.

This is another reason to avoid attempting the change late in page rendering.

Force expansion only for selected roles

You may not want to force the expanded state for administrators who prefer compact navigation.

For example, perhaps only Editors should always receive the expanded menu.

A role-based implementation could be:

add_action(
    'admin_init',
    function () {

        $user = wp_get_current_user();

        if (
            ! in_array(
                'editor',
                (array) $user->roles,
                true
            )
        ) {
            return;
        }

        if (
            'o' !== get_user_setting(
                'mfold'
            )
        ) {
            set_user_setting(
                'mfold',
                'o'
            );
        }
    }
);

This leaves other roles unchanged.

Roles are not always the best condition

WordPress authorization is based on capabilities rather than role names alone.

For example, instead of:

if user is Editor

you may actually mean:

if user cannot manage technical site settings

In that situation, a capability check may better reflect the requirement.

For the underlying distinction, see WordPress User Roles and Capabilities, Explained.

Example using a capability condition

You could keep the menu expanded for users who do not have broad site-management access:

add_action(
    'admin_init',
    function () {

        if (
            current_user_can(
                'manage_options'
            )
        ) {
            return;
        }

        if (
            'o' !== get_user_setting(
                'mfold'
            )
        ) {
            set_user_setting(
                'mfold',
                'o'
            );
        }
    }
);

The official current_user_can() documentation explains the normal WordPress mechanism for capability checks.

This changes interface behavior, not permissions

Keeping the admin menu expanded does not grant access to additional WordPress areas.

For example:

Expanded menu
≠
Administrator access

The user still sees only the areas permitted by WordPress and installed plugins.

Likewise:

collapsed menu
≠
reduced permissions

The expanded or collapsed state is presentation.

Capabilities remain authorization.

Do not use menu expansion as a security control

This should be obvious once the distinction is understood, but admin-interface customization is frequently mistaken for access control.

Security should be enforced with:

• roles;
• capabilities;
• current_user_can();
• plugin-specific permission checks.

The broader permission model is covered in How to Audit User Roles on a WordPress Site.

Why CSS-only solutions are incomplete

You may find snippets that attempt to force the menu open by changing CSS.

For example, a stylesheet might attempt to override rules related to:

folded
menu-folded
#adminmenu
#adminmenuwrap

This can visually widen the sidebar.

But CSS alone does not necessarily update WordPress’s saved menu preference.

The application can therefore end up in an inconsistent state:

WordPress setting:
collapsed

CSS:
looks expanded

Visual state and saved state should agree

A better implementation is:

WordPress user setting
→ expanded

WordPress body state
→ expanded

CSS
→ normal expanded styles

rather than fighting WordPress’s interface state from a stylesheet.

The collapsed state affects body classes

WordPress administration uses state-related classes to style the narrow menu.

The DOM can contain classes associated with the folded administration state, while the menu markup itself includes the collapse control.

Those classes are part of WordPress’s own administration UI behavior.

A custom solution should work with that state rather than relying on brittle assumptions about menu widths.

Do not hardcode the sidebar width unless necessary

A fragile solution might contain:

#adminmenuwrap {
    width: 160px !important;
}

#adminmenu {
    width: 160px !important;
}

This does not actually restore WordPress’s menu state.

It only changes dimensions.

It can also interfere with:

• responsive administration;
• future WordPress changes;
• RTL layouts;
• custom admin themes;
• plugin interfaces.

Do not remove responsive WordPress behavior

Keeping the desktop administration menu expanded does not mean the menu should remain permanently visible at every screen width.

WordPress changes its administration navigation behavior on narrower displays.

That is necessary because a full desktop sidebar consumes too much horizontal space on phones and small tablets.

The intended rule is:

desktop
→ prefer expanded menu

small screen
→ allow WordPress responsive behavior

not:

all screens
→ force 160px sidebar forever

Mobile wp-admin is a separate usability problem

On a desktop monitor:

expanded menu
+
wide workspace

can coexist comfortably.

On a phone:

expanded permanent sidebar
+
narrow viewport

would leave little space for the actual administration screen.

Any custom admin behavior should therefore be tested responsively.

Test the Block Editor too

The WordPress Block Editor uses substantial horizontal workspace.

If you force the administration navigation into a particular layout, verify:

• post editing;
• page editing;
• sidebar settings;
• fullscreen mode;
• plugin editor panels.

A global administration customization should not make content editing harder.

Fullscreen editor behavior can make the admin menu disappear

Do not confuse the collapsed admin menu with editor fullscreen modes.

Some WordPress editing experiences intentionally reduce surrounding administration chrome to create more editing space.

That is a different behavior from:

mfold = f

which represents the normal administration menu’s folded state.

Collapsed menu and hidden menu are different

There are three separate concepts:

EXPANDED

Dashboard
Posts
Media
Pages


COLLAPSED

icons only


HIDDEN

menu item not displayed

Keeping the admin menu expanded controls only the first two states.

It does not decide which menu entries exist.

Reorganizing the WordPress menu is a separate task

If the problem is:

the sidebar contains too many items

keeping it expanded may actually make the clutter more obvious.

In that case, the correct solution may also involve reorganizing the menu.

See How to Reorganize the WordPress Admin Menu for that separate workflow.

Expanded does not automatically mean understandable

Consider:

Dashboard
Posts
Media
Pages
Comments
Portfolio
Testimonials
Products
WooCommerce
Forms
Analytics
SEO
Security
Backups
Cache
SMTP
Snippets
Appearance
Plugins
Users
Tools
Settings

Displaying all those labels is easier than icons alone.

But it is still a crowded administration environment.

This is why keeping the menu expanded often works best together with role-aware navigation cleanup.

TheOneWP Admin Menu Organizer can simplify the navigation itself

TheOneWP Admin Menu Organizer can reorganize the WordPress administration navigation and apply role-aware rules.

This solves a different but related problem.

Keeping the menu expanded answers:

Should labels remain visible?

Admin Menu Organizer answers:

Which menu items should appear,
and in what order?

A useful client configuration combines both ideas

For example:

Client Editor

Menu state:
expanded

Visible navigation:
Dashboard
Pages
Posts
Media
Forms

rather than:

Client Editor

Menu state:
collapsed

Visible navigation:
22 icons

The first interface provides considerably more context with less interpretation.

Role-aware menu organization is often better than one universal menu

An Administrator may need:

• Plugins;
• Settings;
• Security;
• Backups;
• technical tools.

An Editor may need:

• Posts;
• Pages;
• Media;
• Comments.

A WooCommerce manager may need:

• Orders;
• Products;
• Customers;
• reports.

For the underlying permission architecture, see Custom WordPress Roles vs. Combining Existing Ones.

Keeping the menu expanded can reduce training requirements

Imagine training a client with:

Click Pages
then select Home.

With the expanded menu, those instructions match the screen directly.

With a collapsed menu, the client first has to identify the correct icon.

This becomes especially useful when training documentation contains screenshots of the administration interface.

Consistent administration state helps support too

Suppose an agency tells a client:

Open Tools
→ Site Health

If the client’s menu is folded, their screen may not visually match the documentation.

Standardizing interface state can make:

• support instructions;
• screenshots;
• training videos;
• internal documentation;
• client onboarding;

more predictable.

Standardize carefully across client sites

If you manage many WordPress installations, interface consistency can reduce support overhead.

A useful agency baseline could define:

Admin menu
→ expanded for client editors

Technical menus
→ Administrator only

Toolbar
→ retained for editors

Dashboard
→ simplified

Notices
→ role-aware

For the broader agency approach, see Standardizing WordPress Configuration Across Client Sites.

Do not override user preference without a reason

There is an important UX distinction between:

default expanded

and:

forced expanded

If an experienced Administrator intentionally collapses the menu because they prefer the additional workspace, forcing it open again on every page can be frustrating.

Use a permanent override only when there is a clear administration policy behind it.

Consider role-based enforcement instead

A balanced configuration might be:

Administrator
→ user chooses

Editor
→ always expanded

Author
→ always expanded

Client Manager
→ always expanded

This preserves flexibility for technical users while keeping the interface predictable for less frequent users.

Do not update every user’s database records manually

You may encounter suggestions to edit values directly inside:

wp_usermeta

or manipulate serialized user-interface settings manually.

That is unnecessary for normal WordPress development.

WordPress already exposes:

get_user_setting()
set_user_setting()
get_all_user_settings()

Use the application API instead of coupling custom code directly to storage details.

The saved user settings contain more than mfold

The WordPress user-settings mechanism is used for several interface preferences.

Core functions such as get_user_setting() can therefore retrieve settings unrelated to the admin menu as well.

The official get_all_user_settings() documentation explains how the complete collection is retrieved.

Do not overwrite the entire collection just to change one preference.

Use set_user_setting() instead of replacing all settings

The correct pattern is:

set_user_setting(
    'mfold',
    'o'
);

rather than constructing an entirely new set of user-interface values.

set_user_setting() retrieves the existing settings, updates the requested key and preserves the rest.

What if the menu keeps collapsing unexpectedly?

If WordPress does not remember the expanded state, investigate the user-settings system before adding increasingly aggressive CSS.

Potential areas to check include:

• browser cookies;
• cookie-blocking extensions;
• custom admin JavaScript;
• admin-interface plugins;
• user-settings modifications;
• caching or proxy behavior affecting administration;
• custom code manipulating mfold.

Check the browser cookie

WordPress stores user-interface state in a cookie whose name includes the current user ID.

The official wp_user_settings() source shows cookies such as:

wp-settings-{USER_ID}
wp-settings-time-{USER_ID}

If those cookies cannot be created or retained, user-interface preferences may behave unexpectedly.

Check whether another plugin is forcing the collapsed state

Another plugin or custom snippet may already contain logic similar to:

set_user_setting(
    'mfold',
    'f'
);

If so, your code and that code may continually compete over the same setting.

Search:

• custom plugins;
• mu-plugins;
• theme functions;
• snippet managers;
• admin-customization plugins.

Check mu-plugins too

Must-use plugins are particularly easy to overlook because they do not behave exactly like ordinary plugins in the Plugins screen.

An agency or hosting environment may place administration customizations there.

When debugging unexpected wp-admin behavior, include:

/wp-content/mu-plugins/

in the investigation.

Do not assume the active theme is responsible

Administration behavior can come from many places:

WordPress Core
plugin
mu-plugin
theme
custom snippet
hosting integration
browser extension

Identify the source before replacing core behavior with stronger overrides.

Test with a clean browser session

Because WordPress administration preferences use cookies, browser state matters.

When troubleshooting, test with:

• a clean browser profile;
• a private window where appropriate;
• another browser;
• extensions disabled if necessary.

This helps determine whether the problem belongs to WordPress or to the current browser environment.

Test multiple WordPress roles

Do not verify the customization only as Administrator.

Test representative accounts such as:

Administrator
Editor
Author
Client Manager
WooCommerce role
custom role

Different roles can receive different menu items and administration experiences.

Admin-menu expansion and login redirects can work together

If an Editor always works with content, an optimized workflow might be:

Login
↓
redirect directly to Posts
↓
expanded administration navigation
↓
clear access to Posts, Pages and Media

See Redirecting Users by Role in WordPress for the redirect layer.

TheOneWP Redirect After Login can provide configurable destinations by role.

The Toolbar and admin menu can also be configured independently

For an Editor, you might want:

Admin menu
→ expanded

Frontend Toolbar
→ visible

because the Toolbar provides useful shortcuts such as Edit Page.

For a frontend customer, you may instead want:

wp-admin
→ generally not part of workflow

Frontend Toolbar
→ hidden

TheOneWP Hide Admin Bar addresses that separate Toolbar behavior.

Expanded menus can improve accessibility for some users

Text labels provide more explicit information than icons alone.

An icon-only interface assumes that the meaning of each symbol is already understood or can be discovered through interaction.

Keeping labels visible can therefore improve clarity for:

• new WordPress users;
• occasional administrators;
• clients;
• users working with unfamiliar plugins.

This does not mean every user requires the expanded state, but it is a legitimate accessibility and usability consideration.

Do not remove the collapse button just because you set the default

If your goal is only:

start expanded

there is little reason to remove the user’s ability to collapse the menu later.

A default and an enforced policy are different.

If the state genuinely needs to remain fixed, then an override is appropriate.

If not, preserve user choice.

Default expanded vs. forced expanded

Approach	Behavior
User preference	User can expand or collapse and WordPress remembers the choice
Default expanded	User starts expanded but can later choose another state
Forced expanded	Custom code restores expanded state repeatedly

Choose the least restrictive option that meets the actual requirement.

Keep customization outside the theme when possible

Administration behavior normally represents application configuration rather than frontend presentation.

If the rule is:

Client editors should always use
expanded wp-admin navigation

that rule should not disappear simply because the public theme changes.

A small custom plugin or dedicated administration toolkit is usually a more appropriate location than the theme’s functions.php.

Example: small plugin that keeps the menu expanded

A minimal plugin implementation could be:

<?php
/**
 * Plugin Name: Expanded Admin Menu
 * Description: Keeps the WordPress admin menu expanded.
 */

defined(
    'ABSPATH'
) || exit;

add_action(
    'admin_init',
    function () {

        if (
            'o' !== get_user_setting(
                'mfold'
            )
        ) {
            set_user_setting(
                'mfold',
                'o'
            );
        }
    }
);

This keeps the implementation independent of the active theme.

Example: keep it expanded only for non-administrators

A client-oriented variation could be:

<?php
/**
 * Plugin Name: Client Expanded Admin Menu
 */

defined(
    'ABSPATH'
) || exit;

add_action(
    'admin_init',
    function () {

        if (
            current_user_can(
                'manage_options'
            )
        ) {
            return;
        }

        if (
            'o' !== get_user_setting(
                'mfold'
            )
        ) {
            set_user_setting(
                'mfold',
                'o'
            );
        }
    }
);

Technical administrators remain free to choose their preferred layout, while lower-privilege administrative users receive the predictable expanded navigation.

Do not interpret manage_options as “Administrator role”

The capability:

manage_options

is not the same thing as checking:

role === administrator

A custom role may theoretically receive that capability.

Likewise, roles can be customized.

When exact role behavior matters, review the site’s capability architecture instead of assuming defaults.

See How to Audit User Roles on a WordPress Site.

Combine expanded navigation with sensible menu organization

An optimized administration experience might look like:

Dashboard

CONTENT
Posts
Pages
Media

BUSINESS
Forms
Products
Orders

ACCOUNT
Profile

with the text labels permanently visible for client roles.

That is substantially easier to navigate than an uncontrolled list of plugin menus displayed only as icons.

For the organizational layer, see How to Reorganize the WordPress Admin Menu.

Do not confuse simplification with removing functionality

A better administration interface does not necessarily contain fewer features.

It contains less unnecessary complexity.

A client may still have access to:

• Pages;
• Posts;
• Media;
• Forms;
• Products;
• Orders.

The improvement is that those tools are easy to identify and reach.

A practical testing workflow

1. Confirm the target user currently sees the standard WordPress admin menu.
2. Expand the menu manually.
3. Navigate to another administration screen.
4. Confirm WordPress retains the preference.
5. Log out and back in.
6. Confirm the preference still behaves correctly.
7. Inspect the current mfold user setting if debugging.
8. Add custom enforcement only when necessary.
9. Test an Administrator account.
10. Test an Editor or client account.
11. Test custom roles.
12. Open Posts and Pages screens.
13. Open the Block Editor.
14. Open plugin settings screens.
15. Test narrower administration widths.
16. Test a tablet viewport.
17. Test mobile administration.
18. Verify WordPress responsive navigation remains usable.

WordPress expanded admin menu checklist

• Decide whether the menu should be expanded by default or permanently forced open.
• Use WordPress’s built-in expand/collapse control when user choice is sufficient.
• Remember that the preference belongs to the individual user.
• Understand that WordPress uses the mfold user setting.
• Use get_user_setting() to inspect the current state.
• Use set_user_setting() to update the state.
• Use o for the open state.
• Use f for the folded state.
• Run set_user_setting() before output begins.
• Prefer a normal administration initialization hook.
• Do not manually rewrite serialized user settings.
• Do not modify wp_usermeta directly for this preference.
• Do not rely entirely on CSS to fake an expanded state.
• Do not hardcode sidebar widths unnecessarily.
• Preserve WordPress responsive behavior.
• Do not force the desktop sidebar open on small screens with CSS.
• Test the Block Editor.
• Test classic administration screens.
• Test plugin screens.
• Test multiple roles.
• Test using a real client account.
• Remember that menu state does not change capabilities.
• Do not use interface state as access control.
• Use current_user_can() for permission decisions.
• Consider enforcing expansion only for selected roles or capabilities.
• Allow technical administrators to retain personal preference where appropriate.
• Check cookies when the preference is not being remembered.
• Check custom code for conflicting mfold changes.
• Inspect normal plugins.
• Inspect mu-plugins.
• Inspect snippet managers.
• Test in another browser when debugging persistence.
• Combine expansion with admin-menu cleanup when navigation is cluttered.
• Keep the implementation independent of the active theme where practical.
• Document the customization on agency-managed sites.

Related guides

• How to Reorganize the WordPress Admin Menu
• Reducing WordPress Admin Confusion for Clients
• WordPress User Roles and Capabilities, Explained
• How to Audit User Roles on a WordPress Site
• What Is the WordPress Admin Bar, and Who Sees It?
• WordPress Admin List Tables, Explained

Final recommendation

If WordPress’s normal persistence works correctly and the user simply prefers the expanded administration menu, use the built-in menu control and allow WordPress to remember the preference.

Custom code is appropriate when you have an explicit requirement such as:

Client editors must always receive
the expanded wp-admin navigation.

In that case, work with WordPress’s own user-interface setting:

mfold = o

rather than attempting to imitate the expanded state with CSS.

The clean implementation model is:

admin request
↓
identify current user
↓
decide whether expanded navigation
should be enforced
↓
read mfold
↓
set mfold to o when necessary
↓
allow WordPress to render
its normal expanded administration menu

For client environments, expanded navigation often works best as part of a larger administration strategy:

appropriate capabilities
+
expanded text labels
+
organized menu items
+
reduced technical clutter
+
useful login destination
+
consistent documentation

TheOneWP Admin Menu Organizer can handle the organization and role-aware visibility of the menu itself, while the expanded-state preference determines whether the remaining navigation is displayed with its labels visible.

The important distinction is that these are separate layers.

Expanded menu
→ navigation presentation

Admin Menu Organizer
→ navigation structure

Roles and capabilities
→ actual authorization

Keeping those responsibilities separate produces a WordPress administration environment that is easier to understand without weakening the permission model underneath it.