mafftor/laravel-file-manager
A Laravel file manager package for browsing, uploading, and organizing files and folders within your application. It offers a practical way to add file management features to Laravel projects with minimal setup.
v2.0.12 is a dependency-compatibility release, not a feature release. The only change is that composer.json now accepts intervention/image ^2 or ^3 instead of ^2 only. That matters to you in one specific situation: you're on a modern Laravel (10/11+) app that already requires intervention/image ^3, and this package previously blocked your composer update. If you're happily on intervention/image 2, this release changes nothing for you functionally.
First steps:
composer require mafftor/laravel-file-manager (or composer update mafftor/laravel-file-manager if already installed).vendor:publish tag names in your version, as they've shifted between releases./file-manager) and confirm your configured disk is browsable, uploads land where you expect, and thumbnails render — that last one is the real smoke test for this release, since thumbnailing is what touches intervention/image.First realistic use case: point the package at your public disk, upload a handful of images, and verify that browsing, uploading, and thumbnail generation all work against whichever intervention/image major version Composer resolved for you. Do this before you build any application logic on top of it.
Treat it as a picker, not a CMS. The package's highest-value integration is as a file/image selection UI that hands a relative path back to your own form. Keep the actual file→model relationship in your application code ($model->update(['image' => $path])), and resolve URLs yourself via Storage::disk('public')->url($path). This keeps you free to swap the frontend later.
Disk configuration is the main lever. Most day-to-day shaping happens in the package config: which disks are exposed, root/base paths, and which file types are allowed. Define a dedicated disk (e.g. files) rather than exposing local wholesale, and scope per-tenant or per-user paths there if you need isolation — don't try to enforce multi-tenancy through the UI.
Protect the routes explicitly. The package registers its own routes. Wrap them in your auth/authorization middleware in the service provider or route config rather than relying on the UI being hidden. This is the single most common production mistake with file manager packages.
Embedding in Blade. The common pattern is mounting the file manager in a dedicated Blade view (or an iframe/modal inside your admin layout) and wiring a JS callback that writes the selected path into a hidden input in your form. Keep that glue in one Blade partial so upgrades to the package's frontend assets only touch one file.
Pair it with your own validation. Never trust the package's upload filtering as your only defense — validate extensions and sizes in the consuming controller too, and store uploads outside the webroot with a symlink only if you actually need direct serving.
New in this release — intervention/image 3 support. If Composer resolves intervention/image ^3 for you, you now get the v3 driver model (ImageManager, read(), driver chosen via the published intervention/image config) underneath the package's thumbnail path. If you deliberately want v2 semantics, pin intervention/image:^2 in your root composer.json — the package no longer forces the choice for you.
A widened constraint is not a tested code path. The release note says "support intervention/image 2 and higher," but the diff shown only touches composer.json. Widening a version constraint lets Composer install v3; it does not prove the package's thumbnail/resize code was exercised against v3's API (which dropped Image::make() in favour of ImageManager::read() and moved driver configuration into a config file). Upload a JPEG, a PNG, and a large file and confirm thumbnails actually generate before trusting it. If they fail, either pin intervention/image:^2 or patch the package and submit it upstream — this fork is small and community-maintained, so a PR is realistic.
Check your lockfile, not just the release note. After composer update, run composer show intervention/image and confirm which major you actually got. On a fresh Laravel 11 install it will be v3; on a legacy app it may still be v2. Your debugging strategy differs between them.
Republish assets on upgrade. Frontend assets in public/vendor/... are copied, not symlinked. After any version bump, republish and hard-refresh — stale JS against new backend responses produces confusing, silent failures.
Clear config cache when changing disks. php artisan config:cache will happily serve a stale disk list in production. If files "disappear" after a deploy, this is almost always why.
Symlink before you debug permissions. php artisan storage:link and correct storage/app/public ownership solve a disproportionate share of "upload succeeded but the file 404s" reports. Check the browser's network tab on the XHR — the response body usually names the failing path directly.
Watch the package's own logging. Route thumbnail and upload failures to storage/logs/laravel.log and confirm you're seeing them; swallowing exceptions in the file-manager controller makes intervention/image driver errors (missing GD/Imagick extension, unsupported format) look like UI bugs.
Pin the version. Given the small maintainer base and the fact that this release is a one-line composer change, pin mafftor/laravel-file-manager to 2.0.* rather than floating, and read the diff before each bump — as demonstrated here, the changelog is accurate but terse.
Debugging checklist, in order: config cached? → assets republished? → storage symlink present? → disk root writable? → which intervention/image major is installed and does its driver have GD or Imagick?
How can I help you explore Laravel packages today?