Metabox Bridge Laravel Package

Product Decisions This Supports

• Build vs. buy on admin UI scaffolding: field groups, settings pages, and Gutenberg blocks can be declared with PHP 8 attributes (#[FieldGroup], #[Block], #[SettingsPage]) instead of hand-written registration code. This shortens the path from "content model agreed" to "editors can enter content," which is usually the slowest part of a WordPress/Laravel delivery.
• Scope decisions on block development: blocks render through Blade views named after their namespace and ID. That means simple blocks can be shipped without a JS build pipeline or a React toolchain — a meaningful reduction in surface area for teams without dedicated frontend capacity.
• Content modeling tied to Pollora primitives: Pollora post types and taxonomies are valid targets, and classes are resolved through the container. Custom fields attach directly to the content types the rest of the app already defines, so the field layer follows the domain model rather than duplicating it.
• Roadmap sequencing: the discovery pass registers each class exactly once and reports invalid declarations without aborting the rest. This is the kind of reliability work that makes the package viable for multi-developer projects — a single malformed attribute won't take down the admin. Treat "safe to let the whole team touch it" as a milestone, not a given.
• Use cases this unlocks: agency/retainer builds on WordPress with Laravel conventions, custom Gutenberg blocks rendered server-side, per-post-type field groups, and plugin-level settings pages.
• Configuration as a product decision: config/metabox.php (publishable via the metabox-config tag) exposes default block category, mode, views, and field group priority. Defaults become a team convention you can codify once instead of repeating per project — worth a decision on what your house defaults should be.

When to Consider This Package

Consider it when all of the following hold:

• You are already building on Pollora (or committed to it) and want Laravel-style, code-first WordPress admin configuration.
• You are on, or can move to, pollora/metabox 3.1+ — v1.1.0 raises that floor. Verify your installed version and any pinned constraints before upgrading; this is the main compatibility risk in this release.
• Your team is comfortable with attribute-based declaration and container-resolved classes, and prefers configuration in PHP over admin-UI point-and-click.
• You want server-rendered blocks via Blade rather than committing to a JS/React block build.

Look elsewhere — or wait — when:

• You are not on Pollora; the integration features (post type/taxonomy targets, container-created classes, namespaced Blade block views) are the core value and won't transfer.
• You depend on the wider third-party metabox plugin ecosystem or on an admin-UI-first workflow for non-developers.
• You need a long-term, versioned API guarantee. This is a young package on a 1.x line already raising its dependency floor; budget for upgrade work each release.
• You need complex, interactive block editor experiences — Blade rendering covers presentation, not rich editor-side interactivity.

How to Pitch It (Stakeholders)

For executives: This release turns a promising integration into something a team can safely build on. Content types, custom fields, settings pages, and editor blocks are now declared in code with a single, consistent pattern, and configuration is centralized in one publishable file. The practical effect is faster delivery of admin/content features and less bespoke glue code to maintain. The principal caveat is dependency maturity: it requires pollora/metabox 3.1 and sits on an early 1.x line, so treat it as a deliberate bet on the Pollora stack rather than a general-purpose choice.

For engineering: v1.1.0 adds attribute discovery for #[FieldGroup], #[Block], and #[SettingsPage] with idempotent registration — each class registers once regardless of how many discovery passes Pollora runs — and per-class error isolation, so one invalid declaration is reported without blocking the others. Pollora integration is the substance of the release: container-created classes, Pollora post types and taxonomies as field targets, and blocks rendered from Blade views named by namespace and ID. Config lands in config/metabox.php, publishable via the metabox-config tag, covering default block category, mode, views, and field group priority. Action items before adoption: confirm pollora/metabox is at 3.1 or above, publish and review the config file, and decide house defaults for block category/mode rather than inheriting them implicitly.