Dashboard and Admin Screens

Every admin screen and every menu entry is guarded by a capability. Core registers the menu in wp-admin/menu.php as an array of entries, each with the capability it needs, and skips the entries the current user lacks. A Contributor therefore sees Dashboard, Posts, Comments, Profile and Tools; an Editor also sees Media, Pages and the full Comments moderation; only an Administrator sees Appearance, Plugins, Users, Settings and the Site Health parts of Tools. Hiding a menu entry is not access control: the screens check the capability again when they load, and a plugin that only removes a menu item (remove_menu_page()) leaves the screen reachable by URL. Roles and capabilities are covered in Users, Roles and Profiles and Roles and Capabilities API.

The function is_admin() only says that the request is for an admin screen; it says nothing about the user being an administrator. Code that must restrict something to administrators checks current_user_can( 'manage_options' ) or a more specific capability.

Every classic admin screen has the same four parts:

The block editor, the Site Editor, the Font Library and other React-based screens replace the classic work area with their own full-height application, but keep the toolbar (see The toolbar in every editor (7.1)).

Dashboard > Home (wp-admin/index.php) is the first screen after login. It is a grid of boxes, called dashboard widgets, that are technically meta boxes on the screen with the ID dashboard. The grid has one to four columns depending on the window width.

Screen Options is a per-screen panel. On list tables it offers the visible columns, the number of items per page and the view mode (compact or extended); on the classic editor and the Dashboard it lists the boxes that can be hidden. The number of items per page is stored as user meta named after the screen: edit_post_per_page for posts, edit_page_per_page for pages, edit_lp_book_per_page for the Lumen books list, edit_comments_per_page, users_per_page and so on. Values above 999 are rejected. Plugin screens add options with add_screen_option( 'per_page', ... ) and must allow saving them through the set-screen-option filter (or the screen-specific set_screen_option_{$option} filter).

Help opens contextual documentation for the current screen: tabs on the left, a sidebar with "For more information" links on the right. Core screens ship their own; plugins add tabs with WP_Screen::add_help_tab() once the screen is known (the current_screen action or the load-{page} hook). Neither tab exists on the block-based editors, which have their own Keyboard shortcuts and Welcome guide instead.

The colour scheme styles the main navigation, the toolbar, buttons, links and notification bubbles. Each user picks one in Users > Profile > Administration Color Scheme; the choice is the admin_color user meta and applies only to that user, on every site of a network.

WordPress 7.0 refreshed the admin design and made a new scheme the default. Internally its key is modern; in the profile it is labelled Default. The scheme that was the default from 3.8 to 6.9 (key fresh) was relabelled Fresh. The 7.0 database upgrade (upgrade_700() in wp-admin/includes/upgrade.php) changed every user whose admin_color was fresh to modern, because WordPress cannot tell a user who picked the old default on purpose from one who never opened the profile; a user who wants the previous look selects Fresh again. A request to undo the migration in 7.0.1 was declined. The other schemes did not change:

The picker lists Default, Fresh and Light first and then every other scheme, core or plugin, alphabetically by key. If a user’s stored value names a scheme that is no longer registered (a plugin was removed), the admin falls back to modern when rendering; the stale meta value stays in the database until the user saves the profile.

Plugins register extra schemes with wp_admin_css_color( $key, $name, $url, $colors, $icons ) on admin_init: $url is the stylesheet loaded instead of the default one, $colors are the swatches shown in the picker, and $icons the colours applied to the SVG menu icons. Core builds its own schemes from Sass partials shipped in wp-admin/css/colors/ (_admin.scss, _variables.scss, _mixins.scss, _tokens.scss), and a plugin can compile its scheme against the same partials, as the Lumen example below does, so that it covers every element the core schemes cover.

7.1 added design tokens and a ThemeProvider React component for plugin screens built with @wordpress/components, so React-based admin pages follow the user’s colours; see Components, DataViews and Admin Screens.

The Command Palette is a search box that runs commands: go to a screen, open a post by title, add a new page, toggle an editor preference. It opens with Ctrl+K (Windows, Linux) or Cmd+K (macOS).

Plugins register further commands in JavaScript with the @wordpress/commands package (useCommand(), useCommandLoader(), or wp.data.dispatch( 'core/commands' ).registerCommand()); see Data Layer and Editor Extensibility. Some browser extensions and password managers also claim Ctrl/Cmd+K; if the palette does not open, the toolbar button still works.

Since 7.0, moving between classic admin screens animates: the page cross-fades and the admin menu items keep their place instead of flashing, using the browser’s cross-document View Transitions API. Core does this with an inline stylesheet (wp-view-transitions-admin) containing @view-transition { navigation: auto; } and a transition name per top-level menu item. Two consequences:

A plugin screen that misbehaves during the transition (for example, a full-screen app that measures the viewport on load) can dequeue the style on its own screen with wp_dequeue_style( 'wp-view-transitions-admin' ) in an admin_enqueue_scripts callback with a priority above 10 (core enqueues the style at the default priority).

Before 7.1 the post editor hid the toolbar in its default fullscreen mode, and the Site Editor never showed it; the "W" logo in the editor’s corner doubled as a back button. Since 7.1 the toolbar stays visible in the post editor and the Site Editor, as everywhere else in the admin, except in Distraction Free mode. In the editors, a chevron back button replaces the "W" logo as the way back to the previous screen; the logo always opens the About menu, and the site icon (when set) always opens the site menu. The post editor is also always iframed since 7.1, so admin CSS no longer leaks into the editing canvas.

For plugin authors this means toolbar nodes added through the admin_bar_menu action now appear in the Site Editor too. Nodes that make no sense there are skipped by checking get_current_screen(): its id is site-editor in the Site Editor, and $screen->is_block_editor() is true in any block editor. The Lumen plugin below does this.

The Show Toolbar when viewing site profile option only concerns the front end. Inside the admin the toolbar is always shown.

Users > Profile (profile.php, or user-edit.php?user_id=N for someone else) starts with personal options that only affect the current user. Each is a user meta row:

The rest of the profile (name, nickname, display name, contact info, biographical info, profile picture from Gravatar, new password, Application Passwords, and Log Out Everywhere Else) is covered in Users, Roles and Profiles.

The Media Library opt-out has a history worth knowing: infinite scrolling was the grid’s behaviour until 5.8, which replaced it with a "Load more" button for accessibility; 7.1 made infinite scrolling the default again and added the per-user opt-out. The media_library_infinite_scrolling filter still overrides both.

Lumen Press wants three things in its admin: a Dashboard widget showing the state of the book catalogue, an admin colour scheme in the publisher’s ink-and-amber colours, and a toolbar shortcut to the books list that stays out of the Site Editor. Editors should not see the WordPress Events and News widget.

These are site-specific choices rather than features, so they live in a must-use plugin: a PHP file in wp-content/mu-plugins/ that WordPress always loads, that cannot be deactivated from the Plugins screen and that loads before normal plugins. Files in subdirectories of mu-plugins are not loaded automatically, so the PHP file sits at the top level and its stylesheet in a folder next to it:

Source: Advanced Administration Handbook: Must Use Plugins

Admin preferences are user meta, so wp user meta reads and writes them for any user without logging in as that user. Listing a user’s preferences:

Source: WP-CLI Commands: wp user meta list

Source: WordPress.org Documentation: Users Your Profile screen

These are the values of a freshly installed 7.1 site: every new user gets the modern scheme.

Setting the Lumen scheme for one user, then for every Editor, returning one user to the default by deleting the meta row, and setting a scheme through wp user update, which goes through wp_update_user() and strips characters that are not allowed in a scheme key:

Source: WP-CLI Commands: wp user meta update

The registered schemes exist only during an admin request (they are registered on admin_init), so a wp user meta update with a misspelled key succeeds and the user silently gets the default scheme.

Presetting the Dashboard and list screens for a user (hide two widgets, hide the Welcome panel, show 50 books per page, hide the toolbar on the front end):

Source: WP-CLI Commands: wp user meta

--format=json makes WP-CLI store a PHP array (serialised), which is what core expects for metaboxhidden_dashboard; without it the value would be stored as a plain string, which core does not read as a list of widget IDs. After these commands the Dashboard renders the two widgets with the hide-if-js class and their Screen Options boxes unticked, and the Screen Options of Books > Books shows 50 items per page.

The older books on WordPress describe the admin of 6.2 to 6.6. The structure (toolbar, navigation, work area, Screen Options, Help) is still valid; these details are not:

The full list of corrections is in Where Older Books and Tutorials Are Outdated. The settings screens under Settings are described one by one in Settings Screens, and adding menu pages and settings from a plugin in Administration Menus and Settings API.