marshmallow/advanced-nova-media-library
Advanced media library for Laravel Nova. Manage images and files through a polished Nova field, organize assets in folders, and attach reusable media to your Eloquent models with conversions and responsive images. Built for developers who need more than Nova's default file field.
Feature scope: media management inside Laravel Nova admin panels. This package is a UI layer, not a media engine. It connects two existing dependencies — Laravel Nova (paid admin panel) and Spatie's laravel-medialibrary (file-to-model associations) — and gives editors Nova fields to upload, attach, reorder, crop, and delete media without custom admin code.
Build vs. buy signal: buy the glue, not the platform. If your roadmap already commits to Nova + Spatie Media Library, this is a candidate to short-circuit 1–3 sprints of admin UI work (upload widgets, conversions, crop/resize controls, gallery ordering, per-model attachment management). If you are not on both dependencies, this package is irrelevant — it solves an integration problem you don't have.
Roadmap decisions it informs:
Concrete use cases: product/marketing image galleries with responsive conversions; document attachments on records; avatar/logo uploads with crop; multi-image galleries with drag-order in a CMS; any admin workflow where an operator curates files against an Eloquent model.
Adoption risk is itself a product input. Low visible adoption and a single-maintainer footprint mean the realistic PM framing is reference implementation or fork candidate, not a strategic dependency. Budget for owning the code.
New in 5.3.2 — the risk profile is now demonstrated, not theoretical. Release 5.3.1 shipped a regression that silently and permanently deleted existing media on save: a stale reference, a null, or an empty string submitted by the form caused handleMedia() to empty the model's media collection and commit the transaction. It destroyed a production product image and took a live homepage down within minutes of release. 5.3.2 restores fail-loud behavior — every submitted reference is validated up front, a ValidationException surfaces on the field, and the transaction rolls back with existing media intact. Product-level takeaways:
MM-25314) suggests the package is maintained by an organization that runs it in production. Mildly reassuring for responsiveness, but it also confirms the roadmap is driven by their needs — our edge cases still won't get priority.Consider it when all of the following hold:
Look elsewhere — or build it — when:
Verdict for most teams: still a tactical accelerator if the stack already matches, otherwise skip — but the bar for adopting it has moved. Adopt only on a pinned ≥5.3.2, with staging validation and a documented rollback, and treat the admin save path as production-critical. Do not let it enter the dependency graph as an unowned transitive risk.
For executives — one paragraph. This is a small open-source connector that lets our editors manage images and files directly inside the Laravel Nova admin panel, using the media library we already have. It can save roughly one to three sprints of admin-UI work on content-heavy features — galleries, attachments, crops — and costs nothing to license. The trade-off is maintenance: it has no meaningful user base, so we would own the code and its upgrades rather than rely on a vendor. A just-published patch fixed a serious defect in the prior version that could permanently delete images on save and took down one production site — a reminder that we must pin versions, test upgrades on staging with real data, and keep the integration isolated. Recommendation: pilot it behind one admin workflow on a pinned release, keep it replaceable, and expand only if it survives a Laravel/Nova upgrade cycle without incident.
For engineering — the ask. Spike: install exactly 5.3.2 or later against our current Nova + Spatie versions, wire one representative model (gallery with conversions and crop), and report (a) upgrade-path friction, (b) whether the field API covers our required conversions and validation, (c) LOC we would own if we fork, and (d) whether the 5.3.2 validation messaging is actually usable by editors. Two added requirements from this release: write a regression test covering null, empty-string, and stale-ID submissions asserting existing media survives and the save is rejected with a field-level error; and audit the package's other destructive paths (delete, reorder, crop-to-overwrite) for the same silent-success pattern — 5.3.1 failed because a destructive step ran before validation, and that ordering mistake can recur elsewhere. Pin exact versions, no floating constraints, and no auto-merge on dependency bots. Treat it as a reference implementation to vendor, not a Composer dependency we pin and forget. Exit criteria: if the spike exceeds ~3 days or requires patching core field behavior, we build the Nova fields in-house against Spatie directly — the integration surface is small, and the package's low adoption means our patches would never land upstream anyway.
Bottom line. Low cost to trial, meaningful schedule upside only if Nova + Spatie are already our stack; the maintenance burden is now quantified — one data-loss regression already shipped in a patch — so adopt pinned, isolated, and with validation tests, or build the small surface yourself.
How can I help you explore Laravel packages today?