Upgrading from 1.x

The main difference in v2 is the complete rewrite of the front-end.

Log Viewer now uses a Vue 3 front-end with simple API calls to the backend, instead of Livewire/Alpine.js.

This removes Livewire as a dependency for the package, which was the only one apart from Laravel itself.

Update composer.json

Update your composer.json file with the new Log Viewer version requirement:

"require": {     // ...-    "opcodesio/log-viewer": "^1.9"+    "opcodesio/log-viewer": "^2.0"},

Then, run composer update to update Log Viewer to the latest version.

Publish new assets

Log Viewer v2 has a new Vue frontend, which means you will need to publish the frontend JS/CSS assets by running this command:

php artisan log-viewer:publish

Route name changes

All Log Viewer route names have been changed from blv.* to log-viewer.*.

For example, if you previously used route('blv.index') to link to the Log Viewer, you will need to replace it with route('log-viewer.index') instead:

- route('blv.index')+ route('log-viewer.index')

Changes to config/log-viewer.php

If you have previously published the configuration file for Log Viewer, there are only 2 small changes you might need to make.

Removed: eager_scan

Remove the eager_scan option from config/log-viewer.php as it is no longer used.

Updated: middleware config option

Log Viewer no longer applies the web middleware automatically. It is possible to use Log Viewer without the web middleware, as long as you don't require any authorization. But, for backwards compatibility and ease of use, the log-viewer.middleware config option now includes a couple of middlewares by default:

    /*    |--------------------------------------------------------------------------    | Log Viewer route middleware.    |--------------------------------------------------------------------------    | Optional middleware to use when loading the initial Log Viewer page.    |    */    'middleware' => [        'web',        \Opcodes\LogViewer\Http\Middleware\AuthorizeLogViewer::class,    ],    

• The web middleware makes sure your requests are stateful and can resolve an authenticated user for authorization.
• The AuthorizeLogViewer middleware makes sure that only authorized users can access the Log Viewer. You still need to configure the authorization rule described here. You can remove this middleware if you don't need authorization.

Added: api_middleware

A new api_middleware option was added to let you configure the middleware used on API calls to the Log Viewer.

Add this to your config/log-viewer.php:

    /*    |--------------------------------------------------------------------------    | Log Viewer API middleware.    |--------------------------------------------------------------------------    | Optional middleware to use on every API request. The same API is also    | used from within the Log Viewer user interface.    |    */    'api_middleware' => [        \Opcodes\LogViewer\Http\Middleware\EnsureFrontendRequestsAreStateful::class,        \Opcodes\LogViewer\Http\Middleware\AuthorizeLogViewer::class,    ],    

• The EnsureFrontendRequestsAreStateful middleware makes sure that API requests from the Log Viewer user interface are stateful. This is required for authorization to work properly when navigating the logs. You can remove this middleware if you don't need authorization.
• The AuthorizeLogViewer middleware makes sure that only authorized users can access the Log Viewer. You still need to configure the authorization rule described here. You can remove this middleware if you don't need authorization.

Other notes

There's nothing more to do, but a few differences in v2 are worth mentioning below.

Livewire is no longer used

If you had previously extended or rewrote the Livewire components from the Log Viewer v1, those will no longer be used. You might want to clean up any overrides to Log Viewer's v1 Livewire components.

Preferences reset

User preferences (such as direction of logs, pagination, short stack traces, etc) are no longer stored in session cookies. Instead, they are now stored in the browser's localStorage.

This change also means that cookies are no longer required for normal operation and opens up stateless API routes for working with logs outside the provided UI.