Getting Started

Configuration

Configure the Debugbar depending on your needs

There are a few things you can configure in the Debugbar. The configuration happens in two places:

  • in config/initializers/debugbar.rb for the general gem configuration
  • in a script tag in your page for some specific configuration

Enable/disable the Debugbar

You can enable/disable the Debugbar by setting the enabled option in the initializer:

1Debugbar.configure do |config|
2 config.enabled = false
3end

Ignoring requests

Once the debugbar is enabled, every request will be monitored and the debugbar will be displayed. You can ignore some requests by setting the ignore_request option in the initializer. This is typically useful to ignore some requests that are not relevant to you.

By default, the debugbar will ignore all requests starting with /assets or /_debugbar.

1Debugbar.configure do |config|
2 # Ignore all requests starting with /admin
3 config.ignore_request = -> (env) { env['PATH_INFO'].start_with? '/admin' }
4 
5 # Only log request to the API
6 config.ignore_request = -> (env) { not env['PATH_INFO'].start_with? '/api/v1' }
7 
8 # Ignore requests to admin, assets and debugbar
9 config.ignore_request = -> (env) do
10 [Debugbar.config.prefix, "/assets", "/admin"].any? do |pfx|
11 env['PATH_INFO'].start_with? pfx
12 end
13 end
14end

Using a different buffer

Whenever a request is made to the backend, the debugbar will store the data in a buffer. By default, the buffer is an in-memory buffer. You can use a different buffer by setting the buffer_adapter option in the initializer. So far, there is only a memory buffer and a null buffer.

A persisted buffer is coming to support Puma in cluster mode. Custom adapters will also be available.

1Debugbar.configure do |config|
2 config.buffer_adapter = :memory # Use a memory buffer
3 config.buffer_adapter = :null # Use a null buffer
4end

Enable/disable a feature

This is showed in the features] section, but generally, you can enable/disable a feature in the initializer. By default, all features are enabled if the underlying module is available. For example, Active Record is enabled if the ActiveRecord module is available.

1Debugbar.configure do |config|
2 config.active_record = false
3 config.cache = true
4end

Changing URL and port

By default, the frontend will connect to localhost:3000. If you use another port or a domain, you need to pass the URL to the frontend. If you use http polling, checkout this page.

With the ERB helper, you can pass a hash to override any configuration defined here.

1<%= debugbar_body cable: {url: "ws://something.test:3030"} %>

If you don't use the helper, you must define a _debugbarConfigOptions object.

1window._debugbarConfigOptions = {
2 cable: {
3 url: 'ws://something.test:3030'
4 },
5}

Using SSL

The configuration requires you to pass the entire URL so if you use SSL locally, so you can to use wss instead of ws. Us

1<%= debugbar_body cable: {url: "wss://localhost:3000"} %>
1window._debugbarConfigOptions = {
2 cable: {
3 url: 'wss://localhost:3000'
4 },
5}

Using another prefix

All endpoints added by the debugbar are prefixed with /_debugbar. It's unlikely that you'll need to change the prefix, but if you do, you can set the prefix option in the initializer.

If you change it, it also needs to be changed in the frontend configuration

1Debugbar.configure do |config|
2 config.prefix = '/custom-prefix'
3end
1<%= debugbar_body prefix: "/custom-prefix" %>

Custom default height

If you're working on a fairly big screen, you can configure the default height of the debugbar when it opens. Pass a value in pixel.

1<%= debugbar_body height: 800 %>

Or if you don't use the helper

1window._debugbarConfigOptions = {
2 height: 800,
3}