Admin Ui Laravel Package

Product Decisions This Supports

• Upgrade planning and maintenance budget. 2.4.0 is the first breaking release in this line: it requires Intervention Image 4, renames public API methods (read() → decode() / decodePath() / decodeBinary(), gd() / imagick() → new ImageManager(Driver::class)), renames the container binding (image → intervention.image), and moves published config from config/image.php to config/intervention-image.php. This converts a "pull it in on the normal cadence" dependency into a scheduled migration ticket with QA on image flows — a real, estimable line item for internal tooling.
• Ownership of the media pipeline. The release notes reference WYSIWYG upload decoding, which clarifies scope the prior assessment understated: this package is not only admin button chrome, it also sits on the image-upload path for content authoring. That is a product-surface decision input — whether we own media handling in-house or delegate it to this dependency, and how much of our content-authoring reliability is contingent on its release cadence.
• Security and attack-surface currency. Image upload and decoding is a hostile-input path. Being pinned to Intervention Image 4 (intervention/image-laravel ^4.1.1, up from ^1.5.7) means we stay on a supported major for that decoder rather than drifting onto an unmaintained one. This supports the "keep or replace" question with a concrete answer: the package is actively tracking its upstream, which argues for keeping it.
• Silent behavior change to watch. blendingColor is now ignored in favour of backgroundColor on the Intervention-side config. If any admin-generated imagery relies on blending (logos on transparent backgrounds, thumbnail compositing), output can change visually without an error. That is a QA scope decision, not just an engineering one.
• Localization roadmap (unchanged, still valid). The 2.3.1 translation-key surface (admin.btn.show, admin.btn.back) remains the reason to adopt for multi-language admin; nothing in 2.4.0 touches it.
• Correcting the prior call: last cycle we recorded "no breaking change, no action required." 2.4.0 supersedes that. Any roadmap item that assumed a frictionless patch cadence for this dependency should be revisited.

When to Consider This Package

Consider it when:

• You are building a Laravel admin/back-office surface and want the detail/back navigation controls and their translations provided rather than written per resource.
• You need the admin UI to be translatable, with those strings maintained in a package rather than scattered across your own lang files.
• You want a package that keeps pace with its own upstreams — jumping a major version of intervention/image-laravel in a single release is evidence of maintenance, and CI against MariaDB 12.3 plus a shipped testbench.yaml means you can validate upgrades in your own pipeline.
• Your team uses AI coding agents on the repo — the shipped AGENTS.md / CLAUDE.md lowers the cost of agent-assisted contribution.

Look elsewhere or defer when:

• You use Intervention Image directly. This is now the gating criterion. Custom thumbnail generation, watermarks, format conversion, or any ImageManager usage in your own code means you own the migration: method renames, driver construction, and the binding rename. Budget it as a scheduled change, not a patch bump.
• You resolve the image container binding anywhere. The rename to intervention.image is the kind of break that fails at runtime on a specific screen rather than at boot. Grep before you upgrade.
• You have a published config/image.php. It is still read as a fallback, so the upgrade will appear to work while blendingColor is silently ignored — check whether that key matters to your output before declaring victory.
• Your admin layer is already opinionated (full admin framework, design system with its own controls, or a JS-driven SPA admin) — package-provided buttons create two sources of truth.
• You are not localizing the admin, in which case the headline value of the 2.3.x line remains zero for you and 2.4.0 is pure migration cost.
• Your database target is outside the tested matrix. MariaDB 12.3 in CI is a signal, not a support guarantee.

How to Pitch It (Stakeholders)

For executives (one line): This release is a required dependency upgrade with a contained but real migration cost — it moves us onto a supported image-processing library and modernizes the package's plumbing; there are no new customer-facing features, no pricing or roadmap impact, and the work is limited to teams that manipulate images directly.

For engineering: 2.4.0 is breaking by dependency, not by design. It bumps intervention/image-laravel from ^1.5.7 to ^4.1.1. Required changes if we touch Intervention directly: ImageManager::read() → decode() / decodePath() / decodeBinary(); gd() / imagick() → new ImageManager(Driver::class); inject ImageManager / ImageManagerInterface rather than resolving the image binding, which is now intervention.image; move any published config to config/intervention-image.php and translate blendingColor to backgroundColor, noting the old key is read but ignored. The package's own WYSIWYG upload path already uses decodePath(), so that leg is handled for us. Recommended sequencing: grep for the image binding and for ImageManager usage in our code, upgrade in a branch, then run visual QA on any generated imagery — especially anything compositing onto transparent backgrounds — before rollout. Treat as a normal-cadence upgrade with a checklist, not a hotfix.