Weave Code
Tomato Logs Module Laravel Package
tomatophp/tomato-logs-module
A Laravel module that adds a log viewer to the Tomato PHP admin panel, letting you browse, filter, and inspect application log files from a clean interface instead of digging through server files.
Log Viewer for TomatoPHP using Laravel Log Reader
Frequently asked questions about Tomato Logs Module
- What is tomatophp/tomato-logs-module and what does it do?
- It is a Laravel package in the TomatoPHP ecosystem that adds a log viewer to the Tomato admin panel, which is built on Filament and Livewire. Instead of SSHing into a server and tailing files by hand, you browse, filter, and inspect log records from a clean interface inside the panel. It uses Laravel Log Reader under the hood and ships a service provider, migrations, and a Filament plugin/page set. It is additive: no core framework patching, no middleware hijacking, and no separate runtime.
- How do I install tomato-logs-module in a Laravel app?
- Standard Laravel package mechanics apply: run composer require tomatophp/tomato-logs-module, then publish the config and migrations with php artisan vendor:publish and run php artisan migrate. Service provider auto-discovery handles registration. Finally, register the plugin on your Filament panel provider so the log page appears in the admin navigation. For a developer already fluent in Filament, a realistic spike is half a day to two days, mostly config tuning rather than plumbing.
- Which Laravel and Filament versions does tomato-logs-module support?
- The evaluation targets PHP 8.1+, Laravel 10/11, Filament v3, and Livewire 3, but you should confirm the exact constraints in the package's composer.json before committing. The module is effectively pinned to whichever Filament major the Tomato panel targets, so a Filament major bump can strand it. Run a composer why-not or a dependency-resolution dry run in a scratch branch to surface conflicts cheaply. Check whether Filament v2 is still supported if you are on an older panel.
- Can I use tomato-logs-module without Filament?
- No, not realistically. The module renders its log viewer as a Filament plugin and page set, so a Blade, Vue, or Inertia application without Filament gets effectively zero value from it. Adopting Filament solely to consume this module is not justified; adopt the module because you already run, or independently want, the Tomato/Filament panel. For non-Filament stacks, a standalone log reader or Telescope is a better fit.
- How do I register the log viewer plugin on a Filament panel?
- After installing and migrating, you add the module's plugin to your panel provider's plugin list, typically inside the panel() method chain alongside your other Filament plugins. Once registered, the log page shows up in the panel navigation. Publish the config first so you can tune retention, subject types, and authorization before the page goes live. Verify the page renders in a throwaway Laravel plus Filament app before merging.
- How do I control who can access the log viewer?
- Access control must be explicitly configured; a default-open log viewer in an admin panel is an audit finding waiting to happen. Review whether the module uses a policy, a gate, or panel-level access only, and wire it into your existing authorization model. Activity logs routinely capture user IDs, IPs, user agents, and model diffs, so treat the page as sensitive data. Lock it down to a trusted admin role before it reaches production.
- Does tomato-logs-module store logs in the database?
- The module ships migrations and a service provider and renders log records inside the admin panel, while its log-reading layer is built on Laravel Log Reader. Before merging, publish the migrations into version control and diff the generated schema against your conventions to see exactly what it persists. If your application already defines an activity-log schema, confirm there is no duplicate or conflicting table. Treat v1.0.0 as a trial dependency rather than assuming the schema is stable.
- Will tomato-logs-module conflict with spatie/laravel-activitylog or Laravel Telescope?
- There is overlap risk. If you already run spatie/laravel-activitylog or Laravel Telescope you may end up with duplicate tables or conflicting model assumptions, so check whether this module depends on spatie/laravel-activitylog and at what version, or defines its own log schema. Add it on a feature branch and run a dependency-resolution dry run first. Coexistence with an existing audit package is one of the three compatibility axes you should verify explicitly.
- How do I prune old logs so the tables do not grow forever?
- The package provides the read UI, but retention, pruning, and indexing discipline remain your responsibility. Check whether a documented pruning command ships with the module; if not, schedule your own cleanup job or model pruning against the log table. Log tables grow monotonically, so add indexes on the columns you filter by and set a retention window before volume becomes a problem. Test the pruning path in staging so you do not delete audit evidence you are required to keep.
- Is tomato-logs-module production ready and well maintained?
- It is v1.0.0 with release notes consisting solely of a changelog link, with no feature list, breaking-change statement, or migration note, which is a risk signal for a package that writes to your database. TomatoPHP is a largely single-maintainer ecosystem, so check commit cadence, issue response time, and CI/test coverage before relying on it. Verify whether commercial support is available through TomatoPHP or whether it is community-only. Install it behind a feature branch, publish config and migrations into version control, and do not adopt on the strength of the version number alone.
Weaver
How can I help you explore Laravel packages today?