Laravel Sabhero Wrapper Laravel Package

Product Decisions This Supports

Feature / integration scoping

• This package is a thin Laravel wrapper around SabHero — the kind of dependency that decides how page-level content and imagery metadata gets into your app, not what your product does. Treat it as plumbing, not a differentiator.
• The v2.1.0 rename of feature_image → page_feature_image (code and database schema) confirms the vendor is still normalizing its domain model. That is a roadmap input: assume at least one more schema-level rename before the API settles.

Build vs. buy

• The wrapper's surface area is small (one resource concept: pages, their feature imagery, and associated references). A 100–200 line internal client is a credible alternative if you only need read access plus one write path.
• Buying (adopting) wins if you need the full SabHero schema and don't want to track upstream field changes yourself. This release shows the flip side of that trade: upstream field changes arrive whether you want them or not.

Release / migration planning

• v2.1.0 is versioned as a minor bump but ships a breaking attribute and column rename. That is a semver violation and should be logged as a vendor-discipline data point.
• Any product work touching stored page imagery must be sequenced after a column rename migration. If your own schema or API payloads mirror feature_image, budget a coordinated rename, not a composer update.
• The README badge removal and Dependabot actions/checkout bump are hygiene only — no product impact.

Risk / exit-cost modeling

• Because the coupling is shallow, switching cost is low today. Keep it that way: isolate the wrapper behind your own repository or DTO so a future rename or a move to a direct HTTP client is a one-file change.

When to Consider This Package

Adopt when:

• You're on a supported Laravel version and already committed to SabHero as the source of truth for page-level content/metadata.
• You want the schema kept in sync for you rather than hand-maintaining an API client against a moving target.
• Your team can absorb a coordinated rename roughly once per minor release, and you have CI that catches attribute-level breaks.
• Your usage is read-heavy or single-write-path (page records + feature imagery), not deep custom queries against the vendor's tables.

Look elsewhere / defer when:

• You need a stable public contract with predictable semver. Minor releases containing breaking renames mean you must pin exact versions and read every changelog.
• You store feature_image in your own tables, exports, search indexes, or analytics events — the rename becomes a multi-system migration, and this release notes don't state whether a rename migration ships with the package.
• You need multi-tenant overrides, custom indexes, or query patterns the wrapper doesn't expose — at that point you're fighting the abstraction and a direct client is cheaper.
• You lack the capacity to test and deploy a schema rename mid-sprint. Pin to 2.0.x until you have a window.
• The SabHero dependency is incidental (e.g., you only need a static image URL) — don't take a schema-coupled dependency for a URL builder.

Immediate recommendation for current users: pin to ^2.0.0 with an explicit upper bound below 2.1, verify whether a column-rename migration is included, run it against a staging copy of production data, and only then lift the pin.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost integration library that connects our Laravel app to SabHero for page content and imagery metadata. It is not a strategic asset and not a material cost line — but it does carry ongoing maintenance tax. The newest release (v2.1.0) is technically a minor version that contains a breaking field rename, which means upgrading requires a database column change on our side. Recommendation: don't upgrade this sprint. Pin the current version, schedule the rename as a small planned task, and continue. No customer-facing impact, no architectural decision required.

To engineering leads: v2.1.0 bumps actions/checkout to v5 (CI only) and renames feature_image to page_feature_image across code and schema, plus README cleanup. The rename is the only thing that matters. Action items: (1) confirm whether the release includes the column migration and the rollback path; (2) grep for feature_image in app code, API resources, factories, seeders, and any serialized payloads before upgrading; (3) hold the pin at 2.0.x until the migration is rehearsed on a production-shaped dataset; (4) keep the wrapper behind our own repository interface so the next rename is contained.

To product: No feature or timeline impact unless an in-flight story touches page imagery storage or an API contract that exposes feature_image. If it does, flag it now — the field name is changing and any client consuming it will need coordination.