Weave Code
Framework Laravel Package
pollora/framework
Pollora Framework brings Laravel's toolkit to WordPress development, letting you build themes and plugins with Blade templates, Eloquent models, service providers, and familiar Laravel conventions while staying fully compatible with WordPress.
Pollora Framework brings the elegance of Laravel to WordPress development. Build maintainable themes and plugins with a familiar structure, dependency injection, Blade views, and modern tooling—without abandoning WordPress’s ecosystem.
- Laravel-style architecture with service providers, facades, and a powerful container
- Blade templating for clean, reusable WordPress views
- Eloquent ORM and migrations for safer data handling
- Vite-powered asset pipeline and modern frontend workflow
- Seamless WordPress integration for hooks, post types, and taxonomies
Frequently asked questions about Framework
- What is Pollora Framework and how does it work with Laravel and WordPress?
- Pollora Framework is a Laravel-native framework for WordPress that lets you build themes and plugins with Blade templates, Eloquent models, Laravel routing, service providers, dependency injection and Artisan tooling running on top of WordPress. It adds PHP 8 attributes for registering hooks, custom post types and REST routes, so a lot of WordPress boilerplate becomes declarative code. WordPress still renders and serves the site; Pollora supplies the Laravel-style architecture and workflow around it.
- How do I install pollora/framework with Composer?
- Require the package with Composer in your theme or plugin and let the framework bootstrap the Laravel container, service providers and Artisan commands over WordPress. Because v13.36.1 hard-requires pollora/block-bindings, pollora/roles, pollora/meta and pollora/assets, a normal composer update pulls those first-party packages in as well. Publish any package config and assets your project needs as part of your deploy step rather than ad hoc, and follow the repository README for the bootstrap file and directory conventions.
- Which Laravel, PHP and WordPress versions does Pollora Framework require?
- The framework targets PHP 8, since it relies on PHP 8 attributes, alongside a modern Laravel release with WordPress as the runtime underneath. Each of the four split packages declares its own Composer constraints, so their floors can diverge from the framework's — confirm the exact minimums in each package's composer.json before upgrading. Treat the framework, the four packages and pollora/query as one supported version matrix instead of mixing versions independently.
- Is upgrading to Pollora v13.36.1 a breaking change for my theme or plugin?
- For code that stays on the public surface — facades, attributes, config files and Artisan commands — the release is effectively a no-op, because public class names are explicitly preserved. Risk is concentrated in two places: Laravel-side classes that moved into the Pollora Meta, Role and BlockBinding Infrastructure Laravel namespaces, and code that constructed AssetFile, AssetManager or MetaUiDrivers directly or called MetaAccessor::extend(), which must now satisfy the new resolver and PSR-11 contracts. Grep for direct imports of the moved classes and audit manual construction before shipping.
- Why did my query results change after updating pollora/query to 2.0?
- pollora/query now accepts ^1.0 || ^2.0, and composer update resolves to 2.0, whose fixes change queries that previously ran successfully but incorrectly. where() combined with orWhere() now groups earlier clauses as (a AND b) OR c, DateQuery::inclusive() actually applies, dates use a 24-hour clock, and invalid fields(), userPermission() calls or orderBy() directions throw QueryException instead of being ignored. The first three are silent result-set changes, so re-test reporting and filtered listings against realistic data. Pin pollora/query to ^1.0 in a branch if you need to isolate the architectural decomposition from the query semantics change.
- How do I fix QueryException errors after upgrading Pollora?
- Query 2.0 throws QueryException for field names, userPermission() values and orderBy() directions it previously ignored, so a page that appeared to work can now return a 500. Inventory every query that passes dynamic field names, sort directions or permission strings and validate them before they reach the query builder. Then read the pollora/query 2.0 upgrading guide and run your test suite against production-like data before deploying.
- Where did MetaServiceProvider, RoleServiceProvider and LaravelMetaValidator move in v13?
- Those Laravel-side classes moved into the Pollora\Meta\Infrastructure\Laravel, Pollora\Role\Infrastructure\Laravel and Pollora\BlockBinding\Infrastructure\Laravel namespaces as part of the ports-and-adapters split. Also check imports of TypedMetaCheck, MetaListCommand, MetaAuditCommand, EnsureUserHasRole, RoleDirective and RolesCheck. Update the use statements in your application code, and confirm whether the release ships class aliases or a deprecation shim — if it does not, the namespace move is a silent breaking change for direct importers.
- Do I need to publish config or assets for the new pollora/meta, pollora/roles, pollora/assets and pollora/block-bindings packages?
- Yes. Check each package for publishable config and front-end assets such as block-bindings.js, and add them to your vendor:publish deploy step so releases stay reproducible. Also confirm the block-bindings preview route is registered in each environment. Missing published assets usually surface as a broken editor preview rather than a PHP error, so verify in staging.
- Can I use Pollora with classic WordPress themes, plugins or Bedrock sites without Laravel?
- Assets now resolve Vite builds without Laravel, which is what unlocks classic themes, plugins and Bedrock sites. The split packages are framework-agnostic at their core — PSR-11 container, PSR-3 logger, explicit constructor arguments and resolver registration — while everything that needs Laravel (providers, facades, config, ViteManager, HasRoles, HasTypedMeta, the @role directive, role middleware, LaravelMetaValidator and commands) stays in the framework. For non-Laravel consumers, expect to wire the container and resolver yourself.
- Does pollora:doctor detect version mismatches between the framework and the split packages?
- The doctor command is documented around configuration problems and is not described as validating that the framework and the four split packages are on compatible versions. With a multi-package matrix covering the framework, pollora/block-bindings, pollora/roles, pollora/meta, pollora/assets and query 1.x or 2.0, version skew is a real risk. Pin exact versions in composer.lock and assert compatibility explicitly in CI rather than relying on doctor alone.
Weaver
How can I help you explore Laravel packages today?