v13.32.0-beta.3

Fixed

• The block editor now shows the theme's own styles, so a block looks in the back office much like it does on the front. Both default themes declare editor-styles support, but that support only tells WordPress how to treat the styles it is handed — it loads none, and nothing named any: theme assets are registered with toFrontend(), leaving the editor with theme.json's variables and none of the rules built from them. The theme's built stylesheets are read from its Vite manifest and passed to add_editor_style(), which is what reaches inside the editor iframe; enqueueing on enqueue_block_editor_assets lands in the admin page around it instead. Any theme declaring the support gets this, with no change of its own
• Multisite is usable again. Bootstrap::rewriteNetworkUrl() is hooked to the network_site_url filter, which WordPress applies with a $scheme of null whenever no explicit scheme is requested — the common case — while the method declared a non-nullable string $scheme. Every request fatalled as soon as MULTISITE was enabled, the admin included. $path and $scheme now carry defaults matching the filter's own signature; single-site installs never reach this path (#296)
• pollora:install no longer leaves a site whose articles answer 404. It set the permalink structure and flushed, but the rule set WordPress can build mid-install is incomplete — taxonomies and post types are not all registered at that point — so flushing stored exactly that, and every single-post URL 404'd until something flushed again later. The option is dropped instead, letting WordPress rebuild it on the first request. This is the same reasoning completeWebInstall() already applied to the WordPress web installer; that hook is registered only outside the console, so the command-line install never went through it. Measured on a fresh install: 404 on an article before, 200 after
• The missing-theme guidance page now reaches the case it was written for. It was wired only onto the exception handler, catching the View [home] not found that view() used to throw; since the skeleton stopped declaring WordPress routes the template hierarchy decides, nothing calls view(), nothing throws, and a site with no theme answered a bare 404 instead — the crash the page exists to replace, wearing a different status code. The request is now taken over on template_redirect, which WordPress fires before any template is chosen and which runWp() reaches before Laravel routes, alongside the existing handling for robots, favicons, feeds and trackbacks. The exception path stays for anything still routing through view(), and its registration no longer sits behind a guard that could skip the hook. The admin, AJAX and REST keep their normal responses: the admin is where the user goes to fix this
• Blade templates now outrank the PHP stubs at a theme's root. The root holds the files WordPress needs to consider the theme valid — index.php in particular, which ships as "Silence is golden" — and was registered as a view path ahead of resources/views, so locate() ranked its index.php above resources/views/index.blade.php. Every request the template hierarchy could not match to a more specific template (archives, search, custom post types, any single view without its own template) rendered that stub: HTTP 200 with an empty body and no error anywhere. Blade and PHP candidates are now collected separately so every Blade one wins, and view paths are registered in the order they are declared. A classic PHP template with no Blade equivalent is still used
• Installing WordPress on a URL where a site already answers no longer dies with Class "WP_Http_Cookie" not found. wp_install() calls wp_remote_get() on the site URL and WP_Http builds a WP_Http_Cookie for every Set-Cookie header it gets back, but the install bootstrap loaded only part of the HTTP stack. It now loads the classes wp-settings.php loads, in its order. This affected reinstalls, migrations, and taking a domain back
• wordpress.org no longer offers updates for the themes the project scaffolds. WordPress sends every installed theme to its update API keyed by the directory name, so a theme whose name matches a published slug is offered that unrelated theme — default, which pollora:install generates, matches one, and accepting the offer replaced the project's theme with a download of the theme published there in 2005. Offers aimed at a theme in the project's themes directory are moved to no_update. The Update URI header does not cover this on its own: WordPress consults the matching update_themes_{$hostname} filter only when wordpress.org returned nothing for that theme
• A site installed through the WordPress web installer no longer answers 404 on every category, tag and date archive. The rewrite rules WordPress stores during its own install are incomplete — taxonomies and post types are not all registered at that point — and nothing regenerated them afterwards. The option is now dropped on wp_install, where the migrations already run, so WordPress rebuilds the rules on a later request
• wp-admin no longer reports the active theme as missing while the front end renders it. get_stylesheet_directory() goes through the theme_root filter Pollora sets, but wp_get_theme() computes the root itself and no filter applies there. Registering Pollora's themes directory replaced $wp_theme_directories instead of appending to it, and get_raw_theme_root() answers a hardcoded /themes whenever a single directory is registered, which wp_get_theme() then resolves against WP_CONTENT_DIR. WordPress's own themes directory is kept alongside Pollora's, and the stylesheet_root and template_root options now hold the directory containing the themes rather than the active theme's own directory, which was one level too deep
• A site installed through the WordPress web installer explains what to do instead of crashing. That path never runs pollora:install, so themes/ stays empty while the stylesheet option already points at WP_DEFAULT_THEME, and every front-end request died on View [home] not found. A missing view on a front-end request now renders a page naming the two theme templates and the command that scaffolds them, and wp-admin carries the same warning. It applies only while the site has no theme at all, so a headless install keeps working and a theme missing a single template still surfaces its real error