Admin Ui Laravel Package

Technical Evaluation

Baseline note: This supersedes the provisional 2.3.1 baseline. The package has not yet been inspected directly (composer.json, README, view/lang structure), and 2.4.0 materially changes the risk profile — the earlier "additive only" characterization no longer holds.

Architecture fit: Unchanged in layer — still back-office/presentation for a Laravel app — but 2.4.0 reveals a second responsibility we had not accounted for: server-side image handling. The WYSIWYG upload path decodes images through Intervention, so the package's footprint now covers upload validation, storage, and image decoding, not just Blade rendering and translations. TPM implication: ownership of upload security (MIME validation, size limits, storage driver) and of the image-processing dependency now sits with whoever adopts this package, even though neither is visible in the admin UI.

Integration feasibility: Medium-low, down from High. 2.4.0 is not additive: it is a transitive major bump (intervention/image-laravel ^1.5.7 → ^4.1.1), a renamed container binding (image → intervention.image), a renamed/re-scoped config file with an ignored key (blendingColor → backgroundColor), and renamed static APIs. The release note's scoping ("Act only if your project uses Intervention directly") is optimistic: the dependency bump lands in the graph regardless, and Composer will force a resolution conflict for any application or third-party package pinning Intervention 2.x/3.x.

Technical risk: Medium-high for this release, with three distinct break surfaces:

1. Container binding rename — app('image'), @inject('image', 'image'), and any third-party package resolving image fail with BindingResolutionException. This is a runtime 500, not cosmetic.
2. Config semantics — a published config/image.php is still read as a fallback but blendingColor is now silently ignored. No error, just changed compositing behavior on transparent PNGs. Silent behavior changes are the worst category to debug post-deploy.
3. API renames — read() → decode()/decodePath()/decodeBinary(); gd()/imagick() → new ImageManager(Driver::class). Any app code, overridden vendor view, or package extension using the old surface fails fatally.

Structural risk also rises: a package that absorbs a three-major upstream jump into a minor version (2.3.1 → 2.4.0) is signalling that minor releases are not a safe auto-update channel for us.

Key questions:

• Does the package's service provider register intervention.image, or does that binding come from intervention/image-laravel? This determines whether the binding exists when the app has not installed the adapter itself.
• Do we, or any third-party package in our graph, pin intervention/image 2.x/3.x or resolve the image binding?
• Is config/image.php published in our apps, and does it set blendingColor? What is the visual delta on existing assets?
• Is the production image driver GD or Imagick, and is the corresponding extension present in every runtime image (web, queue, CI)?
• Does our PHP version satisfy Intervention Image 4's floor, and does that floor match our supported matrix?
• Do we have published vendor views overriding the WYSIWYG upload path? An override would pin the old read() call.
• Was 2.4.0 intended as a minor, and is the maintainer willing to flag dependency-major bumps in future changelogs?

Integration Approach

Stack fit: Laravel + Blade + lang loader, as before, plus GD or Imagick as a new hard runtime requirement and the intervention/image-laravel provider in the container. Nothing here conflicts with a standard Laravel app; the change is that adoption now includes an image-processing subsystem, not just views and translations.

Migration path: Treat this as a scheduled change, not a composer update.

1. Inventory first. Grep the codebase and vendor/ overrides for read(, ->gd(, ::imagick(, app('image'), 'image' in container resolution, blendingColor, config/image.php, and any published upload views.
2. Determine direct usage. Confirm whether we call Intervention ourselves. Either way the transitive bump is in scope; direct usage only changes the size of step 5.
3. Branch bump to ^2.4, run composer update, and resolve conflicts against app-level and third-party pins deliberately — never with --ignore-platform-reqs or a forced downgrade of the adapter.
4. Config migration. Publish config/intervention-image.php, port blendingColor to backgroundColor, and decide explicitly whether to keep the legacy config/image.php fallback or remove it.
5. Code migration. Replace binding resolutions and static/instance API calls per the upgrade actions.
6. Upload regression. Exercise the WYSIWYG path end to end: transparent PNG, JPEG, WebP, oversized file, corrupt file, non-image with an image extension, and a filename with non-ASCII characters.

Compatibility: The gate is no longer Laravel-major plus database engine (MariaDB 12.3 in CI is irrelevant to this release). It is now: PHP version against Intervention Image 4's floor, Laravel major against intervention-image-laravel ^4.1.1, and ext-gd/ext-imagick availability in every runtime image. Verify all three before bumping.

Sequencing: Inventory → branch bump and conflict resolution → config migration → code migration → upload regression suite → staging soak with real image assets → rollout on a normal deploy window, not a hotfix. Rollback plan: pin back to ^2.3, which retains the v1 adapter and the old binding; confirm the rollback path is exercised in staging, since config files may already have been moved.

Operational Impact

Maintenance: Rises from low to medium. We are no longer syncing translation keys; we are carrying an image-processing dependency through its majors, on a package that has demonstrated it will pull those majors in on a minor release. Add a per-release check of the package's composer.json diff to the update routine, and stop treating minor bumps as auto-eligible.

Support: Upstream hygiene still looks current (CI upkeep, Testbench harness, agent instruction files). The open question is release policy: request a changelog convention that explicitly calls out dependency-major bumps, and clarify whether 2.4.0 was a deliberate minor or a mislabelled major. Also confirm a security disclosure path exists — more relevant now that the package processes user-uploaded files.

Scaling: No longer zero-cost. Translation strings remain free; image decoding is CPU- and memory-bound and scales with upload volume rather than page views. Expect to size memory_limit and request body limits for the upload endpoints, and to consider moving thumbnailing off the request path if upload concurrency is meaningful. Large images under Intervention 4 are the likely first memory-exhaustion source.

Failure modes (severity has moved up):

• BindingResolutionException on image after upgrade — 500s on every path touching the binding.
• Fatal error on removed methods (read, gd, imagick) — 500s.
• Composer resolution failure on install or CI — deploy blocked outright.
• Missing ext-gd/ext-imagick in a container — fails only on first upload, so it escapes a smoke test that does not exercise uploads.
• Ignored blendingColor — silent, user-visible image quality/alpha regression, non-fatal.
• Missing translation keys or stale published lang files (the 2.3.1 risk) — still raw keys in the UI, still cosmetic.

Ramp-up: No longer sub-day. Estimate 1–2 engineer-days for an application that does not call Intervention directly (inventory, conflict resolution, upload regression, staging soak) and 2–5 engineer-days where it does. Requires someone comfortable debugging Composer dependency conflicts and image pipelines; that is a different skill profile from the Laravel admin work the previous assessment assumed.