Key details

  1. Independent Laravel News walkthrough: October 29, 2026.
  2. Laravel-first routes and Blade templates; WordPress admin/plugins retained.
  3. PHP attributes, Gutenberg Blade rendering, Eloquent WordPress models and Vite assets.
  4. PHP 8.4+ and MySQL/MariaDB required.
  5. WordPress core managed via Composer; both frameworks load per request.
  6. MIT-licensed source; no independent production benchmark.

What builders should take away

  1. Prototype Pollora on a new site before migrating an established WordPress installation.
  2. Verify PHP 8.4, MySQL/MariaDB and Node requirements and pin compatible Composer tags.
  3. Test plugin hooks, WooCommerce/ACF, REST, cron, media, admin and caching.
  4. Benchmark memory and response times because Laravel and WordPress both bootstrap.
  5. Prefer Sage or Acorn when conventional WordPress theme compatibility is essential.

What changed

Pollora's public 13.x framework and project skeleton offer a Laravel-first WordPress architecture, described in an October 29, 2026 Laravel News technical walkthrough. Laravel boots first and handles front-end routes, controllers, middleware, Blade templates and Vite assets; WordPress is loaded inside it and continues to provide admin, database, plugins and Gutenberg editing. PHP 8 attributes register WordPress post types, taxonomies, hooks and REST routes. The MIT-licensed project ships a Composer starter and CLI with DDEV support.

Why it matters

PHP teams can keep WordPress content editing and plugin workflows while building the front end with Laravel's routing, ORM and tooling, without a separate headless CMS API. But every request loads both systems, WordPress core updates move to Composer, and conventional theme execution is replaced. That changes hosting requirements, performance assumptions and compatibility testing.

Laravel owns requests while WordPress remains the editor

Install with composer create-project pollora/pollora or the Pollora CLI. WordPress core lives under public/cms and loads during Laravel bootstrap. Laravel handles frontend responses through Route::wp() and Route::wpMatch() using WordPress conditional tags; unmatched routes use WordPress-style template hierarchy as Blade files. WordPress admin, database and plugins remain available, but this is not a conventional theme.

PHP attributes and Blade replace much of the traditional WordPress glue

Pollora discovers PHP attributes for post types, taxonomies, actions, filters and REST endpoints. Gutenberg blocks can use JSX editor files and Blade for server output and previews. WordPress media can use Laravel filesystem disks, including S3-compatible object storage, while Colt exposes WordPress records through Eloquent models.

The maintenance and hosting boundary is substantial

The current skeleton requires PHP 8.4+, Composer 2, MySQL 5.7+ or MariaDB 10.3+, plus Node/npm for Vite. SQLite and PostgreSQL are not supported for the WordPress bootstrap. Core updates go through Composer rather than the dashboard. Both frameworks load per request; benchmark real workloads rather than assuming a speed gain. Test plugins, admin, REST, cron, caching, media and themes before migrating a mature site.

Compared with Sage, Acorn and Corcel

Acorn brings Laravel components into WordPress; Sage is a WordPress theme workflow; Corcel reads WordPress data from a Laravel app. Pollora reverses the boot order, treating Laravel as the main application and WordPress as embedded CMS. Laravel News independently documents the implementation and describes the project as young relative to established Roots tools.

Evidence limitations

The source skeleton, documentation and Laravel News walkthrough establish design and installability, not independent production performance, broad plugin compatibility or long-term maintenance reliability. The installation page contains an inconsistent older version reference alongside a current 13.39.2 claim; pin and verify exact Composer versions.

What to watch next

  • Independent production deployments, performance and plugin-compatibility reports.
  • Maintainer releases and dependency security updates.
  • Migration tooling and changes in Laravel/WordPress version support.

Still unclear

  • No independent production-scale performance or broad compatibility study was found.
  • Docs have inconsistent version references; verify actual package tags.
  • Plugin assumptions about traditional WordPress boot and filesystem layouts may not hold.

Sources

Direct reading behind this dossier.

3 sources
Pollora skeleton
Pollora maintainers primary open-source repository

MIT project skeleton, requirements and setup.

Pollora installation guide
Pollora primary documentation

Current version, requirements, DDEV and Composer install paths.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment