Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Advanced Nova Media Library Laravel Package

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.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

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:

  • Whether "self-serve media editing by non-technical staff" ships this quarter or gets deferred behind custom Filament/Inertia admin work.
  • Whether media handling becomes a platform capability (shared field types, conversion presets, CDN pipeline) or stays a per-feature implementation.
  • Whether to standardize on Nova as the back-office surface for content-heavy products (catalog, CMS, listings, real estate, editorial).

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:

  • Availability exposure, not just a bug. Media deletion is a customer-facing outage vector for content-driven pages. Any adoption plan must treat the admin save path as a production-critical surface.
  • Silent success is the danger pattern. Before 5.3.1 the same inputs threw a 500 and rolled back — annoying but lossless. The regression came from "improving" that to skip bad entries. When evaluating this or any admin field package, prefer loud failure over graceful degradation on destructive operations.
  • Patch releases are not inherently safe. A P1 data-loss bug shipped in a patch version. Version pinning and staged rollout are now mandatory controls, not hygiene nice-to-haves.
  • Maintainer signal, upgraded slightly. The fix shipped quickly with a clear postmortem and a verification matrix, and the tracker ID (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.

When to Consider This Package

Consider it when all of the following hold:

  • You are already running Laravel Nova (the license cost is sunk) and Spatie Laravel Media Library is already your media abstraction.
  • You need editor-facing media CRUD — upload, crop, reorder, delete, conversions — and would otherwise build those Nova fields in-house.
  • Your team is comfortable vendoring or forking a small package and carrying maintenance; you treat it as source you own, not a vendor you depend on.
  • You will pin an exact version (≥5.3.2), roll upgrades through staging against a copy of production data, and can accept that a bad patch could take a content page down.
  • The feature is internal-tooling grade: an admin panel used by tens of staff, not a customer-facing SLA surface — with the caveat that the content it manages may still be customer-facing.
  • You can absorb a breaking change on a Laravel/Nova major upgrade with in-house PHP capacity.

Look elsewhere — or build it — when:

  • You are not on Nova. Nova is closed-source and paid; this package is dead weight on Filament, Livewire, Inertia, or headless setups. Evaluate Filament's Spatie media plugins or Spatie's own Media Library Pro instead.
  • You need vendor support, SLAs, or a security-response commitment. You are the first adopter of every edge case, and the 5.3.1 incident shows the blast radius of that position.
  • You cannot tolerate a single silent data-loss path. If media is unrecoverable business record (regulatory, audited, or non-reproducible assets), build the fields in-house against Spatie directly, where failure semantics are yours to define.
  • Your media needs are heavy: video transcoding, DAM-style tagging/search, signed-URL delivery at scale, multi-tenant isolation, or audited retention. This is a field-type package; those are platform problems.
  • You want a maintained upstream. Prefer Spatie's first-party paid media UI, or a package with meaningful adoption and recent issue activity, before a low-adoption dependency.
  • Your team is JS/frontend-leaning and would rather own a small custom Vue/Inertia admin surface than debug third-party Nova field internals.

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.

How to Pitch It (Stakeholders)

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.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
adachsoft/changelog-linter
adachsoft/collection
payerurl/telegrambot-crypto-payment-instant-payout
dskripchenko/laravel-hybrid-search
riorizkyrainey/lara-ced
mehedimi/static-vel
zharp/zharp
nonsapiens/bigquery-model-sync
lgu-bayambang-ict-office/lgu-laravel-development-standards
andydefer/laravel-support
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel
draftsmaninc/draftsman
square-bit/laravel-volition
himito/laravel-mailman
htinlynn/genius-helper
maco-studios/hephaestus
elmogy/larafast