Weave Code
Tomato Browser Module Laravel Package
tomatophp/tomato-browser-module
A Tomato PHP admin module that adds a browser for exploring and managing files and media inside your Laravel application, integrating with the Tomato admin panel to give developers a simple built-in file browsing interface.
Browser to the files inside your app build for TomatoPHP
Frequently asked questions about Tomato Browser Module
- What does tomatophp/tomato-browser-module actually do?
- It is a TomatoPHP admin module that adds a file and media browser to a Laravel application, so developers get a built-in interface for exploring and managing files inside the admin panel instead of building a bespoke file manager. It is a back-office capability that slots in alongside other TomatoPHP modules such as settings, roles, and translations, not something on your application's request path. The overview does not publish a detailed feature list, so confirm the exact browse, upload, and delete behaviors against the repository before adopting it.
- Which Laravel and Filament versions does tomato-browser-module support?
- TomatoPHP modules conventionally ship as Filament plugins, so expect a requirement of Laravel with a supported Filament major, PHP 8.1 or newer, and a configured filesystem disk, with composer.json as the authoritative constraint. No supported-version matrix is published in the release notes, so read composer.json and the repo before installing. TomatoPHP modules have historically tracked Filament major versions closely, so plan for a coordinated module bump when you upgrade Filament.
- How do I install tomato-browser-module in a Laravel app?
- The expected flow follows the standard TomatoPHP pattern: require the package with Composer, let service provider auto-discovery register it, publish the config, migrations, and assets, then register the plugin on your Filament panel. Confirm the exact artisan publish and panel-registration commands in the repository README, since the release notes are only a changelog link. Make sure your deploy pipeline runs the Filament asset build step so the browser UI renders correctly.
- Does tomato-browser-module work without Filament?
- The module is designed as a Filament admin surface, so it assumes the Livewire and Filament asset pipeline is already present in your application. If your admin panel is bespoke Livewire or Blade, or a separate SPA, the integration cost roughly doubles because you have to host another admin surface rather than embedding it. In that case the value proposition weakens considerably and a simpler custom uploader or a dedicated file manager may be a better fit.
- Which storage disks does the browser support, local only or S3?
- This is not documented in the overview or release notes, and a file browser module implies a storage disk, a visibility model, and a thumbnail or preview pipeline. Whether it supports only the local driver or also S3-compatible disks out of the box is an open question you should raise with the maintainer. A practical way to find out is to run it read-only against a scoped disk in staging and observe how it resolves paths and URLs.
- How does authorization work in this file browser?
- The authorization model is not published, so it is unclear whether the module respects Laravel gates and policies or ships its own permission table. That distinction matters a lot if non-admin users will ever see the browser, because a module-level permission table bypasses the policy logic you already trust. Treat this as the key spike question before exposing it beyond trusted administrators.
- Is tomato-browser-module safe to use in production?
- Treat the 1.0.0 tag as a naming decision rather than a quality signal, since the release notes are a changelog URL with no feature list, breaking-change statement, or upgrade guide. File browsers touch security-sensitive areas including storage disks, upload validation, MIME and extension handling, path traversal defenses, and public-versus-private URL generation. Start with a read-only deployment against a scoped disk, confirm rendering and authorization, then cut over deliberately.
- Can I migrate to this module from Laravel File Manager or a custom uploader?
- Do not migrate in place. Run the module read-only against a scoped disk or a copy of your media tree first, confirm it renders and authorizes as expected, and only then switch over. Greenfield projects are simpler: install it as part of the initial Filament panel build with no migration or coexistence problem. Because there is no prior assessment or published changelog content, this is a first adoption rather than a version bump with a documented migration path.
- How should I test tomato-browser-module before rolling it out?
- Run it in staging against a scoped disk and exercise browse, upload, and delete paths, checking that authorization follows your gates and policies. Probe path traversal and MIME validation explicitly, since those are the areas a young file browser package carries the most risk. Also check whether the repository has CI, automated tests, and a release cadence, because the overview does not confirm any of them.
- What are the best alternatives to tomato-browser-module for Laravel?
- Alternatives include Laravel File Manager, a custom uploader built on Laravel's filesystem and validation APIs, or direct S3 console access for asset management. The module's real advantage is adjacency: if you already run the TomatoPHP and Filament stack, it is a low-friction addition, whereas if you do not, a dedicated file manager or a small custom solution is usually a better investment. Compare them on authorization model, supported disks, and Filament version coupling before deciding.
Weaver
How can I help you explore Laravel packages today?