Quite often, when you're building a Django site,

you need a sanity check on various bits and pieces.

Did that template actually get used?

How many queries did I run?

How long did all those queries take?

You could of course track all of these things down in the code and

log them out to a file of the terminal.

Raise your hand if you wanna do that?

Yeah, I don't either.

Thanks to Rob Hudson and many o we don't have to do all of that work.

Their project, Django Debug Toolbar, came out several years ago and

quickly became an indispensable part of many Django developers workflow.

Django Debug Toolbar provides us with a huge amount of valuable information

as we're building and yes, debugging our software.

Let's look at how to install and use it.

Installing Django Debug Toolbar is actually just remarkably simple.

It used to be a bit more involved and if you're working on an older Django project,

you might see more settings related to the toolbar.

In fact, we have to do a special thing now just because we're on workspaces but

I'll walk you through that in a minute.

We're gonna to start by installing the debug toolbar with pip.

So pip install django-debug-toolbar.

And I actually know that for running things in a new workspace, you don't see

this but I fork workspaces a whole lot when I'm creating these courses for you.

I need to install markdown too, so I'm gonna go ahead and do that.

All right, so we have two are installed and

now we need to go to our settings file.

Settings.pi and we're gonna come down here and in installed apps,

after static files, we're going to add debug toolbar.

And you can put it after courses if you want,

but I like to always have my own custom things that I built

listed last just because that way, I'm kinda know where things are.

You have to come in after static files though because Django the debug

toolbar needs some static files.

So here's the thing that's special that we have to add ourselves.

So, let me explain a bit of how this works.

Django debug toolbar expects that all the requests coming to your app,

it checks to make sure that the setting debug is set to true and

it also checks to make sure that you're coming from your localhost.

So from 127.0.0.1.

So, we can do this setting in two different ways.

First thing is we have to add in debug toolbar config.

And this is a dictionary.

So we have two settings that we can set,

one of these is show toolbar callback and the other is internal IPs.

Internal IPs is a little bit easier.

We can just do internal_IPs, and then this is set to a list of IPs.

So the one that we want to set it to is we'd want to have say, 127.01.01.1.

And maybe we don't wanna have ::1 for the IP6.

And then we can just do all zeroes and

everything's considered an internal IP, I do believe.

But, this is a little bit messy and it's a little weird.

So, instead of doing that one,

I'm actually going to do something that's arguably even more messy.

But, it's explicitly like weird so I'll remember to take it out.

So I'm gonna make a new key here that is SHOW_TOOLBAR_CALLBACK.

And so this is a function to be run to determine whether or

not to show the toolbar.

So this gonna be an actual function that you write or

this can be a dotted path to a function somewhere else.

I'm just gonna write a lambda and it's gonna get an argument.

I don't even care what the argument is, I just wanna return true.

All right, so, we added it to installed apps and

then simply because we're on work spaces, we added this.

You will not need these last three lines.

If you're working on your local machine, leave those out.

You don't need these at all.

And you don't want to put these on to a remote server.

All right, so we've saved that and now let's go run our server.

Oops, sorry I got to get into learning site.

And there we go.

And then we can preview our site on port 8000 and

look, here's our debug toolbar, isn't that cool?

So, this is our toolbar and one of the things that you know right away,

is that you can hide it by clicking this hide button.

And now you have this little tab that sticks out,

you can click that to bring out the toolbar again.

Django Debug Toolbar is really smart.

It will remember whether or not you wanted hidden.

And if you said to hide it, then it won't show up on page except there's a little

button and if you leave it open, then it'll be open all the pages.

So, let's look at what's below the hide button.

There's a lot of stuff here.

So this version's tab tells us the version of things that we are running.

So we have 1.4 the toolbar, 1.9 of Django and 3.5.0 of Python.

So that's cool.

The time tab tells us how long the page the pager whee're on took to render and

this is both in Python and in the browser.

So this is kinda cool.

You can kind of see like what's taken the most time,

look we're spending a whole lot of time in the CPU.

Maybe we can get rid of that kind of stuff.

Settings, it just shows you all of your settings.

There's a lot of settings.

Headers shows you the HTTP headers and

the WSGI environ settings for your current page, your current view.

Request, that's our next one and this shows us information about the request.

This is what view we're in, we're in the hello world view.

There were no arguments, there were no keyword arguments, and a URL name is home.

So this is really handy for debugging like how did I get the view that I'm in?

SQL shows us how many queries were run on the page that we're on.

So currently there was one query and it took 19 and a half milliseconds.

So that's cool.

And this cell, that shows you like what was actually run and everything.

And then the expel, E-X-P-L,

will show you the explanation of the query if your engine supports it.

So pretty handy.

We're gonna be using this panel a lot.

So just kinda get used to it.

Static files shows you all the static files that were loaded for

the particular page that you're on.

What's cool though,

is it shows you the apps that have static files that are being loaded.

And then also like, everywhere that's being looked at for static files and

all that stuff.

So this can be really really handy for debug.

Templates works very similarly.

These are the templates that were loaded.

So you can see that we loaded home.html,

we loaded layout.html, and we loaded coursenav.html.

And we also get the context processors that handle

putting things into the template.

If we had a cache, then the cache stuff would show up.

Signals run depending on what's happening in your Django app.

So like when you save a model, there is a pre-save and

post save signals that are fired off.

So the show you which signals are like

involved in the requests that we're currently on.

We'll, do more of these in a workshop or something later on.

And the last panel is this logging panel and if we were sending any messages out to

the logging system that Django go has, they would show up here.

Pretty handy to be able to see like I logged that but I can still look at it.

The last thing on the panel is this thing down here that has intercept redirects,

if you check this box.

And then you go to a view that would do a redirect.

So like you submit a form the form, hits the view the view is like yeah everything

is good and does a redirect to another page.

Checking that box would stop that redirect.

This is really handy, if you want to be able to see in the debug toolbar

what happens after your submit a post.

Most the time I leave this off until I need it because it's one of those thingsll

just get in your way.

And the checkmarks also let you turn off panels.

If you don't gonna be using them like if we don't care about the settings panel.

Then we can turn off the settings panel.

Sometimes that's handy sometimes it's not leave it up for you.

The debug panel will help us a lot with our Django development and fine tuning.

You should go do a search on pipe API for debug panel and

see just how many packages are out there to add new panels to the Django debug tool

bar I'll put a link to the toolbars documentation in the teachers note too