Voyager Page Blocks Laravel Package

Product Decisions This Supports

• Page composition: build vs. buy. The package is essentially a pre-built data model + Voyager BREAD screens for reusable page blocks (heroes, text sections, CTAs, embedded content). It lets a PM answer "do we need to build an editorial block system, or is a thin module enough?" without committing engineering weeks to a custom CMS feature.
• Feature scope for a CMS/admin area. If the roadmap item is "marketing can edit pages without a deploy," this module defines a minimum viable shape: a page_blocks-style table, an admin CRUD surface, and a Blade render hook. It is a scoping artifact as much as a dependency — useful for estimating what the "real" version needs (ordering, previews, revisions, roles).
• Content ops velocity as a product bet. It supports the decision to invest in editor self-service instead of routing every copy change through a release. That trade is usually justified for marketing/resource/landing pages and rarely justified for highly transactional or design-locked screens.
• Stack/roadmap question: stay on Voyager or migrate. Adoption is implicitly a statement that Voyager remains the admin layer. Because the package is archived (last release July 2020), it should surface a companion decision: are we extending a legacy admin, or using this as a bridge while we plan a move to a maintained CMS/headless content layer?
• Use cases it fits: brochure/marketing sections, resource and FAQ hubs, reusable promotional blocks and CTAs across multiple pages, and internal tools where content freshness matters more than workflow rigor.
• Use cases it does not settle: versioning/approval workflows, localization, granular editorial permissions, structured content reuse across channels, and anything needing vendor support or an SLA.

When to Consider This Package

Consider it when:

• You are already running Voyager on a Laravel app, and the alternative to this module is hand-rolling block tables, admin forms, and render partials yourself.
• The content need is moderate and stable — a handful of reusable block types for marketing or informational pages — and you have engineering capacity to vendor/fork the code and own it.
• You want a reference implementation to align stakeholders on what a block-based editor looks like before funding a larger build.
• MIT licensing and small surface area matter to you; the module is compact enough to audit and adapt.
• You can accept archived status: no upstream fixes, and compatibility with current Laravel/PHP versions is unverified until you test it.

Look elsewhere when:

• The project is greenfield or has a multi-year roadmap — do not make an archived 2020 module a load-bearing dependency.
• You need guaranteed upgrades, security response, or PHP 8+/modern Laravel support as a contractual expectation.
• Requirements include workflow, revisions, localization, multi-tenant content, or headless delivery — a maintained CMS (or a purpose-built content model) will cost less over the product's life than extending this.
• The team is not on Voyager and would be adopting Voyager in order to use this module; that inverts the cost/benefit.
• Design and page structure are tightly controlled by code and brand — you may not want an open block composer at all.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed module that gives editors a way to assemble pages from reusable content blocks inside our existing Laravel/Voyager admin, instead of shipping every copy change through engineering. The upside is speed and low acquisition cost — it is free and small. The constraint is ownership: the project is archived and hasn't been released since mid-2020, so nobody else is maintaining it. My recommendation is to treat it as a prototype or internal tooling accelerator, budget a short engineering spike to confirm it runs on our stack, and fork it if we keep it. It is not a candidate for a long-term platform dependency.

For engineering: Expect a compact module — block storage, Voyager BREAD screens, and a render path — that we would vendor into the repo rather than pull as a trusted dependency. We should validate current Laravel/PHP compatibility, review the migrations and any Blade output for escaping/security, and confirm how block ordering and per-page association are modeled before we build on it. If the spike passes, we own it; if not, we keep the data model as the spec and implement it ourselves.

Decision framing: adopt as a scoped, time-boxed accelerator for Voyager-based content pages, with an explicit owner and a documented exit path — not as a strategic CMS decision.