Intervention Request Laravel Package

Product Decisions This Supports

• Build vs. buy for image delivery. Rather than commissioning a bespoke resize/crop pipeline, this package gives a ready-made, URL-parameter-driven image service you deploy as a container. v7 strengthens that "assemble, don't build" position by shipping a production-grade worker-mode runtime (FrankenPHP + Caddy) alongside the classic PHP + Nginx + cron flavor.
• Roadmap input for media features. v7's hotspot processor now accepts an optional normalized initial cropping area — d{x}:{y}:{areaStartX}:{areaStartY}:{areaEndX}:{areaEndY} — so "focus on this point, then crop to this region for this aspect ratio" becomes configuration rather than custom code or manual re-exports. This directly unlocks per-channel crop presets, responsive art direction, and CMS-side focal point tooling.
• Operational cost and latency decisions. InterventionRequest is now stateless and handleRequest returns a Response, enabling worker mode: one long-lived process serving many requests. For a PM this is a lever on origin cost, cold-start latency, and container count — with the FrankenPHP flavor trading a separate Nginx and cron for a single runtime.
• Migration as a planned deliverable. v7.0.0 is breaking on two axes (API removal and container path change). A PM decision is required on (a) pinning a tag rather than latest, and (b) scheduling the code change $app->handleRequest($request)->send() and the /var/www/html/web → /app/public volume and env-var migration. Treating this as a backlog item prevents it surfacing during an unrelated release.
• Reliability/perception risk burn-down. The crop fix (works without width or height, falling back to original dimensions) removes a class of bugs where partial crop parameters produced failed or unexpected images — fewer support tickets against the media feature.
• Backwards compatibility as a rollout de-risker. Existing x/y-only hotspots behave as if the crop area were the whole image (0:0:1:1), so crop presets can ship incrementally without invalidating existing asset URLs.

When to Consider This Package

Adopt when:

• You need on-demand resizing, cropping, and variant generation for editor- or user-supplied images and don't want to rebuild that pipeline per product or per project.
• You want a containerized image service in front of object storage (source images read-only, cache volume writable) running alongside a Laravel/PHP application or as a standalone origin behind a CDN.
• Your roadmap includes art direction, focal-point cropping, or responsive variants derived from URL parameters rather than pre-generated asset sets.
• Your platform can run PHP 8.4 and adopt the v7 layout (/app/public, IR_IMAGES_PATH, IR_CACHE_PATH).
• Throughput matters: the stateless handler plus the frankenphp-7.0.x image is a good fit for higher-traffic origins — but note the FrankenPHP flavor has no cron, so scheduled cache cleanup must be owned elsewhere.

Look elsewhere when:

• You only need a handful of static derivatives — a build-time step or your CDN's built-in transforms will be cheaper to operate than a dedicated service.
• You cannot absorb a breaking upgrade in the near term and don't want to own a pinned 6.x image indefinitely.
• You require vendor-managed SLAs, autoscaling guarantees, or a fully hosted image CDN — this is self-operated infrastructure with your own on-call.
• Your team doesn't own container, volume, and cache lifecycle operations, or you need a full digital asset management UI rather than URL-based transforms.
• You need ML-driven cropping (face/subject detection) as a requirement — hotspot coordinates are manually specified, normalized values.

Adoption checklist: pin an explicit tag (7.0.1, not latest); migrate volumes and env vars to /app/public; update application code to the single-call handleRequest(...)->send() form; confirm a cache invalidation and cleanup story for whichever image flavor you choose.

How to Pitch It (Stakeholders)

Executives. "This is a maintenance upgrade we should schedule, not skip. v7 makes our image service cheaper and simpler to run — a worker-mode container with fewer moving parts — and gives marketing a new capability: defining crop regions so one source image works across banner, square, and portrait placements without manual re-exports. The cost is a one-time migration: a container path change and a two-line code change. We'll pin to 7.0.1 rather than latest so no future upgrade lands unplanned."

Engineering. "Breaking: getResponse is removed; handleRequest now returns a Response and the handler is stateless, so it's safe in worker mode. The Docker root moved from /var/www/html/web to /app/public — update IR_IMAGES_PATH, IR_CACHE_PATH, and volume mounts. Pick the PHP + Nginx image if you rely on cron for cache cleanup; pick frankenphp-7.0.x for worker-mode throughput with Caddy, which needs /data and /config volumes and has no cron. Base image is PHP 8.4. Also included: hotspot accepts an optional normalized initial crop area, and crop no longer requires width or height."

Product and Design. "Hotspot now takes an optional crop window — normalized coordinates from 0 to 1 — so 'focus here, then cut to this ratio' is a setting, not a design ticket. Existing hotspots keep working unchanged. That means we can ship per-channel crop presets in the CMS without a backend story."