Nova Imagic Laravel Package

Product Decisions This Supports

• Feature delivery: Enables a complete media workflow inside Laravel Nova admin panels—upload, crop, transform, organize, reuse, and store images on local or cloud disks—without building custom media tooling.
• Roadmap acceleration: If your product’s admin UI is built on Nova and needs image management, this package can shorten delivery for per-user media libraries, nested folders, search, filters, sorting, pagination, rename/move, and guarded bulk deletion.
• Build vs buy: Strong candidate to adopt rather than custom-build. It covers S3/S3-compatible writes through Laravel Storage, random object names, originals/thumbnails, batch rollback, and owner-scoped authorization—areas that are costly and risky to maintain in-house.
• Use cases: Content management admin panels, e-commerce product image management, multi-image galleries, user-generated content with per-user upload scoping, and any Nova resource requiring crop-before-upload and reusable media selection.
• Security and privacy decisions: Supports private-by-default uploads, strict MIME/extension/byte-size/dimension/pixel-count/batch limits, authenticated and rate-limited owner-scoped media routes, and stable media:<uuid> references that resolve to authorized Nova previews without exposing private storage paths.
• Upgrade planning: v2.0.0 is a major release. PMs should account for php artisan migrate, a behavior change to private-by-default uploads, and the fact that legacy URL/path/JSON values remain readable but are not automatically imported into the media catalog. Adoption should be weighed against stack readiness for PHP 8.2+, Laravel 12, Nova 5, and Intervention Image 3.11+.

When to Consider This Package

• You are using Laravel Nova and need image upload/management fields beyond basic file inputs.
• You need a maintainable media library with cropping, folders, search, sorting, reuse, bulk actions, and S3-compatible storage.
• You want built-in security controls—owner-scoped routes, rate limiting, strict validation, private-by-default storage—rather than custom file-handling code.
• You can meet or plan for the supported baseline: PHP 8.2+, Laravel 12, Nova 5, Intervention Image 3.11+. The broader PHP 8.1+/Laravel 9–11/Nova 4–5 and Intervention Image 2.7 path exists only for EOL migration compatibility.
• You are prepared to run migrations and handle breaking changes, including private-by-default uploads and media:<uuid> references, and you do not require automatic import of legacy URL/path values into the catalog.
• Look elsewhere if: you are not using Nova; you need a framework-agnostic media library; you require advanced DAM features such as versioning, editorial workflows, or rich metadata; you cannot upgrade to a supported stack and cannot accept EOL security-advisory risk; or you need automatic legacy media import.

How to Pitch It (Stakeholders)

• Executives: Imagic 2.0 gives our Nova admin a complete, secure media workflow out of the box—upload, crop, organize, reuse, and cloud storage—reducing custom development effort and risk. It enforces per-user access, private-by-default storage, and strict validation. The trade-off is that v2 is a major release: migration is required, uploads become private by default, and legacy media is not auto-imported. We should adopt only if we can align with the supported stack—PHP 8.2+, Laravel 12, Nova 5—or explicitly accept the EOL transition path and its security-advisory risks.
• Engineering: Imagic 2.0 provides a responsive Nova media library with folders, search, sorting, bulk deletion, crop-before-upload, S3 writes through Laravel Storage, and batch rollback. Security includes strict MIME/size/dimension limits, authenticated rate-limited owner-scoped routes, and media:<uuid> references that resolve only for authorized previews. Before upgrading: run php artisan migrate; configure public visibility explicitly if needed; plan for legacy URL/path/JSON values remaining readable but not imported into the catalog; and prefer Intervention Image 3. Composer may refuse legacy dependency resolution due to active framework advisories—do not disable Composer security blocking in production; upgrade the application stack instead. The legacy CI override exists only to detect Imagic regressions.