v13.32.0-beta.4

Added

• Every page says which template answered it, as an HTML comment on wp_head, whenever WP_DEBUG is on. WordPress offers no way to see which template rendered a request short of reading the code and guessing, and a Blade hierarchy on top makes the guess harder — several files could plausibly have answered, and which one did is the whole question when a page comes back wrong. Themes had started marking their own views by hand, one at a time, and drifting: theme-apiary marks most of its templates and not its front page. This is derived from the template the request actually resolved to, so it cannot be forgotten, and it reaches every theme without one of its own. A comment changes no markup and no styling; nothing at all is emitted in production, and the path is relative to the project so it never says where the site lives on disk

Fixed

• A failed starter download says what happened instead of raising a TypeError. make:theme and make:plugin fetch their template from GitHub and, when that fails, fall back to copying one bundled with the framework — except none is bundled: neither src/Theme/stubs/ nor src/Plugin/stubs/ exists. getTemplatePath() declared string and returned realpath()'s false, so a transient network failure surfaced as getTemplatePath(): Return value must be of type string, false returned, naming a method the user has never heard of and saying nothing about the download. Measured on CI the first time GitHub did not serve an archive. Both commands now fail with a sentence that names the cause
• A REST controller declaring WP_REST_Request $request receives it. Handler arguments were built from the route parameters alone, so that type hint had get_param('request') looked up — no route declares a parameter by that name — and the method was invoked with null, fatalling on a TypeError before a line of it ran. Every endpoint whose handler asked for the request answered 500. A parameter type-hinted WP_REST_Request now gets the request; everything else still comes from the route, and builtin types are left alone since they name route values
• WordPress's own entry points answer their real status again. wp-login.php, wp-links-opml.php and the rest are run directly by PHP, with Pollora loaded along the way through wp-config.php; it resolved the URL as a content request anyway, and /cms/wp-login.php matches the attachment rewrite rule [^/]+/([^/]+)/?$. No such attachment exists, so WordPress sent a 404 header — and then rendered a perfectly good login form underneath it. The query now runs only when Laravel's front controller is the script being executed, which covers any entry point WordPress or a project adds later without naming it. pollora_loaded still fires either way
• /cms/ no longer answers with the source of a Blade template. The WordPress installation root is served by WordPress's own index.php, whose template-loader.php includes whatever the template hierarchy hands it — and Pollora puts Blade sources in that hierarchy, since it renders them through Laravel. PHP printed one verbatim, directives and all. A front-end request that reaches that loader has bypassed Laravel and was looking for the site, so it is redirected to the home URL
• make:theme and make:plugin download the highest version of a starter, not whichever tag GitHub listed first. That order follows what was pushed most recently, so a fix tagged on an older line — 1.2.1 published after 1.4.0 — would have been handed to everyone scaffolding, a downgrade with nothing to notice it by. Tags are now compared as versions, pre-releases lose to any stable version so tagging a beta does not push it onto people who asked for nothing in particular, and a tag that is not a version at all is left out of the comparison rather than winning it. A repository whose tags follow some other scheme keeps its previous behaviour. The request also asks for 100 tags instead of the default 30, which could leave the highest version on an unread second page