Bootstrap Bundle Laravel Package

Product Decisions This Supports

• Cache invalidation strategy for legacy eZ/Ibexa + Laravel hybrid stacks. Release 1.6 adds a new cache purger and overwrites the existing ez cache purger service, which directly affects how content publish/update events propagate to HTTP caches. This is a decision point for teams still bridging eZ Platform content events into a Laravel application layer.
• Legacy migration sequencing. Overwriting the old ez cache purger service is effectively a deprecation-in-place. It gives you a supported path to move off the legacy purger without ripping out the surrounding service wiring — useful when planning the "get off eZ-era tooling" roadmap item in phases rather than as a big-bang rewrite.
• Build vs. buy for purge orchestration. If your team is hand-rolling cache purge listeners (content events → CDN/varnish/Redis invalidation), this package replaces that glue. Buying/inheriting is usually cheaper unless your purge logic is a genuine differentiator (e.g., fine-grained surrogate-key strategies).
• Roadmap input: staleness SLA and publishing latency. A dedicated purger makes cache-staleness an explicit, configurable concern rather than an emergent side effect, which supports committing to a content-freshness target in the product.
• Multi-site / multi-locale content operations. Purge behavior differs per site context; having a first-class purger is the hook for per-site invalidation policies, which is a common enterprise requirement in eZ-derived deployments.

When to Consider This Package

Consider it when:

• You run Laravel alongside eZ Platform / Ibexa (legacy) and need content changes to invalidate caches reliably.
• You are currently using the older ez cache purger service and want a maintained replacement rather than continuing to patch the old one.
• You need service-container-level swapping of purge behavior (the new purger is registered by overwriting the prior service — verify this matches your override conventions before adopting).
• Your team lacks appetite to own cache-purge plumbing and prefers a package-level dependency.

Look elsewhere when:

• You are on a modern Ibexa/Symfony stack with native cache and HTTP-cache components — you'd be adding a compatibility layer you don't need.
• You're on a pure Laravel stack; Laravel's cache tags, Redis, and a CDN integration cover this with less surface area.
• Your invalidation requirements are highly custom (surrogate keys, per-fragment edge rules) such that a generic purger adds a layer you'll fight.
• You require strict semantic-versioning guarantees across the 1.x line — 1.6 overrides an existing service, so treat minor releases as potentially behavior-changing until you've verified the container bindings and config in a staging environment.

Adoption criteria before committing: confirm what "overwrites" means concretely (service ID alias vs. hard replacement), check whether existing config keys for the old purger are still honored, and pin the version in composer.json until you've regression-tested purge behavior on publish, update, and delete events.

How to Pitch It (Stakeholders)

For executives: A small, low-cost dependency upgrade that closes a known gap in how content changes propagate to caches. Version 1.6 replaces an aging cache-purge component with a maintained one, reducing the risk of stale content and shrinking the custom code we'd otherwise own. It's a supporting step in the broader effort to modernize our legacy content-platform integration — not a strategic bet, but a cheap removal of technical debt with a clear rollback path.

For engineering: Release 1.6 introduces a new cache purger and overwrites the existing ez cache purger service. Treat this as a behavioral change despite the minor version bump: audit the service container for anything binding or extending the old purger, confirm config compatibility, and add regression coverage for publish/update/delete purge paths before rollout. The upside is that the migration off the legacy purger becomes a wiring change rather than a rewrite — which is the outcome we want, provided we validate the override semantics first.