Basic Blocks Laravel Package

Product Decisions This Supports

• Who owns the category page. v1.6.0 ships two blocks — a category banner (58103ae) and a category description (62f94af) — which move the two most visible elements of a category page out of Blade templates and into structured, editable data. Category pages are typically high-traffic and low-investment, making them the cheapest surface on which to test a real operating question: does merchandising own category presentation, or does it remain an engineering artifact? A pilot answers that with evidence instead of opinion.
• Build vs. buy for content tooling. The realistic alternative is a bespoke category-fields build with its own admin screen and permanent upkeep. This package is explicitly a basic block library layered onto an editor that already exists, so the honest comparison is "extend a third-party block set behind a thin internal layer" against "own a custom build forever." Buying in means inheriting future block types rather than owning a one-off.
• Roadmap sequencing input. Two additive, narrowly scoped blocks in a single release is a directional signal that the maintainer is working outward from category surfaces — banner and description today, plausibly listing and PDP blocks later. Useful as an input to a content roadmap conversation; not sufficient as a commitment. One release note is a datapoint, not a plan.
• Delivery shaping and estimation. Blocks convert content modelling from development work into configuration work. That rewrites estimates, handover risk, and staffing for a theme refresh — a build task becomes an enablement and training task, and the recurring "change the banner on category X" ticket stream shrinks.
• Experimentation velocity. Because block content is data rather than template, a category hero can be swapped, tested, or rolled back without a deploy — provided cache invalidation on block save is handled. That is the quiet failure mode that erases the benefit and produces "the site is broken" reports.
• Use cases to validate first: seasonal and promo banners on top-traffic categories; SEO-relevant descriptions authored by content teams without engineering; multi-store/marketplace setups where category presentation differs by channel; A/B tests on hero treatment.
• Decisions this does not support. A block library is not a CMS. Do not let a successful pilot be argued upward into "we now have a page builder." Scheduling, editorial approvals, localisation governance, and asset management are out of scope and will be re-litigated later if that boundary isn't stated now.

When to Consider This Package

Adopt when:

• You are on Bagisto (or a directly compatible Laravel storefront) and category hero/description content currently lives in templates rather than in content-managed fields.
• Merchandising is blocked on engineering for routine category changes — the tell is a recurring backlog of "update the banner on category X" tickets.
• You want a structured block model rather than free-form HTML fields, because blocks are portable, testable, and survive theme changes.
• You can name an internal owner for the render path and pin the version. A third-party package in the critical path of high-traffic pages with no owner is the most common way this class of dependency goes stale.
• You can ship a fallback to the existing category image and description fields, so untouched categories keep rendering throughout the rollout.

Look elsewhere when:

• You need a full page builder, layout composition, scheduling, or editorial approvals. The gap widens as content operations mature and you will re-platform within a year or two.
• You require headless/API-first delivery, multi-locale content governance, or DAM capability beyond what the host platform already offers.
• You are not on Bagisto. The value is tightly coupled to that ecosystem and integration cost will exceed the benefit.
• You cannot tolerate an unpinned third-party dependency in the critical rendering path. Block libraries get extended per theme, and that is exactly where upgrade friction accumulates.
• Category content already lives in a mature CMS or PIM. Adopting this creates a second source of truth and an unbudgeted reconciliation problem.

Evidence caveats to weigh before committing. Zero dependents, negligible stars, and an evaluation derived from a single release note covering two additive features. There is no changelog history, no visible adoption base, and no documented test coverage. Treat the strategic read as directional, not predictive, and gate any roadmap dependency on a short maintainer-health review: release cadence, issue responsiveness, supported Laravel/PHP versions, license and security posture, and whether the new blocks ship default views you would have to override.

How to Pitch It (Stakeholders)

For executives: A small, additive release to our block-content package adds two category-page building blocks — a banner and a description. No breaking changes are indicated and the scope is deliberately narrow, but the direction matters: it lets marketing publish category-page content without an engineering ticket, which is typically one of the cheapest conversion and SEO levers on a storefront. The package itself is immature — no meaningful adoption signal and a single-release evidence base — so the recommendation is a scoped pilot on 3–5 high-traffic categories over one campaign cycle, measured against engagement and organic landing performance, before we widen adoption or commit budget. Ask: approve the pilot plus a bounded maintainer-health review; defer the rollout decision until both are in hand.

For engineering: This is a thin, Laravel-native block library, not a framework. Value to us is that block types are data and render through Blade partials we can override under a namespace, so our customisation layer stays upgradeable. Risks we own: no test suite, no CI signal, unverified multi-store scoping on block records, and no documented BC history. Mitigations are cheap and non-negotiable — pin to 1.6.0, confirm the service provider's registration and publish behaviour before install, read the category-banner resolution method to confirm the association and store scoping, render every block through a fallback to the native category image/description, cache per category-store and flush on save, and keep a written inventory of every published view path as the upgrade checklist. Budget the regression tests ourselves: one feature test covering a category with a block, without one, and with the block disabled, run before and after each upgrade. Extension points ranked by safety: register new block types (safest), override published views (safe with the inventory), extend the registry class (fragile), patch the vendor file (never). Worst case we maintain a fork — decide now whether that is acceptable.