UniSharp laravel-filemanager: two storage roots, three ways in, and a badge frozen at 2.6.4

Two roots on disk behind one browser

A Laravel application that already writes uploads through its filesystem still needs a way for a person to browse them, and that gap is what this package fills. Nothing inside it introduces a second storage abstraction: the gallery is a view over the same objects an editor embeds and a public URL serves. The browsing interface is split into two categories, files and images, and the feature list is explicit that each type works in a different directory, which fixes two roots on disk and makes every path in the interface relative to one of them.

Multi-user mode adds a second axis on top of those roots. Shared folders are open to all users, who can upload and manage files in them. Private folders are a dedicated directory per user, where only the owner can upload or manage. Uploading validation, cropping and resizing of images, and selection of several files at once sit alongside that, and the interface is described as responsive and entirely customizable.

Localisation is the widest part of the feature list. Thirty locales ship in the tree, running from ar and az through pt-BR to zh-CN and zh-TW, so an interface in any of those languages is not something you have to patch in yourself.

The people this fits are Laravel teams shipping anything editor-driven: a back office, a CMS section, a help desk. What it removes is the controller and view work that a file browser normally costs, and what it does not remove is the part where you decide who is allowed to touch a given folder.

Three doors into the same gallery

Reaching the gallery is a choice of three, and the choice matters more than the size of the feature list. The package offers WYSIWYG editor integration for CKEditor, TinyMCE and Summernote, a standalone upload button, and an iframe. Editor integration puts the picker inside a text field somebody is already typing in. The standalone button is for forms that need one file or image next to a label and nothing more. The iframe is the option when the host page cannot carry the picker markup, a legacy view or a different system entirely.

Underneath all three, routes, middlewares, views and the folder path are all configurable. That last group is where the real decisions live. Routes decide where the gallery is mounted in the application, and views decide what it looks like without forking. Middlewares decide who gets in, because access control is delegated to whatever the host application attaches to the route rather than described inside the package.

The documentation site mirrors that structure with separate pages for Integration, Config, Customization and Events. An Events page is the only sign in the README of a hook for behaviour after an upload, and nothing about those events is written down in the file itself.

Where the install lives, and what the README skips

There is no composer command in the README, and any article that printed one would be inventing it. The badge row does give you the pointer that matters: the latest stable version badge and the monthly download badge both resolve to packagist.org/packages/unisharp/laravel-filemanager, so that page is where the current version and its requirements are stated. The second pointer is the documentation site, whose link row names an Installation page at unisharp.github.io/laravel-filemanager/installation, then Integration, Config, Customization, Events and Upgrade in that order.

So a first run reads like this: open the Packagist page, open the Installation page on the docs site, pull the package, publish whatever the package ships for configuration, and treat the README as a feature summary rather than a setup guide. The documentation site is the setup guide and the README points at it.

What the checkout itself shows is a top level with composer.json, a config/ directory, a src/ directory, a public/ directory, resources/ and tests/. A publishable configuration file exists in the package. The README names no config key at all, so anything key-level, including how the two roots are pointed at your disk, comes from the Config page or from the config file inside the package rather than from the README.

One Makefile target and three CI entry points

The only automation in the repository is a single Makefile target named test, and it does two things in order: coverage output from PHPUnit, then a coding standard pass. Both commands are in the Makefile as written, and the second one deliberately leaves two resource trees out of the PSR2 scan.

test:
	vendor/bin/phpunit --coverage-text
	vendor/bin/phpcs --version && echo &&	vendor/bin/phpcs -p --standard=PSR2 --ignore=resources/lang/,resources/views/ src tests

Run that in a checkout with dependencies installed and you get the two checks the badges report. The exclusion list carries more information than it looks. resources/lang/ holds the locale files for those thirty locales, resources/views/ holds the templates, and translated strings plus markup are not held to the same rule as PHP source in src/ and tests/.

The rest of the top level splits its automation across several places: phpunit.xml for the test run, .travis.yml, .github/ and .styleci.yml. The StyleCI badge names repository 39873788 on branch master, the Scrutinizer badge runs on master as well, and the CodeClimate badge points at UniSharp/laravel-filemanager/maintainability. Three style signals and two CI configurations sit beside one Makefile, which leaves the Makefile as the fastest local check available. There is no packaging target in it, so nothing there builds a distributable archive; Composer does that.

Thirty locales, one image library, three maintainers

The credits say more about how the package is put together than the feature list does. It credits @taswler as the original author, which tells you this is a lineage with an upstream rather than something built from an empty directory, and it credits @olivervogel for the image library Intervention/image. That second credit is the honest answer to where the cropping and resizing in the feature list comes from: the behaviour lives in another project, and this package wires it into a file browser.

Three names are given as maintainers, Stream, Youchen Lee and Willem Leuverink, and the security section names Ayon Hasan and Nathan. The logo is credited to its designer under CC BY 4.0, a separate arrangement that covers that image and not the package. SVG loaders come from Sam, and the remaining credits are to contributors on the project and to users.

Read together with the locale list, this is a package with a long tail of upkeep: thirty translated interfaces, an upstream image dependency and a logo carrying its own terms. None of that is a problem on its own. It is an argument for pinning the version and reading the Upgrade page before you upgrade rather than tracking the branch.

A frozen 2.6.4 badge next to a live version badge

Read the badge row closely and the version story turns murky in a way the feature list hides. The live badges pull the latest stable version and the download count straight from Packagist. Sitting beside them, wrapped in an HTML comment so it never renders, is an older hand-written badge pinned to stable-2.6.4. A version number was once typed into the README by a person, that badge fell behind the actual tags, and the repair applied was to comment it out rather than update it.

The demo link points at a repository named laravel-filemanager-example-5.3, and 5.3 is a Laravel major version. The sample application offered as a live demo therefore belongs to a far older generation of the framework than the 2.x package line shipping next to it, and the README does not say which Laravel versions that line targets. The last push was on 2026-08-09 and carried the v2.15.1 release, following v2.15.0 on 2026-06-15 and v2.14.0 on 2026-04-27, a cadence of roughly six to eight weeks between the three most recent tags.

The MIT terms let you vendor this into an application you ship without a copyleft obligation, and the full text sits at the top of the tree, which is the part most teams check first.

Where the gallery is the wrong tool

Three cases make this the wrong shape. Start with access control. The multi-user mode described in the README has two levels and no third: folders every user can manage, and folders only the owner can manage. Nothing in the feature list describes roles, groups or a read-only folder, so an application where editors may browse but not upload has to enforce that in the middlewares it attaches to the customizable routes.

Second, failure handling. Several files can be selected in one action, and the README documents no rollback, no partial-failure report and no cleanup rule for a batch that dies halfway through. That is precisely where the questions arrive for an editor-driven upload, and the Events page is the only place behaviour after an upload is addressed.

Third, image processing. Cropping and resizing are credited to Intervention/image, so quality settings, stored format and the memory cost of a large image are tuned in that dependency's configuration, not in this package's. Anyone who only needs thumbnails does not need a file browser, and anyone who expects the gallery to normalise image output will not find that here.

Rolling your own gallery on the same filesystem

The real alternative is not another gallery, it is no gallery. Because the package is built on Laravel's filesystem, an application that needs an upload field and a public URL can call that filesystem directly, keep the CKEditor dialog down to a single field, and drop the interface, the two roots, the locale set and the per-user folder machinery. That trade is worth taking when the set of people who can upload is small and already known, because it removes the browser from the path entirely.

Where the gallery earns its place is the other case: many users browsing, cropping and picking assets without learning paths, or a content team that needs a picker inside CKEditor, TinyMCE or Summernote. For image work alone, going straight to Intervention/image, the library this package credits as its own, keeps the resize and crop behaviour while skipping the file browser, its routes and its configuration.

The decision comes down to who you are building for. One known user and a fixed list of upload fields, take the direct route. An open set of editors who need to see what already exists, take the gallery and budget time for the middlewares the package leaves to you.

Editorial conclusion

Adopt it when editors need to browse and crop assets inside a form and you want private per-user folders without writing the file browser yourself. Leave it when uploads must follow a role rather than an identity, or when a failed multi-file batch needs a documented rollback, because neither is spelled out beyond a line in the feature list. Before wiring it into a form, confirm which Laravel version the current tag supports, then check that the customizable routes and middlewares enforce your own rules and run the Makefile test target over any file you change.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. UniSharp/laravel-filemanager on GitHub