Ibexa Logs Ui Laravel Package

Getting Started

This is a small, single-author Ibexa bundle (last release September 2022, zero stars, zero dependents) that adds a UI for browsing Ibexa/Symfony log files. Treat it as "read the source before you trust it," not as a drop-in vendor dependency.

Minimal path:

1. Check fit first. Confirm the bundle's composer.json constraints against your Ibexa version and PHP version. With no releases since 2022 it likely targets Ibexa 4.x / PHP 8.0–8.1; on newer stacks expect at least a composer why-not conversation.
2. Read the bundle, not just the README. Open vendor/fkeloks/ibexa-logs-ui/ and look at, in order:
   • the bundle class (src/*Bundle.php) — namespace tells you what to register,
   • Resources/config/ (routing, services, default_settings.yaml if present),
   • src/Controller/ — the route path, the log directory it reads, and whether it takes a filename from the request,
   • Resources/views/ — how it renders, and whether it uses Ibexa's admin design system.
3. Register the bundle in config/bundles.php, and import its routing if the bundle doesn't autoload it (most Ibexa bundles require an explicit entry in config/routes/ or config/routes/ibexa.yaml).
4. Clear cache and find the route: bin/console cache:clear && bin/console debug:router | grep -i log.
5. Log in as an admin and open the route. If you get a 403, you've hit the permission layer (see Gotchas) — that's usually a firewall/policy issue, not a bundling issue.

First real use case: give support staff and editors a read-only, in-admin view of var/log/prod.log (or a dedicated support Monolog channel) so they can self-diagnose "why didn't my content publish" without shell access or a separate log stack. It is a convenience tool, not an observability platform.

Implementation Patterns

Standard bundle wiring. The common Ibexa pattern is: register the bundle, import routing, and let the bundle's own controller serve the page. Expect an admin-menu entry or a route you link to manually. If there's no menu item, add one via an admin menu listener rather than hardcoding links into templates.

Access control is your job, not the bundle's. In practice you want to gate this behind either:

• an Ibexa Policy (a custom module/function, e.g. logs / read) checked in a controller listener, or
• a Symfony access_control rule + role, e.g. only ROLE_ADMIN or a dedicated ROLE_SUPPORT.

Whichever route you take, verify with a non-admin user before shipping. A log viewer that leaks stack traces and request payloads to editors is a security incident waiting to happen.

Channel-per-concern. The bundle is only as useful as your Monolog config. Split into named channels/files (prod.log, support.log, payments.log) so the UI's file picker maps to something meaningful. A single 500 MB prod.log makes any file-based viewer painful.

Environment scoping. The clean pattern is: install in require-dev or enable the bundle conditionally in config/bundles.php for dev/staging only, and only ever enable in production behind a hard allowlist (VPN/internal IP check via a kernel request listener). Support tooling in prod is fine; open support tooling in prod is not.

Template override instead of forking. If you need branding or to hide the file picker, override the bundle's Twig templates using standard bundle inheritance (templates/bundles/FkeloksLogsUiBundle/...) rather than editing vendor code. That keeps you upgradeable if the package ever revives.

Pair it with a read-only log path. Point the bundle at a directory your web user (www-data) can read but not write, and make sure your deploy pipeline sets those permissions — otherwise the UI renders an empty list and you'll spend an hour debugging the bundle instead of chmod.

Gotchas and Tips

• Maintenance risk is the headline. Zero stars, zero dependents, no release in multiple years. Pin the version in composer.json, commit the lock file, and be prepared to fork or vendor-patch. Budget an hour to audit the controller for path traversal (../ in a filename parameter) before exposing it anywhere.
• File permissions. The PHP-FPM/nginx user must be able to read the log directory. This is the #1 cause of "the page loads but there are no logs." Test with sudo -u www-data head -n1 var/log/prod.log.
• Log rotation. logrotate renames and recreates files; a viewer holding an open handle or caching a file list will show stale or truncated content. If the bundle caches the listing, expect to refresh after rotation.
• Large files. File-based viewers frequently read the whole file into memory or into a request. Check the controller before pointing it at a multi-hundred-MB log. If it's naive, cap what it serves or rotate aggressively.
• Sensitive content. Logs contain emails, tokens, stack traces, sometimes SQL with PII. Restrict aggressively, and consider scrubbing at the Monolog processor level rather than relying on UI permissions alone.
• Version drift. Ibexa 4.x → 4.6, Symfony 5.4 → 6.x, and PHP 8.1 → 8.3 all changed enough that an unmaintained 2022 bundle may fail on container compilation. If cache:clear throws a service-definition error, check debug:container for the failing service and whether a deprecated argument signature is the cause.
• Routing not loading. If debug:router shows nothing, the routing file wasn't imported. Add it explicitly to config/routes.yaml under the bundle's prefix.
• Debugging checklist: debug:router (route exists?) → debug:container (services wired?) → firewall/access_control (403?) → filesystem permissions (empty list?) → log format (content unparseable?).
• Extension points to prefer: Twig template overrides, a custom controller wrapping the bundle's service, and an admin menu listener. Avoid subclassing the bundle's controller unless you're prepared to track its internals.
• When to skip it. If you need search, filtering, structured JSON logs, or retention, ship your logs to Loki/ELK/Papertrail instead. This package is a convenience UI, and the low adoption is a signal to weigh it accordingly.