A customised WordPress dashboard may need a styling check before its next major upgrade. The 5 November WordPress 7.2 developer note explains the move from font glyphs to inline SVG icons in the admin bar and menu. Most plugins and themes need no change, but code that targets the old icon markup deserves attention.
The note concerns WordPress 7.2 during its beta period. Treat it as preparation for a compatibility trial, rather than evidence that your production site has already changed.
Identify who owns the dashboard styling
Start with the customisations your agency maintains: an admin colour scheme, a branded toolbar or a plugin that replaces a core menu icon. Ask the developer to locate the CSS and PHP responsible. A screenshot can show the symptom, but the owner needs the rule or function behind it.
Record the current appearance before testing. Include the user role and viewport size, since a dashboard used by an editor may differ from an administrator’s view. Use a disposable copy with representative menu items.
Inspect rules aimed at pseudo-elements
The developer note calls out CSS that colours or hides icons through pseudo-elements such as ::before. The replacement SVG is a real element, so those older selectors may no longer affect it as intended. Colour-scheme updates should account for the element that passes colour to the SVG.
Our suggested check is a short comparison across normal, hover and keyboard-focus states, including the mobile menu. Look for an icon that disappears, keeps the wrong colour or appears twice. Record the exact state that produces the fault so the developer can repeat it.
Preserve support for earlier versions
Don’t replace every Dashicon reference just because the new API exists. WordPress documents continued support for common existing approaches, along with version-sensitive examples for adopting registered icons.
If a plugin serves sites on different WordPress versions, ask its maintainer to choose the compatibility path. Test the oldest supported version as well as the 7.2 trial. An icon that looks correct on the newest environment doesn’t prove that the shared plugin still behaves correctly elsewhere.
Accept the change with an editing task
Our recommendation is to have an editor carry out an ordinary job after the styling check: open the relevant menu, create a test item and return to the dashboard. Keep labels understandable and focus states visible. Record any behaviour you haven’t tested.
The Contributor Toolkit testing article explains how to report a reproducible fault and a bounded result. Use the same discipline here: identify the customisation, reproduce the problem and review the smallest correction. That gives the upgrade owner a concrete compatibility decision instead of a general assurance that the dashboard looks fine.
Author
