- How do I install fkeloks/ibexa-logs-ui in an Ibexa application?
- Install it with composer require fkeloks/ibexa-logs-ui, register the bundle in config/bundles.php, and clear the cache. There are no migrations, schema changes, or new services to operate. The real effort is verification: confirm the route is registered, the Twig templates match your Admin UI build, and your Monolog handlers match the bundle's assumptions.
- Does fkeloks/ibexa-logs-ui work with Laravel?
- No. It is a Symfony bundle built for the Ibexa DXP back office and depends on Ibexa's admin UI and bundle registration; it is not a Laravel package and has no Laravel service provider or config. Laravel teams should treat it as out of scope and use Laravel-native log viewers or an observability stack instead.
- Which Ibexa, Symfony, and PHP versions does this log viewer support?
- The package was last released on 2022-09-05 against an Ibexa 4.0-era Admin UI, and there is no verified support for newer Ibexa 4.x minors, PHP 8.2/8.3, or newer Symfony lines. Run composer why-not against your lock file to see whether its constraints block a platform upgrade. Validate on a branch rather than in a release train.
- Is fkeloks/ibexa-logs-ui still maintained?
- It has zero stars, zero dependents, a last release in September 2022, and effectively no community validation. Treat it as abandoned and plan to fork and vendor it internally if you adopt it. Do not consume the upstream package directly in production without owning the code.
- Where does the bundle read logs from, and will it work with containerized or centralized logging?
- It surfaces Monolog file output from var/log/*.log in the Ibexa back office. If your logs go to stderr/stdout in containers or to ELK, Loki, Sentry, or another drain, the bundle has nothing to render and is a non-starter. Confirm your Monolog handlers write the expected files and format.
- Is it safe to browse log files inside the Ibexa back office?
- Log lines and stack traces often contain DSNs, tokens, and PII, so access must be gated by a dedicated Ibexa policy or role, not just 'logged into the back office.' Confirm there is no download, delete, or tail-execute path. Also verify the parser tolerates your Monolog formatter, especially JSON or custom processors.
- Does the log viewer paginate files or load the whole log into memory?
- The available evaluation does not confirm the implementation details, so verify whether the controller reads the entire file or paginates/tails it. Test behavior on a large log such as 500 MB before exposing it to users. A thin controller over the filesystem can still cause memory or timeout problems.
- Will installing this bundle change or override my Monolog configuration?
- The bundle is a thin controller and Twig layer, but you must confirm it does not replace or reorder your Monolog handlers. A handler override would be the one change with genuine production consequence. Run bin/console debug:container to inspect any Monolog-related service changes.
- How do I verify route registration and templates before deploying?
- On a branch, run bin/console debug:router | grep -i log to confirm the admin route, and debug:container to check Monolog wiring. Do a template smoke test in the back office for your Ibexa Admin UI build. Also check composer why-not and confirm the route is restricted to the right role.
- What are alternatives to fkeloks/ibexa-logs-ui?
- Use the observability stack you already pay for, such as ELK, Loki, Sentry, or Datadog, which offers better search and retention. If you are migrating from legacy eZ Platform, this bundle is the Ibexa 4 successor to ezsystems/ezplatform-logs-ui but is not maintained. A small custom admin route is often safer than adopting an abandoned package.