Top Related Projects
PHP errors for cool kids
Clockwork - php dev tools in your browser - server-side component
A beautiful error page for Laravel apps
A MongoDB based Eloquent model and Query builder for Laravel (Moloquent)
Quick Overview
Laravel Debugbar is a package that integrates PHP Debug Bar with Laravel. It provides a powerful and customizable debugging toolbar for Laravel applications, allowing developers to easily monitor and analyze various aspects of their application's performance, database queries, and more during development.
Pros
- Easy integration with Laravel projects
- Comprehensive debugging information, including request data, database queries, and performance metrics
- Customizable and extendable with additional collectors and data sources
- Minimal impact on application performance when disabled in production
Cons
- Can slightly impact performance when enabled in development environments
- May expose sensitive information if accidentally left enabled in production
- Requires additional configuration for certain features (e.g., clock differences in multi-server setups)
- Learning curve for utilizing all available features and customizations
Code Examples
- Basic installation and enabling the Debugbar:
// In config/app.php
'providers' => [
// ...
Barryvdh\Debugbar\ServiceProvider::class,
],
'aliases' => [
// ...
'Debugbar' => Barryvdh\Debugbar\Facade::class,
],
- Adding custom messages to the Debugbar:
Debugbar::info('Info message');
Debugbar::error('Error message');
Debugbar::warning('Warning message');
Debugbar::addMessage('Another message', 'MyLabel');
- Measuring execution time of code blocks:
Debugbar::startMeasure('render','Time for rendering');
// Your code here
Debugbar::stopMeasure('render');
- Collecting custom data:
Debugbar::addCollector(new DebugBar\DataCollector\ConfigCollector());
Getting Started
-
Install the package via Composer:
composer require barryvdh/laravel-debugbar --dev
-
Laravel will auto-discover the package. For Laravel 5.4 or earlier, add the service provider and facade in
config/app.php
. -
Publish the configuration file:
php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider"
-
Set
APP_DEBUG=true
in your.env
file to enable the Debugbar. -
(Optional) Configure additional options in
config/debugbar.php
.
Competitor Comparisons
PHP errors for cool kids
Pros of Whoops
- Framework-agnostic, can be used with any PHP project
- Lightweight and focused solely on error handling
- Highly customizable with a plugin system
Cons of Whoops
- Limited to error handling and doesn't provide performance profiling
- Requires manual integration with Laravel (not a dedicated Laravel package)
- Less comprehensive debugging information compared to Laravel Debugbar
Code Comparison
Whoops integration in Laravel:
$whoops = new \Whoops\Run;
$whoops->pushHandler(new \Whoops\Handler\PrettyPageHandler);
$whoops->register();
Laravel Debugbar integration:
// In config/app.php
'providers' => [
Barryvdh\Debugbar\ServiceProvider::class,
],
'aliases' => [
'Debugbar' => Barryvdh\Debugbar\Facade::class,
],
Summary
Whoops is a lightweight, framework-agnostic error handling library, while Laravel Debugbar is a comprehensive debugging and profiling tool specifically designed for Laravel applications. Whoops excels in providing detailed error information and is easily customizable, but lacks the extensive features and Laravel integration that Debugbar offers. Laravel Debugbar provides a more complete debugging experience with performance profiling, query logging, and other Laravel-specific features, but may be considered overkill for projects that only require error handling.
Clockwork - php dev tools in your browser - server-side component
Pros of Clockwork
- Lightweight and less intrusive, with minimal impact on application performance
- Provides a clean, modern interface for debugging and profiling
- Supports remote debugging, allowing inspection of requests from different devices
Cons of Clockwork
- Less feature-rich compared to Laravel Debugbar
- Requires a separate browser extension for optimal usage
- May have a steeper learning curve for beginners
Code Comparison
Laravel Debugbar:
use Barryvdh\Debugbar\Facade as Debugbar;
Debugbar::info('Info message');
Debugbar::error('Error message');
Debugbar::warning('Warning message');
Clockwork:
use Clockwork\Support\Vanilla\Clockwork;
clock()->info('Info message');
clock()->error('Error message');
clock()->warning('Warning message');
Both packages offer similar functionality for logging and debugging, but Laravel Debugbar provides a more extensive set of features out of the box. Clockwork focuses on simplicity and performance, making it a good choice for projects where minimal overhead is crucial. Laravel Debugbar is more suitable for developers who prefer a comprehensive toolkit with a wider range of debugging options readily available.
A beautiful error page for Laravel apps
Pros of Ignition
- Provides a more detailed and interactive error page with stack traces, code snippets, and context
- Offers solution suggestions for common errors, helping developers quickly resolve issues
- Integrates seamlessly with Laravel's error handling system
Cons of Ignition
- May have a steeper learning curve for developers new to Laravel's error handling
- Can be more resource-intensive compared to simpler debug bars
- Might provide too much information for production environments if not properly configured
Code Comparison
Laravel Debugbar:
use Barryvdh\Debugbar\Facade as Debugbar;
Debugbar::info('Info message');
Debugbar::error('Error message');
Debugbar::warning('Warning message');
Ignition:
use Facade\Ignition\Exceptions\ViewException;
throw new ViewException('Custom view error message');
The Laravel Debugbar focuses on adding debug information to a bar at the bottom of the page, while Ignition replaces the default error page with a more detailed and interactive one. Debugbar is more suited for general debugging and performance monitoring, whereas Ignition excels at providing comprehensive error information and potential solutions.
A MongoDB based Eloquent model and Query builder for Laravel (Moloquent)
Pros of laravel-mongodb
- Enables seamless integration of MongoDB with Laravel, allowing developers to use MongoDB as the primary database
- Provides MongoDB-specific query builder and Eloquent model support, making it easier to work with MongoDB in a Laravel environment
- Offers support for MongoDB-specific features like geospatial queries and aggregation pipelines
Cons of laravel-mongodb
- Lacks debugging and profiling capabilities specific to Laravel applications
- Does not provide visual representation of database queries, request data, or application logs
- Focuses solely on MongoDB integration, without offering general-purpose debugging tools for Laravel
Code Comparison
laravel-mongodb:
use Jenssegers\Mongodb\Eloquent\Model;
class User extends Model
{
protected $connection = 'mongodb';
}
laravel-debugbar:
use Barryvdh\Debugbar\Facade as Debugbar;
Debugbar::info('Info message');
Debugbar::error('Error message');
Debugbar::warning('Warning message');
Summary
While laravel-mongodb focuses on integrating MongoDB with Laravel, providing specific database functionality, laravel-debugbar is a general-purpose debugging and profiling tool for Laravel applications. laravel-mongodb excels in MongoDB-specific features but lacks the comprehensive debugging capabilities offered by laravel-debugbar. The choice between these packages depends on the project's requirements: MongoDB integration or enhanced debugging and profiling for Laravel applications.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Debugbar for Laravel
This is a package to integrate PHP Debug Bar with Laravel. It includes a ServiceProvider to register the debugbar and attach it to the output. You can publish assets and configure it through Laravel. It bootstraps some Collectors to work with Laravel and implements a couple custom DataCollectors, specific for Laravel. It is configured to display Redirects and (jQuery) Ajax Requests. (Shown in a dropdown) Read the documentation for more configuration options.
Note: Use the DebugBar only in development. Do not use Debugbar on publicly accessible websites, as it will leak information from stored requests (by design). It can also slow the application down (because it has to gather data). So when experiencing slowness, try disabling some of the collectors.
This package includes some custom collectors:
- QueryCollector: Show all queries, including binding + timing
- RouteCollector: Show information about the current Route.
- ViewCollector: Show the currently loaded views. (Optionally: display the shared data)
- EventsCollector: Show all events
- LaravelCollector: Show the Laravel version and Environment. (disabled by default)
- SymfonyRequestCollector: replaces the RequestCollector with more information about the request/response
- LogsCollector: Show the latest log entries from the storage logs. (disabled by default)
- FilesCollector: Show the files that are included/required by PHP. (disabled by default)
- ConfigCollector: Display the values from the config files. (disabled by default)
- CacheCollector: Display all cache events. (disabled by default)
Bootstraps the following collectors for Laravel:
- LogCollector: Show all Log messages
- SymfonyMailCollector for Mail
And the default collectors:
- PhpInfoCollector
- MessagesCollector
- TimeDataCollector (With Booting and Application timing)
- MemoryCollector
- ExceptionsCollector
It also provides a facade interface (Debugbar
) for easy logging Messages, Exceptions and Time
Installation
Require this package with composer. It is recommended to only require the package for development.
composer require barryvdh/laravel-debugbar --dev
Laravel uses Package Auto-Discovery, so doesn't require you to manually add the ServiceProvider.
The Debugbar will be enabled when APP_DEBUG
is true
.
If you use a catch-all/fallback route, make sure you load the Debugbar ServiceProvider before your own App ServiceProviders.
Laravel without auto-discovery:
If you don't use auto-discovery, add the ServiceProvider to the providers list. For Laravel 11 or newer, add the ServiceProvider in bootstrap/providers.php. For Laravel 10 or older, add the ServiceProvider in config/app.php.
Barryvdh\Debugbar\ServiceProvider::class,
If you want to use the facade to log messages, add this within the register
method of app/Providers/AppServiceProvider.php
class:
public function register(): void
{
$loader = \Illuminate\Foundation\AliasLoader::getInstance();
$loader->alias('Debugbar', \Barryvdh\Debugbar\Facades\Debugbar::class);
}
The profiler is enabled by default, if you have APP_DEBUG=true. You can override that in the config (debugbar.enabled
) or by setting DEBUGBAR_ENABLED
in your .env
. See more options in config/debugbar.php
You can also set in your config if you want to include/exclude the vendor files also (FontAwesome, Highlight.js and jQuery). If you already use them in your site, set it to false.
You can also only display the js or css vendors, by setting it to 'js' or 'css'. (Highlight.js requires both css + js, so set to true
for syntax highlighting)
Copy the package config to your local config with the publish command:
php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider"
Laravel with Octane:
Make sure to add LaravelDebugbar to your flush list in config/octane.php
.
'flush' => [
\Barryvdh\Debugbar\LaravelDebugbar::class,
],
Lumen:
For Lumen, register a different Provider in bootstrap/app.php
:
if (env('APP_DEBUG')) {
$app->register(Barryvdh\Debugbar\LumenServiceProvider::class);
}
To change the configuration, copy the file to your config folder and enable it:
$app->configure('debugbar');
Usage
You can now add messages using the Facade (when added), using the PSR-3 levels (debug, info, notice, warning, error, critical, alert, emergency):
Debugbar::info($object);
Debugbar::error('Error!');
Debugbar::warning('Watch outâ¦');
Debugbar::addMessage('Another message', 'mylabel');
And start/stop timing:
Debugbar::startMeasure('render','Time for rendering');
Debugbar::stopMeasure('render');
Debugbar::addMeasure('now', LARAVEL_START, microtime(true));
Debugbar::measure('My long operation', function() {
// Do somethingâ¦
});
Or log exceptions:
try {
throw new Exception('foobar');
} catch (Exception $e) {
Debugbar::addThrowable($e);
}
There are also helper functions available for the most common calls:
// All arguments will be dumped as a debug message
debug($var1, $someString, $intValue, $object);
// `$collection->debug()` will return the collection and dump it as a debug message. Like `$collection->dump()`
collect([$var1, $someString])->debug();
start_measure('render','Time for rendering');
stop_measure('render');
add_measure('now', LARAVEL_START, microtime(true));
measure('My long operation', function() {
// Do somethingâ¦
});
If you want you can add your own DataCollectors, through the Container or the Facade:
Debugbar::addCollector(new DebugBar\DataCollector\MessagesCollector('my_messages'));
//Or via the App container:
$debugbar = App::make('debugbar');
$debugbar->addCollector(new DebugBar\DataCollector\MessagesCollector('my_messages'));
By default, the Debugbar is injected just before </body>
. If you want to inject the Debugbar yourself,
set the config option 'inject' to false and use the renderer yourself and follow http://phpdebugbar.com/docs/rendering.html
$renderer = Debugbar::getJavascriptRenderer();
Note: Not using the auto-inject, will disable the Request information, because that is added After the response. You can add the default_request datacollector in the config as alternative.
Enabling/Disabling on run time
You can enable or disable the debugbar during run time.
\Debugbar::enable();
\Debugbar::disable();
NB. Once enabled, the collectors are added (and could produce extra overhead), so if you want to use the debugbar in production, disable in the config and only enable when needed.
Storage
Debugbar remembers previous requests, which you can view using the Browse button on the right. This will only work if you enable debugbar.storage.open
in the config.
Make sure you only do this on local development, because otherwise other people will be able to view previous requests.
In general, Debugbar should only be used locally or at least restricted by IP.
It's possible to pass a callback, which will receive the Request object, so you can determine access to the OpenHandler storage.
Twig Integration
Laravel Debugbar comes with two Twig Extensions. These are tested with rcrowe/TwigBridge 0.6.x
Add the following extensions to your TwigBridge config/extensions.php (or register the extensions manually)
'Barryvdh\Debugbar\Twig\Extension\Debug',
'Barryvdh\Debugbar\Twig\Extension\Dump',
'Barryvdh\Debugbar\Twig\Extension\Stopwatch',
The Dump extension will replace the dump function to output variables using the DataFormatter. The Debug extension adds a debug()
function which passes variables to the Message Collector,
instead of showing it directly in the template. It dumps the arguments, or when empty; all context variables.
{{ debug() }}
{{ debug(user, categories) }}
The Stopwatch extension adds a stopwatch tag similar to the one in Symfony/Silex Twigbridge.
{% stopwatch "foo" %}
â¦some things that gets timed
{% endstopwatch %}
Top Related Projects
PHP errors for cool kids
Clockwork - php dev tools in your browser - server-side component
A beautiful error page for Laravel apps
A MongoDB based Eloquent model and Query builder for Laravel (Moloquent)
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot