- What Laravel versions does this log-manager package support?
- The package is compatible with Laravel 8 through 11, as it relies on core Laravel features like facades, Blade components, and Eloquent migrations. Always test thoroughly in your specific Laravel version, especially since the package hasn’t been updated since 2021. Check for breaking changes in newer Laravel releases, such as deprecated Eloquent methods.
- How do I add custom log types without editing the config file directly?
- The package requires defining log types in `config/log-manager.php`. Currently, there’s no documented dynamic way to add types via migrations or seeders. You’d need to manually update the config file or extend the package’s logic in a custom service provider to load types from a database table or environment variables.
- Does this package support Laravel’s logging channels (e.g., single, stack, or database channels)?
- No, this package writes logs directly to its own database tables (`logs` and `error_logs`) and doesn’t integrate with Laravel’s native logging channels. If you need multi-channel logging, consider combining this package with Laravel’s built-in logging or a dedicated logging service like Monolog.
- How do I prevent sensitive error traces from leaking in production?
- The `error_trace` field in the `error_logs` table stores raw stack traces, which can expose sensitive data. Mitigate this by restricting database access via Laravel’s gate policies or middleware, or by sanitizing the trace before saving. For production, consider logging only error messages and IDs, then querying full traces only when authorized.
- What’s the best way to handle log retention or cleanup for this package?
- The package lacks built-in log retention. To manage table bloat, manually prune logs using Laravel’s `Model::where()` queries or schedule a custom Artisan command with `schedule:run`. For example, add a job to delete logs older than 90 days: `Log::where('created_at', '<=', now()->subDays(90))->delete();`.
- Why am I getting a `BaseFacade not found` error after installation?
- This error typically occurs if the package’s service provider isn’t registered or the facade alias isn’t published. Run `composer dump-autoload` and verify the `LogFacade` alias exists in `config/app.php`. If using Laravel 8+, ensure the package’s service provider is listed in `config/app.php` under `providers`.
- Can I use this package with SQLite instead of MySQL/PostgreSQL?
- The package should work with SQLite, but there are no SQLite-specific optimizations or tests. SQLite’s transaction handling and query syntax may differ slightly, so test thoroughly. If you encounter issues, check for deprecated Eloquent methods (e.g., `whereRaw`) that might behave differently in SQLite.
- Are there alternatives to this package for Laravel log management?
- Yes. For UI-based log viewing, consider `spatie/laravel-log-viewer` (supports file and database logs). For debugging, `barryvdh/laravel-debugbar` provides a dashboard with logs, queries, and more. For audit trails, `owen-it/laravel-auditing` offers model-level logging. Compare features like retention, search, and error handling.
- How do I integrate the log-menu Blade component into my existing layout?
- Publish the Blade component with `php artisan vendor:publish --tag=log-manager`, then include it in your layout file (e.g., `resources/views/layouts/app.blade.php`). Use `<x-log-menu />` in your sidebar or header. Customize its appearance by overriding the published Blade file in your `resources/views/vendor/log-manager` directory.
- What permissions are needed to access the logs/error_logs tables?
- The package doesn’t enforce permissions by default. Secure access by implementing Laravel’s gate policies or middleware. For example, restrict the `logs` and `error_logs` tables to authenticated users with the `view-logs` permission: `Gate::define('view-logs', fn() => auth()->check());`. Always validate queries to prevent SQL injection.