Skip to content

Administration: Remove admin menu auto-fold and use the responsive menu below 961px - #14219

Draft
abhishekfdd wants to merge 1 commit into
WordPress:trunkfrom
abhishekfdd:66018-remove-admin-menu-auto-fold
Draft

abhishekfdd wants to merge 1 commit into
WordPress:trunkfrom
abhishekfdd:66018-remove-admin-menu-auto-fold

Conversation

@abhishekfdd

Copy link
Copy Markdown

Removes the automatic icon-only fold of the admin menu between 783px and 960px. At 960px and below, the admin menu now uses the existing responsive (toggle) menu. Folding remains available as a user choice above 960px via the collapse button and the mfold user setting.

Scope: only the admin menu breakpoint moves to 960px. Toolbar height, content padding and metabox sortables keep the 782px breakpoint (option 1 from comment:3, see comment:9).

Changes

  • admin-menu.css: merges the 960px auto-fold block and the 782px responsive block into one 960px responsive menu block, keeping rule order so ≤782px output is unchanged. Removes rules made dead by the merge. Shows the toolbar menu toggle at ≤960px at regular toolbar size; the large touch sizing stays at ≤782px. Hides #collapse-menu at ≤960px.
  • common.js: responsive trigger and setMenuState() use 960px, so wp-menu-state-set reports responsive at ≤960px and never an automatic folded. The collapse button only toggles folded / mfold; unfold is no longer read or written. wpResponsive.activate() calls maybeDisableSortables() so metabox drag and drop stays enabled between 783px and 960px.
  • admin-header.php: always adds auto-fold to the body, since the responsive menu styles are scoped to it and plugins and Gutenberg's editor-left() mixin target it.

Testing

Compared against unpatched trunk at 700, 850, 960, 961 and 1100px in Chromium:

  • 783 to 960px: menu hidden, toggle in the 32px toolbar, content starts at the edge. Toggle opens the menu, moves focus to the first item and sets aria-expanded="true"; Escape closes it. Metabox sortables stay enabled. No flash of the full menu on first paint.
  • ≤782px, ≥961px, and user-folded menu at 700px and 1100px: pixel-identical to trunk.
  • RTL (he_IL): correctly mirrored at 850px; pixel-identical to trunk at 700px and 1100px.
  • Block editor (non-fullscreen): pixel-identical at 700px and 1100px. At 850px there is a 36px empty strip from Gutenberg's editor-left() mixin; details on the ticket.
  • No JS errors on the dashboard or block editor, LTR or RTL.

Trac ticket: https://core.trac.wordpress.org/ticket/66018

Use of AI Tools

AI assistance: Yes
Tool(s): Claude (Anthropic)
Model(s): Claude Opus 5.5
Used for: Investigating the auto-fold and breakpoint code paths, drafting the implementation. I reviewed the changes, verified the behavior locally, and take responsibility for the code.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

…ve menu below 961px.

The admin menu no longer collapses automatically to the icon-only state between 783px and 960px. Instead, the responsive admin menu, opened from the toolbar menu toggle, is now used at 960px and below. Folding the menu remains available as a user choice through the collapse button and the `mfold` user setting.

The `auto-fold` body class is kept and is now always added, as it scopes the responsive admin menu styles and is used by plugins and the block editor. The `unfold` user setting is no longer read or written.

Only the admin menu breakpoint moves. The toolbar height, content padding and metabox sortables keep their existing 782px breakpoint.

See #66018.
@github-actions

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant