v13.32.0-beta.2
Pre-release
Pre-release
·
237 commits
to main
since this release
Added
- pollora.dev as the project website and documentation:
homepageandsupport.docsincomposer.json(shown on Packagist),homepageinpackage.json, the README, and a Documentation link in the Pollora admin dashboard header - Gutenberg blocks render with Blade: a
block.json"render": "file:./render.blade.php"renders through the view factory with$attributes,$contentand$block, Blade components included.pollora:make:blocknow creates dynamic Blade blocks by default — their markup is not stored inpost_content, so changing it never invalidates existing content — and--staticcreates a block withsave.jsx BlockRegistrar::registerDirectory()andregisterBlock()accept an optionalbasePath, the Vite project root the asset entry points are resolved from; it defaults to the closest directory holding avite.configfile, or else the one containingresources/
Changed
- Blocks live in
resources/views/blocks/{slug}instead ofresources/blocks/{slug}, next to the Blade views, forpollora:make:block, itsBlocksServiceProviderstub and the Vite entries it generates. See Migrating fromresources/blocks pollora:make:blocklimits Vite full reloads underresources/viewsto Blade files: laravel-vite-plugin'srefreshPathsand aresources/views/**glob would reload the page on every block JSX change instead of hot-replacing it- BREAKING for custom
BlockRegistrarInterfaceimplementations: both methods gained the optional?string $basePath = nullparameter - Relicensed under MIT, like the other Pollora packages:
composer.jsonand the README declaredGPL-2.0-or-later, and the only license files were the 0BSD/WTFPL texts inherited from the original WordPress integration by Jordan Doyle, now credited in the README - Development against WordPress 7.1 stubs (
php-stubs/wordpress-stubs^7.1);patches/wordpress-stubs.patchregenerated for them and reduced to the__()→__wp()rename. Itswp_mail()hunk no longer matched the stubs (WordPress added an$embedsparameter) and renamed a function nothing overrides mockery/mockery^1.6.11in development
Deprecated
- Blocks in
resources/blocksare still registered, with a notice in the log, until Pollora v15. A theme or plugin blocks directory scans both locations, and a block present in both is taken fromresources/views/blocks pollora:make:block --dynamic, now the default
Fixed
- A block
renderfile outside the block directory is no longer included: WordPress built its own render callback fromblock.jsonwhenever Pollora's check rejected the path - Blocks built with
vite buildget their view script and stylesheets again: the Vite entries generated bypollora:make:blockonly listed each block'sindexscript, soviewScript,styleandeditorStylewere missing from the production manifest. Running the command again in a configured theme or plugin rewrites the entries pollora:make:blockaddswordpressPlugin()to the Vite plugins on first use: it imported the plugin, then skipped adding it because the name was already in the file- The Artisan commands renamed to the Laravel colon convention in v13.32.0-beta answer to their previous names again. The rename left no alias, so a project whose
composer.jsonstill ranpollora:env-setupinpost-autoload-dumpfailedcomposer installright after upgrading. Kept as aliases:pollora:env-setup,pollora:make-theme,pollora:delete-theme,pollora:make-plugin,pollora:make-block,pollora:make-model,pollora:make-action,pollora:make-filter,pollora:make-posttype,pollora:make-taxonomy,pollora:make-wp-cli pollora:installpointed to a non-existentwp:env-setupcommand when the database connection failed- Asset containers no longer share one Vite configuration. Each
ViteManagerreconfigured Laravel'sVitesingleton in place, so the last container set up — typically the theme — imposed its hot file on every other one: with the theme onnpm run devand a plugin built for production, the plugin's assets resolved as built but were enqueued as hot, and the block editor crashed withforceFullUrl(): Argument #1 ($path) must be of type string, array given. ThegetAssetUrlsmacro likewise read the build directory of the last manager registered instead of its own, and the Vite client tag was rendered from the unconfigured singleton pollora:installcompletes without interaction (--no-interaction, CI, piped stdin). It calledpollora:make:themewithout a name, which failed withNot enough arguments (missing: "name")after WordPress was installed; it now generates thedefaulttheme frompollora/theme-default— the theme WordPress activates on install — or the one named by the new--themeoptionpollora:installruns its migrations with--forceand fails when they fail. In production,migrateasks for confirmation and cancels when it cannot prompt, yet the install reportedMigration completed successfully: a non-interactive production install left the sessions and cache tables missing and every page answered 500- Commands using
PromptsForMissingOption(pollora:make:theme,pollora:make:plugin) apply their prompt defaults when they cannot prompt, instead of leaving the options empty: a theme generated without interaction had astyle.csswith no author, URI, description or version
Removed
patches/mockery-php84-nullable.patch— Mockery fixed the PHP 8.4 implicit nullable deprecations upstream, so the patch no longer applied and printedCould not apply patch!on everycomposer install, including in projects built on the skeleton.patches/wordpress-core.patchstays: it is what letspollora/helper-overriderdeclare__()