Pollora is splitting into packages you can use on their own, filling in what it still misses of WordPress
(blocks, menus, widgets), and heading toward a Pollora that runs without Laravel, in a classic WordPress or a Bedrock.
The horizons are not dated: they set an order of priority, not a calendar.
The vision
Building blocks, not a monolith
Today most of Pollora lives in one package, pollora/framework, which assumes Laravel. Some pieces are already out:
pollora/hook works in a classic WordPress plugin or theme, and pollora/helper-overrider has no
Laravel dependency at all. The goal is to make that the rule.
01
One package per job
Discovery, attributes and each WordPress integration become packages you can install on their own.
02
The framework assembles
pollora/framework keeps what belongs to Laravel (routing, Eloquent, auth, queues) and wires the packages together.
03
Same code everywhere
A #[PostType] or an #[Action] reads the same in a Laravel app, a classic WordPress or a Bedrock.
04
Third-party plugins stay outside
ACF or Meta Box support comes as a companion package, never inside the framework.
01Short term · The next 13.x releasesFoundations shipped in 13.36
Foundations, and the gaps you notice first
Discovery and attributes left the framework in 13.36: the rest of the roadmap builds on them. Next, Pollora fills three everyday gaps: block variations and styles, menus and widgets.
The foundations Shipped in 13.36, everything else depends on these two
pollora/discovery
Discovery is a package
Discovery scans themes, plugins and modules for classes that carry attributes. It now lives in pollora/discovery, which the framework requires,
and its contracts (Pollora\Discovery\Domain\Contracts\*) are a stable public API.
Runs without Laravel’s application: new DiscoveryEngine() takes no argument, and any PSR-16 cache stores the scans.
The environment plugs in through two contracts: one builds the classes discovery needs (Laravel’s container in Pollora), the other adds its discoveries before each run.
discovery:run and discovery:clear stay in the framework, with the Laravel adapters.
Every attribute declaration lives in pollora/attributes, which reaches neither Laravel nor the framework. Processing each attribute stays in the package of its feature.
#[PostType]
#[Taxonomy]
#[Action]
#[Filter]
#[Meta]
#[Role]
#[Schedule]
#[WpRestRoute]
#[Ajax]
#[Ability]
#[BlockBinding]
#[SkipDiscovery]
WP-CLI attributes
What it unlocks: a plugin can declare its attributes without installing the framework, and an IDE or a static analyser can read them on their own.
Locations in the theme configuration; rendering rules (link_config, item_config, submenu_config) passed to wp_nav_menu()
Planned
Locations declared with a fluent API and an attribute, like post types
A Blade component that renders a menu, keeping the existing class and attribute rules
The docs page listed for what it covers: navigation menus, not admin menus
Widgets and widget areas
Today
Areas declared in the theme’s config/sidebars.php, no other API
Planned
Widget areas with a fluent API and an attribute
A widget as a class with an attribute, rendered in Blade
02Mid term · Once the foundations are outPlanned, order may change
WordPress integrations, one package each
With discovery and attributes standing alone, each feature that mostly talks to WordPress can leave the framework in turn: scheduled tasks, REST routes and WP-CLI commands left in 13.36, then typed meta, roles, Block Bindings and assets in 13.36.1, and the media library, with its image sizes, in 13.37. Blade blocks and patterns are next. In parallel, Pollora covers new WordPress APIs, always in two forms: a fluent API and an attribute.
Next to leave the framework What it has to solve first
Blade blocks & patterns
→ pollora/blocks
Standalone Blade (illuminate/view alone); the editor runtime and <InnerBlocks /> unchanged.
New WordPress APIs Nothing dedicated today; each gets a fluent API and an attribute
Allowed blocks per post type
Restrict or hide blocks, core/* included, per post type
Block Hooks
Insert a block automatically before, after or inside another
Admin pages & settings
Pages and settings declared as attributes, with fields typed like meta
Post statuses
Custom statuses declared the way post types are
Shortcodes
A class with an attribute, rendered in Blade
Dashboard widgets
A class with an attribute, rendered in Blade
Admin notices
A fluent API, targeted by screen and by capability
03Long term · Pollora without LaravelDirection, under study
Pollora in a classic WordPress or a Bedrock
In time, Pollora ships as a mu-plugin that embeds the framework. Each port picks its adapter from what is present: Laravel in a Pollora application, native WordPress elsewhere. Your code stays the same.
A mu-plugin that embeds the framework
The framework loads as it is: only the adapters change with the environment.
Discovery and attributes plug into the active theme and plugins.
Blade stays available for blocks and patterns.
Install by dropping the mu-plugin into a classic WordPress, or with Composer in a Bedrock.
Stays in Laravel applications
Laravel routingRoute::wp()
Eloquentpollora/colt
Authentication
Modules
Same port, the adapter that fits
Laravel cacheCache discovery, results Transients or the WordPress object cache
The config/ folderConfiguration settings Theme configuration and WordPress filters
ArtisanCommands console WP-CLI
Your code calls the port. Which side answers depends on where Pollora runs.
Package map
Everything rests on two packages
Discovery and attributes are the base. The WordPress packages build on them, and the framework assembles them, whether a Laravel
application loads it or, in time, the mu-plugin.