Better Log Viewer Laravel Package

Getting Started

1. Install into a Laravel app (package supports auto-discovery):

   composer require arukompas/better-log-viewer
   

2. Publish the config so you can see the route prefix, middleware, and log-path settings:

   php artisan vendor:publish --provider="Arukompas\BetterLogViewer\BetterLogViewerServiceProvider"
   

   Inspect the resulting config file first — it tells you the exact route, the directory being read (storage/logs by default), and which middleware guards it.

3. Hit the route in the browser (typically /logs or whatever prefix the config exposes). You should see a list of log files; click one to see parsed entries with a search box and pagination.

4. First real use case: reproducing a production/staging exception. Search the daily log for the exception class or a request ID, page through results, and copy the stack trace — this is where the search + pagination combo beats tail -f or grepping by hand.

Because the package is archived, treat it as read-only infrastructure: pin the version, vendor it if you rely on it long-term, and do not expect fixes. If you are starting fresh, evaluate opcodesio/log-viewer (same maintainer, actively maintained) before committing to this one.

Implementation Patterns

Guard the route with real auth. The single most important integration step is putting admin auth in front of it:

// config/better-log-viewer.php
'middleware' => ['web', 'auth', 'can:viewLogs'],

or restrict to non-production via a service provider Gate::define/abort_unless check on app()->isLocal().

Environment gating. Register the service provider (or publish the route) conditionally so the viewer never exists in production:

// AppServiceProvider::register()
if (! app()->isProduction()) {
    $this->app->register(\Arukompas\BetterLogViewer\BetterLogViewerServiceProvider::class);
}

Workflow: search-driven triage. Typical loop is open latest daily file → search by exception class, correlation ID, or a route path → page to the first occurrence → copy the trace into your issue tracker. Search across a paged file is the package's core value; it is not a metrics/alerting tool.

Admin panel integration. If you use Filament/Nova/a custom dashboard, expose a link to the viewer route from the admin nav rather than remembering the URL. Since routes are config-driven, read the prefix from config when building the link so it stays in sync.

Read-only local mirroring. For staging, mount or symlink storage/logs from the app server into the box running the viewer so you can search without SSH-ing per request. Keep the viewer process off the public internet.

Keep log channel compatible. Stick to Laravel's default single/daily line format; anything custom (JSON channel, multi-line stack traces with custom formatting) may parse poorly since the viewer assumes standard log lines.

Gotchas and Tips

• Archived = no security patches. A log viewer exposes stack traces, file paths, env-adjacent data, and sometimes request payloads. Never ship it publicly reachable; ideally never in production at all.
• Check auto-discovery vs. manual registration. If you conditionally register the provider as above, remember to disable package discovery for it in composer.json (extra.laravel.dont-discover) or you'll get the route in production anyway.
• Clear config cache after changes. Route prefix / middleware edits in config/better-log-viewer.php won't apply until php artisan config:clear — a common "why is it still public?" debugging trap.
• Large log files. Search + pagination helps the UI, but parsing still reads the file; a multi-GB daily log will be slow or memory-heavy. Rotate logs, or open a smaller dated file.
• Permissions. The PHP/web user must be able to read storage/logs. On containerized setups where logs are written by a different UID, you'll get an empty list rather than an error — verify with ls -l before debugging the package.
• Pagination loses search context on some flows. When paging, confirm the query string is preserved; if not, re-issue the search with the page parameter manually in the URL.
• Multi-line exceptions. Entries whose stack traces span lines may be grouped or truncated depending on how the parser splits on timestamps — verify against a real exception before trusting the view for triage.
• Route collisions. If you already have a /logs route or another viewer installed, change the prefix in config rather than fighting route order.
• Extension points are thin. This is a UI-over-files package, not a pluggable pipeline; don't plan to add custom filters/export without forking. If you need level filtering, per-file stats, or shareable links, that's the signal to migrate to opcodesio/log-viewer.
• Migration tip. Because both come from the same author, moving to the maintained successor is mostly a config/route rename; budget time to uninstall this one and re-guard the new route.