- Does itn/log-viewer-bundle work with Laravel?
- No. itn/log-viewer-bundle is a Symfony 2 bundle built on Symfony contracts such as a Bundle class, a DI extension, Resources/config/routing.yml, and Twig views, none of which exist in Laravel. Laravel uses service providers, config/*.php, routes/web.php, and Blade, and there is no bridge or facade for this package. Treat it as a UX reference at most, not a Composer dependency for a Laravel app.
- How do I install itn/log-viewer-bundle?
- In a Symfony 2 project you would require it with Composer, register the bundle in AppKernel, point the log path at your Monolog directory, and import its routing configuration. There is no Laravel installation path because the package ships Symfony bundle classes and Twig templates. If you are on a modern Symfony or Laravel stack, expect to rewrite the integration rather than configure it.
- What Laravel log viewer package should I use instead?
- For Laravel, use a maintained Laravel-native package such as opcodesio/log-viewer, which offers host authorization, search, level filters, and a publishable config, or rap2hpoutre/laravel-log-viewer for a minimal single-route viewer. Laravel Telescope is a better fit for local and staging debugging. All of these install in one line and follow Laravel conventions, which is the gap itn/log-viewer-bundle will never close.
- Is itn/log-viewer-bundle still maintained?
- No. The last release was 2015-01-16, placing it in the Symfony 2.x and PHP 5.x era, and it has a single maintainer with roughly 2 stars and 0 dependents. There is no active disclosure path and no dependent ecosystem to surface regressions. Unmaintained packages should not be added to new projects.
- Which PHP and Symfony versions does itn/log-viewer-bundle support?
- It targets Symfony 2.x and PHP 5.x. On PHP 8.1+ you should expect fatal errors from removed functions, dynamic-property deprecations, container compilation changes, Twig autoescape differences, and outdated PSR/Composer constraints. Symfony 3+ also moved the default log directory from app/logs to var/logs, which fails silently and leaves the viewer empty.
- Is itn/log-viewer-bundle safe to expose in production?
- No, not without a serious security review. A log viewer is a sensitive surface: uncanonicalized log-path parameters risk path traversal and arbitrary file reads, older bundles often ship routes with no firewall, unescaped log content is a stored XSS vector, and logs routinely contain tokens, PII, and connection strings. If you must run it, bind it to an internal-only firewall and feature-flag it.
- How does itn/log-viewer-bundle read and store log files?
- It reads your existing Monolog files directly from a configured log directory, so there is no database, index, or extra storage to manage. Entries are parsed from standard Monolog output and rendered in the browser with syntax-highlighted stack traces. The trade-off is that performance depends entirely on file size, and very large logs will not page well.
- Can I filter logs by level, channel, or date with itn/log-viewer-bundle?
- Yes. The bundle offers level filtering to isolate errors, warnings, or debug output, full-text search across messages and exception traces, and date navigation to jump between days. That interaction model is the genuinely useful part of the package and is worth copying into a Laravel-native implementation or a centralized logging tool.
- How do I evaluate or spike itn/log-viewer-bundle safely?
- Start by running composer why-not on a PHP 8.1 container to confirm the constraint conflicts, and timebox any spike to about one day. Install it only on a throwaway branch behind a feature flag and an internal firewall. Given the near-zero Laravel fit, the spike usually ends with a decision to build or buy rather than adopt.
- Should I port itn/log-viewer-bundle to Laravel or use centralized logging?
- Porting is bounded but real work: auth, file discovery, pagination, filtering, and safe rendering all need rewriting against current Laravel APIs. Before you do that, ask whether the job is tailing, searching, correlating, or alerting, because a browser viewer only handles the first two and poorly at scale. If you already have an observability budget, ship logs to Sentry, Datadog, Grafana Loki, or CloudWatch instead.