Product Decisions This Supports
- PHP 8 modernization / platform upgrade planning: 2.1.0 makes PHP 8.0 the floor, so this package is no longer a blocker in a PHP 7 → 8 migration — but it is a forcing function for any service still on 7.x. Add it to the dependency-inventory checklist for the platform upgrade and sequence it accordingly.
- Runtime/version support policy for our own apps: the release explicitly tests PHP 8.0, 8.2, 8.3, 8.4, and 8.5. That gives us a defensible statement of "supported PHP versions" for any feature that generates or signs Thumbor URLs, and lets us keep our own CI matrix aligned rather than guessing.
- Build vs. buy for image delivery: this is a thin client for Thumbor (URL construction + signing), not an image pipeline. The decision it informs is not "build a Thumbor client" — it's "do we run Thumbor as our image service, and do we consume it via this client or hand-roll URL signing?" Given the URL-signing surface is small and well-understood, re-evaluating this package should be tied to a broader review of whether we stay on self-hosted Thumbor versus a managed image CDN.
- Maintenance-health input to dependency risk register: sustained CI coverage across five PHP minors, refreshed static analysis (PHPStan, Rector, CS Fixer, PHPUnit), and an outside contributor (@lostfocus) are positive maintenance signals. Useful evidence when arguing to keep vs. replace a dependency at architecture review.
- Use cases it unlocks/enables: on-the-fly resizing, cropping, and signed URL generation for user-generated content, responsive
srcset pipelines, and private/paid image assets where signed URLs prevent hotlinking. Relevant to any roadmap item involving media, thumbnails, or per-tenant image access control.
- Roadmap timing: because 2.1.0 contains a breaking change (PHP 7 support dropped) with no announced API changes, this is the right moment to schedule the upgrade before we accumulate more call sites — cost is low now, and it avoids being pinned to an unmaintained 2.0.x line.
When to Consider This Package
Adopt when:
- We already run (or plan to run) a Thumbor server or a Thumbor-compatible endpoint; this package saves us from re-implementing HMAC URL signing and parameter encoding.
- The application is on PHP 8.0+. Below that, 2.1.0 is simply unavailable — stay on 2.0.x only as a short, tracked exception.
- We need a small, framework-native integration rather than a full media-management platform; the value is convenience and correctness of signing, not features.
- We want the signing logic to be a maintained dependency with active CI rather than bespoke code only one engineer understands.
Look elsewhere when:
- We are standardized on a managed image CDN (Cloudinary, imgix, Imgix-style services, Cloudflare Images) — their SDKs supersede this, and adding Thumbor means running infrastructure we don't want.
- We need transformation execution in-process (no external service): this is a client only, so it does not solve image processing on its own.
- The requirement is broader media management — uploads, storage abstraction, variant generation queues, admin UI. Reach for a fuller media package (e.g. a Laravel media-library solution) and treat Thumbor as one delivery backend.
- We are pinned to PHP 7.x with no upgrade path this cycle, or our Laravel/PHP constraint set conflicts with the 8.0 floor.
Release-specific caveat: treat 2.1.0 as a breaking upgrade on the PHP dimension. Verify our PHP version matrix, CI images, and any Docker base images before bumping; there's no indication of public API changes, so the code-level risk is low, but the platform-level gate is real.
How to Pitch It (Stakeholders)
For executives: This is a small, low-cost dependency that handles the fiddly part of serving images — generating secure, signed URLs for our image service — so our engineers don't maintain that logic themselves. The new 2.1.0 release is a maintenance release with one breaking change: it now requires PHP 8.0 or newer. That aligns the package with where our platform is already heading, and it signals the project is actively maintained and tested against current PHP versions (through 8.5). Recommendation: include it in the current PHP upgrade workstream rather than treating it as a separate initiative — near-zero engineering cost now, and it avoids us being stuck on an unmaintained older version later.
For engineering: 2.1.0 drops PHP 7.x and requires 8.0+, adds CI coverage for 8.0/8.2/8.3/8.4/8.5, and modernizes the codebase with PHP 8 type declarations plus refreshed PHPStan, Rector, CS Fixer, and PHPUnit configuration. No public API changes are called out. Action: confirm our PHP floor and CI matrix, bump the constraint, and run the suite — expect a clean upgrade on PHP 8 apps; PHP 7 services need a sequenced migration or must stay pinned to 2.0.x with a tracked follow-up.