release: v13.34.0-beta

CHANGELOG.md

@@ -5,7 +5,11 @@ All notable changes to the Pollora framework will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased](https://github.com/Pollora/framework/compare/v13.32.0-beta.9...develop)
+## [Unreleased](https://github.com/Pollora/framework/compare/v13.34.0-beta...develop)
+
+## [v13.34.0-beta](https://github.com/Pollora/framework/compare/v13.32.0-beta.9...v13.34.0-beta) - 2026-09-29
+
+The framework's version tracks Laravel's: this beta requires Laravel 13.34.
 
 ### Added
 - A third `pollora:make:theme` template, **Magazine** (`magazine` → `pollora/theme-buzz`): a Full Site Editing block theme whose templates, parts and patterns are edited in the Site Editor, next to `default` and `ecommerce`. The missing-theme page and admin notice list it too
@@ -16,6 +20,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - A real 404 lost its `error404` body class, and every page served by the template hierarchy carried a meaningless one built from its path (`any-no-such-page`). The `WordPressBodyClass` middleware was meant for Laravel routes, which WordPress's own resolution calls a 404, but it only ran on WordPress routes — the `{any}` fallback included — where WordPress's verdict is the right one. So it did the opposite of its job on both sides: a Laravel route (`Route::get('/dashboard/{tab}')`) kept `error404`, `is_404()` true and a "Page not found" title over its 200 response
 
 ### Changed
+- Requires Laravel 13.34: `illuminate/*` `^13.34` (was `^13.32`). Measured on `laravel/framework` v13.34.0: the full suite, Pint, PHPStan and Rector pass unchanged
 - The `WordPressBodyClass` middleware is replaced by a `RouteMatched` listener, `ApplyApplicationRouteContext`, which runs on every route: a route WordPress answers (`Route::wp()` and the template-hierarchy fallback, both flagged `isWordPressRoute()`) keeps WordPress's classes and verdict untouched; any other route has `is_404()` cleared and its URI segments added as body classes (`dashboard tab-settings`). A middleware could not do this — Laravel routes are not given the WordPress middleware stack
 - On the front end and in the admin, a Vite script is enqueued as a WordPress script module (`wp_enqueue_script_module`), so WordPress places it after its import map, as it does its own modules: in the head of a block theme (the footer with `loadInFooter()`), always in the footer of a classic theme. What a module cannot take — `dependencies()`, `localize()`, `inline()` — goes on a classic companion script, `{handle}-data`, which runs before the module. The editor, login screen and Customizer are unchanged
 

composer.json

@@ -24,11 +24,11 @@
     "require": {
         "php": "^8.3",
         "pollora/helper-overrider": "^1.2",
-        "illuminate/auth": "^13.32",
-        "illuminate/support": "^13.32",
-        "illuminate/database": "^13.32",
-        "illuminate/routing": "^13.32",
-        "illuminate/console": "^13.32",
+        "illuminate/auth": "^13.34",
+        "illuminate/support": "^13.34",
+        "illuminate/database": "^13.34",
+        "illuminate/routing": "^13.34",
+        "illuminate/console": "^13.34",
         "pollora/abilities": "^1.0",
         "pollora/ajax": "^1.0",
         "pollora/entity": "^1.2",
@@ -44,7 +44,7 @@
         "coduo/php-humanizer": "5.0.3",
         "nwidart/laravel-modules": "^13.0",
         "symfony/process": "^7.4 || ^8.0",
-        "illuminate/config": "^13.32",
+        "illuminate/config": "^13.34",
         "laravel/prompts": "^0.3.21"
     },
     "autoload": {