# Pollora puts WordPress inside Laravel — a PHP-first path with a two-framework maintenance cost The open-source Pollora framework keeps WordPress as a CMS while making Laravel the front-end application, with Blade templates, PHP attributes and Composer-managed WordPress updates. Pollora changes the WordPress build workflow for Laravel teams, but developers must accept PHP 8.4 requirements, dual boot costs and compatibility testing. - Status: Active - Published: 2026-11-03T16:20:16+13:00 - Updated: 2026-11-03T16:20:16+13:00 - Categories: Web Development, PHP, WordPress, Frameworks, Developer Tools - Tags: Blade, Composer, Laravel, open source - Canonical HTML: https://beyondthe.news/dossiers/pollora-wordpress-inside-laravel-blade-php-attributes-composer-framework ## 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. ## Key details - Independent Laravel News walkthrough: October 29, 2026. - Laravel-first routes and Blade templates; WordPress admin/plugins retained. - PHP attributes, Gutenberg Blade rendering, Eloquent WordPress models and Vite assets. - PHP 8.4+ and MySQL/MariaDB required. - WordPress core managed via Composer; both frameworks load per request. - MIT-licensed source; no independent production benchmark. ## Builder takeaways - Prototype Pollora on a new site before migrating an established WordPress installation. - Verify PHP 8.4, MySQL/MariaDB and Node requirements and pin compatible Composer tags. - Test plugin hooks, WooCommerce/ACF, REST, cron, media, admin and caching. - Benchmark memory and response times because Laravel and WordPress both bootstrap. - Prefer Sage or Acorn when conventional WordPress theme compatibility is essential. ## What to watch - Independent production deployments, performance and plugin-compatibility reports. - Maintainer releases and dependency security updates. - Migration tooling and changes in Laravel/WordPress version support. ## Uncertainties - 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 - [Pollora: Run WordPress Inside a Laravel Application](https://laravel-news.com/pollora-wordpress-laravel) — Laravel News · independent specialist reporting · 2026-10-29T00:00:00+13:00. Technical walkthrough and comparison with other integration approaches. - [Pollora skeleton](https://github.com/Pollora/pollora) — Pollora maintainers · primary open-source repository · 2026-11-03T00:00:00+13:00. MIT project skeleton, requirements and setup. - [Pollora installation guide](https://pollora.dev/getting-started/installation/) — Pollora · primary documentation · 2026-11-03T00:00:00+13:00. Current version, requirements, DDEV and Composer install paths.