- How do I install and register the Filament File Explorer plugin in a Laravel app?
- Install it with Composer using composer require ardavan/filament-file-explorer, then register the plugin in your Filament panel provider. After that, publish the package config and assets as described in the documentation and confirm your storage disk and Media Library setup before opening the explorer page.
- Which Laravel, PHP, Filament, Livewire, and Spatie Media Library versions does it support?
- The package targets Filament v4 and v5 and is built on Spatie Media Library, Livewire, and Tailwind. The README badge and docs point at the current release, but exact PHP, Laravel, Livewire, and Media Library bounds should be confirmed against the composer.json constraints before you pin a version. Verify the full dependency matrix in a branch before upgrading an existing panel.
- Do I need Spatie Media Library, and does it browse all media records or a specific model?
- Yes, Spatie Media Library is a hard requirement because the explorer reads and writes media records rather than raw filesystem paths. It is not a general filesystem abstraction and will not replace Laravel's storage layer. Whether it browses every media record or needs a specific model and collection context is not fully spelled out in the README, so test it against your existing Media model.
- How are authorization, tenant scoping, and file-operation policies enforced?
- Filament panel access and policy checks govern the UI, but operations such as move, rename, and delete may bypass your application policies unless you wire them in explicitly. The package documentation includes an authorization guide, and tenant scoping needs to be validated against your own tenancy model. Treat policy enforcement as something you verify in a spike rather than assume.
- Does the file explorer work with S3 or other remote storage disks?
- The package works through Spatie Media Library, so disk support follows whatever your Media Library configuration allows, including S3 and other remote disks. Behavior specific to S3, such as path prefixes, signed URLs, and multi-tenant prefixes, is not documented in the README. Test uploads, browsing, and destructive actions on a staging bucket before relying on it.
- Will it respect Media Library conversions, responsive images, and custom path generators?
- Because media records are served through Media Library, conversions and responsive images should resolve through the same URLs your application already uses. Custom path generators depend on your Media Library configuration rather than on the explorer itself. Confirm thumbnails, conversions, and fallbacks render correctly for each collection in a test panel.
- Does installing the package publish migrations that could conflict with my existing media tables?
- Installation may publish config and migration files, so review anything published before running migrations against an existing media table. Do not let the package alter or conflict with tables your application already owns. Run the migrations first in a disposable database and diff the resulting schema.
- How does it perform with large media libraries, and does it support pagination, search, and bulk operations?
- The explorer, files table, and form picker are built on Livewire, which gives you paginated, searchable tables, but large-directory behavior is not benchmarked in the README. Seed a realistic volume of media and measure page load, search latency, and bulk actions. If you store tens of thousands of files, plan for indexes and consider scoping by collection or tenant.
- Are upload, delete, move, and rename actions auditable and recoverable?
- Upload, delete, move, and rename actions run through the package UI, and the README does not describe built-in audit logging or a trash and restore mechanism. For regulated or shared admin environments, add your own activity logging and a soft-delete or backup strategy around media records. Confirm what happens to orphaned media and on-disk files when a record is deleted.
- Is the package production-ready in terms of test coverage, CI, maintenance, and the Filament v5 upgrade path?
- Adoption is currently very low, with a single maintainer and no dependents, so treat it as a productivity accelerator for internal admin tooling rather than a core dependency. Test coverage, CI, and a documented upgrade path for Filament v5 should be checked on the repository before adopting. Pin the version, run a time-boxed proof of concept, and keep an exit plan if maintenance stalls.