- What is Imagic for Laravel Nova used for?
- Imagic adds a media-aware image field to Laravel Nova for uploads, cropping, resizing, library selection, folder organization, reuse, and guarded deletion. Managed uploads are stored through Laravel Storage and referenced as media:<uuid> values, so Nova previews do not expose disk or bucket paths. It is best suited to admin workflows that need reusable, owner-scoped image assets instead of a basic file input.
- How do I install ayvazyan10/imagic in a Laravel Nova application?
- Install it with Composer using composer require ayvazyan10/imagic alongside the supported baseline: PHP 8.2+, Laravel 12, Nova 5, and preferably Intervention Image 3.11+. After the Composer update, run php artisan migrate to create the media catalog table. Then configure your storage disks and choose which fields need public visibility versus private owner-authorized previews.
- Does Imagic 2.0 require Laravel 12, Nova 5, and PHP 8.2?
- Imagic 2.0 targets PHP 8.2+, Laravel 12, and Nova 5, with Intervention Image 3.11+ recommended for transformations. Intervention Image 2.7 is documented only as a transition path for EOL migration compatibility. Older PHP 7 support has been removed, so legacy stacks should be upgraded rather than pinned.
- Should I use Imagic on Laravel 9 to 11 or Nova 4, or choose an alternative?
- Laravel 9–11, Nova 4, PHP 8.1, and Intervention Image 2.7 appear only as EOL migration compatibility, not as supported production targets. Composer may also refuse legacy dependency resolution because active framework advisories have no patched release on those lines. Bypassing Composer security blocking in production is not an acceptable operational risk.
- How does Imagic handle S3 storage and local disks?
- Imagic uses Laravel Storage, so it can write to local disks or S3/S3-compatible storage. Managed uploads use random object names and original/thumbnail variants, with batch rollback available for production operations. Before using cloud storage, verify credentials, bucket policies, CORS, private-by-default access, and object lifecycle rules.
- What is a media:<uuid> reference in Imagic and what happens to legacy values?
- A media:<uuid> reference is the persisted field value for a managed upload; it points into the media catalog instead of a raw storage path or public URL. This decouples Nova field values from bucket and disk paths. Legacy URL/path and JSON values remain readable, but they are not automatically imported into the media catalog.
- Why are new Imagic uploads private by default and how do I make them public?
- Imagic 2.0 makes new uploads private by default, so existing assumptions about public image URLs may break. Apply package configuration deliberately or use ->visibility('public') on fields that must expose public URLs. Keep private owner-authorized previews for media that should not be publicly reachable.
- How do I migrate existing Nova image fields to Imagic 2.0?
- Start with an inventory of every Nova image field, including its persistence format, visibility expectation, and storage disk, then back up the database and affected disks. Run the catalog migration and decide per field whether to re-upload, backfill, or accept mixed-mode behavior. Legacy values may render but will not appear as managed library assets unless you import them.
- How do I test Imagic uploads and owner-scoped media routes?
- Test Composer installation against your real PHP, Laravel, Nova, and Intervention Image versions, and cover upload, crop, library selection, and deletion flows in Nova. Because Imagic adds owner-scoped authenticated routes, verify authorization, tenancy boundaries, rate limiting, and private preview behavior in the host application. Use Storage::fake for local tests and a dedicated S3 test bucket when validating cloud writes.
- What should I verify before rolling Imagic 2.0 into production?
- Before production rollout, confirm the catalog migration, S3 write path, Nova field behavior, public/private visibility, owner-scoped routes, and rate limits in a staging environment. Have a rollback plan in case the catalog migration or upload path fails, and note that existing legacy values may require a separate backfill. Treat Imagic 2.0 as a modern-stack package, not a drop-in for legacy Nova applications.