Skip to content

v13.32.0-beta.2

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 17 Sep 16:32
· 237 commits to main since this release

Added

  • pollora.dev as the project website and documentation: homepage and support.docs in composer.json (shown on Packagist), homepage in package.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, $content and $block, Blade components included. pollora:make:block now creates dynamic Blade blocks by default — their markup is not stored in post_content, so changing it never invalidates existing content — and --static creates a block with save.jsx
  • BlockRegistrar::registerDirectory() and registerBlock() accept an optional basePath, the Vite project root the asset entry points are resolved from; it defaults to the closest directory holding a vite.config file, or else the one containing resources/

Changed

  • Blocks live in resources/views/blocks/{slug} instead of resources/blocks/{slug}, next to the Blade views, for pollora:make:block, its BlocksServiceProvider stub and the Vite entries it generates. See Migrating from resources/blocks
  • pollora:make:block limits Vite full reloads under resources/views to Blade files: laravel-vite-plugin's refreshPaths and a resources/views/** glob would reload the page on every block JSX change instead of hot-replacing it
  • BREAKING for custom BlockRegistrarInterface implementations: both methods gained the optional ?string $basePath = null parameter
  • Relicensed under MIT, like the other Pollora packages: composer.json and the README declared GPL-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.patch regenerated for them and reduced to the __() → __wp() rename. Its wp_mail() hunk no longer matched the stubs (WordPress added an $embeds parameter) and renamed a function nothing overrides
  • mockery/mockery ^1.6.11 in development

Deprecated

  • Blocks in resources/blocks are 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 from resources/views/blocks
  • pollora:make:block --dynamic, now the default

Fixed

  • A block render file outside the block directory is no longer included: WordPress built its own render callback from block.json whenever Pollora's check rejected the path
  • Blocks built with vite build get their view script and stylesheets again: the Vite entries generated by pollora:make:block only listed each block's index script, so viewScript, style and editorStyle were missing from the production manifest. Running the command again in a configured theme or plugin rewrites the entries
  • pollora:make:block adds wordpressPlugin() 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.json still ran pollora:env-setup in post-autoload-dump failed composer install right 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:install pointed to a non-existent wp:env-setup command when the database connection failed
  • Asset containers no longer share one Vite configuration. Each ViteManager reconfigured Laravel's Vite singleton in place, so the last container set up — typically the theme — imposed its hot file on every other one: with the theme on npm run dev and a plugin built for production, the plugin's assets resolved as built but were enqueued as hot, and the block editor crashed with forceFullUrl(): Argument #1 ($path) must be of type string, array given. The getAssetUrls macro 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:install completes without interaction (--no-interaction, CI, piped stdin). It called pollora:make:theme without a name, which failed with Not enough arguments (missing: "name") after WordPress was installed; it now generates the default theme from pollora/theme-default — the theme WordPress activates on install — or the one named by the new --theme option
  • pollora:install runs its migrations with --force and fails when they fail. In production, migrate asks for confirmation and cancels when it cannot prompt, yet the install reported Migration 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 a style.css with 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 printed Could not apply patch! on every composer install, including in projects built on the skeleton. patches/wordpress-core.patch stays: it is what lets pollora/helper-overrider declare __()