v13.32.0-beta.5

Added

• The login screen wears the theme's design, from the theme's own theme.json. WordPress loads the theme on wp-login.php but emits none of its design there — measured: zero occurrences of wp--preset--color in the HTML of a login screen — so every site logs in through the same grey form whatever it looks like elsewhere. A theme that ships a config/login.php now gets its colours, radii and typography printed on login_head, its own logo above the form, and its home page behind that logo instead of wordpress.org. Nothing is duplicated: the design stays in theme.json, and restyling a theme restyles its login screen. Sign-in, lost password, reset, register and the confirm-admin-email prompt are all covered, being one screen as far as login_head is concerned. Strictly opt-in — a theme with no config/login.php gets WordPress's screen, byte for byte, so upgrading the framework never changes the page people sign in through. See Theming → Login screen
• pollora/login/palette, pollora/login/logo, pollora/login/styles and pollora/login/credit filters, for a module or a plugin to take over any part of the login screen without touching the theme
• Discovery says so when one location takes more than 250ms to scan, naming the location, the time and how many structures it found. The cost above was absorbed in complete silence for as long as it existed — no log line, no notice, nothing that measured it. Debug mode only: with the cache on, the cost is paid once

Changed

• A theme's config/login.php is loaded on init, like menus.php, sidebars.php and templates.php, so __() works in it. WordPress fires init through wp-load.php before wp-login.php fires login_init, so the config is in place well before anything reads it

Fixed

• Attribute discovery no longer walks a plugin's node_modules. Themes and modules have always been scanned at app/, falling back to src/ — the two directories the autoloader maps Plugin\{Name}\ onto — while plugins were scanned at their root, which is where node_modules/ lands as soon as a plugin has a Vite build. Symfony's Finder enumerates every file before filtering by extension, so the walk costs everything and the extension check costs nothing: measured on a demo plugin with a block build, 69,741 files walked on every request to reach the three PHP files the plugin owns — 1,691 ms against 1 ms for the same directory without node_modules. It also discovered five WordPress core classes shipped inside @wordpress/style-engine and handed them to the discovery pipeline, which is its own kind of wrong. With APP_DEBUG on, discovery keeps no cache, so a site paid this on every request: the home page of a site with one such plugin went from 3.0s to 0.78s, and from 691MB of peak memory to 37MB under Blackfire. A plugin shipping neither app/ nor src/ is still scanned at its root, so one keeping its classes at the top level is unaffected