Web Log Viewer Bundle Laravel Package

Getting Started

Reality check before you composer require anything. This is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/web-log-viewer.php to publish, and no php artisan vendor:publish path. Laravel's package auto-discovery will not find it, and installing it into a Laravel app gets you a class that expects Symfony\Component\HttpKernel\Bundle\Bundle, the Symfony DI container, and Symfony routing. For a Laravel codebase, the realistic options are:

1. Skip it and use a native equivalent (opcodesio/log-viewer or rap2hpoutre/laravel-log-viewer) — same feature set, maintained, zero friction.
2. Run it as a sidecar — a tiny Symfony app (or an existing Symfony service in your stack) that mounts this bundle and reads a shared log volume. Useful only if you already operate Symfony services alongside Laravel.
3. Treat it as reference code — the parsing/reading logic is small enough to port into a Laravel controller or Artisan command in an afternoon. This is the highest-value use given the package's age.

If you are on Symfony (3.4/4.x era), minimal steps:

composer require greenskies/web-log-viewer-bundle

Then register the bundle in app/AppKernel.php (or config/bundles.php on Symfony 4+), import its routing (check Resources/config/routing.xml/.yml for the route name and path), and set the log file path in your config. Look first at DependencyInjection/Configuration.php — that file is the authoritative list of config keys, defaults, and whether a path or a directory is expected. Second, read the controller and the log-reading service: they tell you exactly which Monolog line format the parser assumes.

First use case: point it at var/log/dev.log, load the route, and confirm it renders the default Monolog format ([2024-01-01 12:00:00] app.INFO: message [] []). If your handler uses a custom formatter (json, logstash), it will likely show blank or unparsed rows — that's your first signal about how much you'd need to fork it.

Implementation Patterns

• Config-driven path per environment. Keep the log path in config/packages/*.yaml under the bundle's alias rather than hardcoding. The bundle has no environment awareness of its own; it reads whatever path you give it.
• Align Monolog and the viewer. The classic failure is Monolog writing to var/log/prod.log while the bundle points at %kernel.logs_dir%/app.log (a Symfony 2/3-era default). Grep your monolog.yaml handlers for the path: value and copy it verbatim.
• Never expose it on the public firewall. Add an access_control entry requiring ROLE_ADMIN (or an IP allowlist via security.access_control with ips:). Better still, put it on a separate admin firewall/subdomain so a misconfigured anonymous: true can't leak it. Log files contain session IDs, API tokens, and PII.
• Porting pattern for Laravel. The bundle's core is: open file → iterate lines → regex against Monolog's default format → build {timestamp, channel, level, message, context} → render. In Laravel that's a Route::get('/logs', ...) behind auth + a Gate, using SplFileObject with SEEK_END-style tailing for large files, plus a Str::contains filter. Do not use file() — see gotchas.
• Multiple log files. If the bundle supports only one path per config, run it once per file (two routes, two configs) rather than patching the reader. If you need cross-file search, a Laravel implementation or a real log aggregator (Loki, Papertrail) is the better investment.
• Shared-volume sidecar. If you run Laravel + Symfony, mount your Laravel storage/logs into the Symfony container read-only and point the bundle at it. This is the one scenario where the bundle genuinely earns its place.
• Do not use it for alerting. It's a read-only UI. Errors that matter should go to Sentry/Bugsnag/Flare; the viewer is for "what happened at 14:32" archaeology.

Gotchas and Tips

• Abandoned since March 2018 — plan to fork. Last release targets the Symfony 3.4/4.0 era. On Symfony 5/6/7 you'll hit: Bundle no longer auto-resolving paths, type: annotation route loading removed, deprecated Twig functions in the templates, and services.yml autowiring that doesn't match modern defaults. composer require will most likely fail on constraints; use composer why-not greenskies/web-log-viewer-bundle to confirm, then vendor a patched fork.
• PHP 8 friction. Expect nullable-parameter deprecations, possible dynamic-property warnings, and each()/create_function-era code if it's present. Run with error_reporting(E_ALL) once before trusting the output.
• No Flex recipe. There's no symfony/flex recipe, so registration and routing import are entirely manual. Missing the routing import is the #1 cause of a 404 — verify with bin/console debug:router | grep -i log.
• Memory blowup on big files. Verify whether the reader uses file()/file_get_contents (loads everything) or a streamed iterator. Test against a ~200–500 MB rotated log before shipping; a viewer that OOMs the FPM worker is worse than no viewer.
• Rotation behavior. Pointing at prod.log means the UI silently switches to the fresh file after rotation, and yesterday's prod-2024-01-01.log disappears from view. If you need history, point at a directory (if supported — check the config tree) or a stable symlink.
• Permissions and SELinux. The FPM user needs read access to the log file and traverse permission on every parent directory. On RHEL-family hosts, check audit.log for avc: denied on the log path before assuming the bundle is broken.
• Debugging checklist: bin/console debug:config <bundle_alias> (confirms your keys are actually merged), debug:router, lint:container. A blank page is usually the security firewall redirecting you to login in a loop rather than a template error.
• Extension points are thin. Realistically: the config tree, and Twig template overrides via templates/bundles/<BundleName>/ on Symfony 4+. There are no events, no parser interface worth decorating, and no hook system — anything beyond path config means forking.
• Verdict for a Laravel team: 4 stars, 0 dependents, no release in 7 years. Don't add it as a dependency. Read Controller/ and the reader service for 10 minutes, port the parsing to Laravel, gate it behind auth, and move on.