Great work, I'm definitely going to check this out. I'm coming from a Symfony background and the debug toolbar was _the_ thing I was missing in Django. Thanks for making it open source.
Julien Phalip
· 1 year ago
Wow, this looks really great, thanks for sharing! Just two comments: In 'debug_toolbar.panel.sql.py', you should maybe import Django's integrated version of simplejson (django.utils), so you wouldn't need to install it separately. Also, it'd be nice to add instructions on how to install the toolbar's media (css & js) in the README file. Again, congrats for your work, this is a fantastic debugging tool.
Rob Hudson
· 1 year ago
I'll definitely look into the simplejson tip, thanks. The media path for the toolbar files gets "injected" in the middleware during process_request, so there should be no setup for that.
Rinat
· 1 year ago
You can modify from: import simplejson to: from django.utils import simplejson
in: views.py, panels/sql.py
David, biologeek
· 1 year ago
What about an integration of logging output as a new panel? djangologging already has a nice css to render part of what is done with the debug toolbar.
CarlosC
· 1 year ago
Rocks! Like Firebug but for your model/logic/view. I wish more frameworks had it.
DJ
· 1 year ago
your freagin' awesome!
Anonymous
· 1 year ago
switch the orange to grey and drop the red on 'debug', looks much better
Rob Hudson
· 1 year ago
Yes, I should have mentioned it definitely needs some CSS help. Bryan Veloso is one person that's working on a better design. But the templates are easily overridable in your project.
Alex Gaynor
· 1 year ago
Hey, I was looking to add this into Pinax, however I ran into some issues with the JS, I was able to fix them with this diff: http://dpaste.com/79362/ . I'm also having some CSS issues, but I'm still tracking those down.
Empty
· 1 year ago
Rob, excellent work. This looks really nice and will be a regular staple for my Django projects. Thanks.
Neal
· 1 year ago
Some requirements and a screenshot would help. I'm familiar with firefox toolbars, and IE toolbars - but perhaps this is browser-independent? Which would be cool.
snirp
· 1 year ago
Neal: this just adds debugging information to a django project you are working on. It is not browser-related at all. However, the toolbar will of course show up in any browser.
Cezar
· 1 year ago
I had some unicode issues. Adding: encoding.smart_unicode(response.content) in middleware.py", line 69 solves my problems :)
Ross Bruniges
· 1 year ago
Not able to install it yet but if you still need some CSS done on it give me a shout and we can work the best way to do this!
Ari Flinkman
· 1 year ago
Nice. However, if I have the template debug panel enabled the whole dev server ends up in busyloop for 30 seconds, wait it out and it seems to work.
Rob Hudson
· 1 year ago
Would you be willing to share you template code and context, or provide a test case, to help try to debug this so it performs better for certain templates? I have no problems with the template panel in my projects so far.
Ari Flinkman
· 1 year ago
I'll try to isolate this. Actually, now that I've wrestled with this for a while I also have a different view which is similarily broken - except this time it happens with SQL panel.
In other news, I think DebugToolbarMiddleware's process_request modifies the urls every time there's no match, which ends up multiplying the existing urls. This is easily replicated with an empty project.
Jeff Croft
· 1 year ago
I've had this exact same problem (but overall, I LOVE the toolbar -- great work, guys!).
I've narrowed it down to this bit of the template panel template:
If I comment that out, it works fine (albeit without showing the context, which is one of the most useful bits!).
I have seen the SQL panel cause hangs, too, but this only seems to happen on pages with excessive queries (my fault, not yours, but it would be nice if it handled the situation a bit more gracefully).
Sidenote: If DEBUG=False, the debug toolbar throws loud, fatal type errors. I would assert that it should fail silently, and just do nothing (so that the page gets rendered as per usual, sans toolbar).
Again, great work! Despite a few looking issues, this is really, really great stuff. Thanks to everyone involved!
Michael Sanders
· 1 year ago
Great work, though I had trouble on Windows (error: bad group name) which was solved by editing the 'templates.html' template, changing:
{% for template in template_dirs %} <li>{{ template }}</li> {% endfor %}
to:
{% for template in template_dirs %} <li>{{ template|addslashes }}</li> {% endfor %}
i.e. adding '|addslashes' to the 'template' variable.
Arcady Chumachenko
· 1 year ago
Thanks, it looks great. Most useful are IMHO Queries and Cache tabs.
Hey Djangoians. Fellow Lawrencian here. I use Symfony nearly exclusively for my web project and love the developer toolbar. It will be a great addition to your framework. Enjoy.
Kurczak
· 1 year ago
I can't use jquery in my views after enabling Debug Toolbar Middleware. (the $ symbol is not recognized, changing $ to jquery also didn't help) Is there any solution to that problem?
Rob Hudson
· 1 year ago
We're looking into this problem. You might try checking out the "footer" branch on github which inserts the toolbar at the bottom of the HTML document rather than the top. This might fix the issue. Be aware, though, that the CSS isn't updated for that branch yet so the display may not be optimal. If you try it, let me know how it works. Either here or on IRC in the #django channel. Cheers!
Kurczak
· 1 year ago
Unfortunately it didn't help much. Maybe I should spend some time experimenting.
Rob Hudson
· 1 year ago
There was another fix recently that Alex Gaynor helped me with and someone else with this same problem confirmed the fix for. You might try the latest master branch to get the update. Thanks.
Kurczak
· 1 year ago
Now it works like a charm, and the green look is much better. this is amazing stuff.
Wojtek
· 1 year ago
Doesn't work for me. I've followed the installation guide but debug tool bar doesn't appear. :( No error messages, nothing.... any ideas?
Shimon Rura
· 1 year ago
This is extremely useful, easy to read, and easy to set up. Many many many thanks!
RJ Ryan
· 1 year ago
Thanks so much for this, I've been looking for something like this for a while.
sro
· 1 year ago
great work...
I was hoping to report (what appears to be) a bug. Let me know if there's anywhere to do that...
odio (dot) sam (a t) gmail (dot) com
Dave Lowe
· 1 year ago
Great work, Rob! This has become one of the essentials for any project I'm working on.
hollerith
· 1 year ago
you are a golden god
thank you so much!
GPRX
· 1 year ago
I followed all the instructions for installation but don't seem to be able to get the toolbar to appear, my development server is running on a remote machine and I have its IP and mine in the INTERNAL_IPS in settings.py. I don't have any errors when I run my server, any clues to what I might be missing?
tinio
· 1 year ago
Hi great work. Followed the instructions and got it to work using the django dev webserver. However, does it work if served through an apache/mod_python server? Couldn't get that part working, and was looking to get pointers from anyone who's had similar problems if it does support that setup.
tinio
· 1 year ago
For those who might have run into a similar problem, I got this to work by adding an ipv6 localhost address ::1 to INTERNAL_IPS as oppose to just ipv4 addresses
Chyssler
· 1 year ago
Nice, you could also add a profiling panel :)
josh
· 1 year ago
I think it's worth noting that the toolbar will not work with Django installations prior to Django 1.0.
matt
· 1 year ago
I followed the instructions and daat is "dumped", but not in the nice format shown above. Viewing the HTML - it looks as though it is trying to access a __debug__ directory that does not exist on my server. For example:
If I'm being dense forgive me. Any help would be greatly appreciated.
adam
· 7 months ago
I am having the same problem. Can anyone shed some light on how to fix this?
Matt
· 1 year ago
This is a great tool. I had to hack the the source code a bit to use in our debug server cluster. This allows me to specify a regex for IPs.
settings.py ================================ import re DEBUG_IPS = ( re.compile(r'^192.168.1.*'), ) ================================
Then in the middleware.py I changed the show_toolbar method:
================================ def show_toolbar(self, request): if not settings.DEBUG: return False if request.is_ajax(): return False for user_agent_regex in settings.DEBUG_IPS: if user_agent_regex.search(request.META['REMOTE_ADDR']): return True if not request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS: return False return True ================================
Thanks!
dan
· 1 year ago
where's the download link?
bosveld
· 1 year ago
1. The zip version (on git) didn't contain all the files. 2. Got all installed and have simple django app going but don't see the toolbar??
Using local test server. INTERNAL_IPS = INTERNAL_IPS = ('127.0.0.1',) & rest of settings as per setup
Any pointers would be appreciated as I am keen to have a look.
Many Thanks
bosveld
· 12 months ago
Found problem -- had to add html tags. I saw it was working fine in django admin but not in my app. After adding <html><header><body> tags it was ok, Thanks
Rob Hudson
· 12 months ago
Right, the toolbar middleware searches for the closing body tag and inserts its code before it, so the output has to be HTML and has to contain the closing body tag to work. XML output won't work, for example.
Joe
· 10 months ago
Hi,
Great piece of software. I just installed it today, and I'm trying to understand a problem. The number of SQL queries I see in the toolbar always appears to be less than the number being reported in the debug context (available in "templates/django.core.context_processors.debug". Two reasons that I can think of: 1) where you introduce the middleware matters---that is if comes after the session and authentication middleware, then the sql requests for those are not included, and 2) the debug panel triggers some queries of some sort? Number one appears to be true for certain; I moved the middleware insertion point around to see the effect, but it doesn't explain ALL of the differences. Can you clue me in if something else is going on?
Rob Hudson
· 10 months ago
Since middleware gets initialized at project runtime (not at request/response time), the ordering shouldn't matter that much.
One place that differs between the toolbar's way of getting queries and the context processor is if you call the context processor and iterate over its results in a template that continues to do template calls further down the template, you may miss some queries getting called since the context processor gathers up its queries at the time it's called. Versus the toolbar that gathers up its queries via the process_response hook in the middleware. But what I'm describing usually leads to more queries appearing in the toolbar, not less.
One area that may trigger extra queries is if the template context contains objects whose __str__ or __unicode__ methods execute queries. Since the toolbar is attempting to print the objects in the template context, this would trigger extra queries if those methods execute queries.
Joe
· 10 months ago
Thanks for the response. Yes, the authentication software does appear to trigger at least one query in one of its __unicode__ methods, so that answers that question.
As to the other--middleware placement--it does appear to make a difference. If I include the toolbar just before or right after the session/authentication middleware, the session/authentication queries show up in the tool bar, but not if I put it further down the list.
Again, thanks for this. It has been a great help so far.
davedash
· 9 months ago
Awesome, I am a symfony developer, and have ported parts of the toolbar to my django app, but you went the whole 9 yards. Thanks.
szinspire
· 9 months ago
very useful, thanks so much...
Ben
· 7 months ago
First, I love this. Let me just say that.
Second, I'm having a little trouble getting the cache watcher to work in development. I run memcached in production, and a database table based system in development. When I check the table in the DB I see that pages are caching, but I'm not seeing any results in the toolbar. Ideas on what I'm screwing up?
Thanks in advance everybody.
Federico Cáceres
· 7 months ago
This is one fantastic piece of app :D. It works like a charm, right out of the box, I love it when apps play well with my site.
I did modify the CSS a bit so that the bar aligns to the bottom instead of the top.
No issues until now, let me congratulate you and the rest for this great app. Thank you!
All Comments
Again, congrats for your work, this is a fantastic debugging tool.
import simplejson
to:
from django.utils import simplejson
in: views.py, panels/sql.py
Which would be cool.
encoding.smart_unicode(response.content)
in middleware.py", line 69 solves my problems :)
In other news, I think DebugToolbarMiddleware's process_request modifies the urls every time there's no match, which ends up multiplying the existing urls. This is easily replicated with an empty project.
I've narrowed it down to this bit of the template panel template:
<dd>
<div class="djTemplateShowContextDiv">Toggle Context</div>
<div class="djTemplateHideContextDiv" style="display:none;"><pre>{{ template.context }}</pre></div>
</dd>
If I comment that out, it works fine (albeit without showing the context, which is one of the most useful bits!).
I have seen the SQL panel cause hangs, too, but this only seems to happen on pages with excessive queries (my fault, not yours, but it would be nice if it handled the situation a bit more gracefully).
Sidenote: If DEBUG=False, the debug toolbar throws loud, fatal type errors. I would assert that it should fail silently, and just do nothing (so that the page gets rendered as per usual, sans toolbar).
Again, great work! Despite a few looking issues, this is really, really great stuff. Thanks to everyone involved!
{% for template in template_dirs %}
<li>{{ template }}</li>
{% endfor %}
to:
{% for template in template_dirs %}
<li>{{ template|addslashes }}</li>
{% endfor %}
i.e. adding '|addslashes' to the 'template' variable.
But it's nice you do it for django! :)
Is there any solution to that problem?
this is amazing stuff.
No error messages, nothing.... any ideas?
I was hoping to report (what appears to be) a bug. Let me know if there's anywhere to do that...
odio (dot) sam (a t) gmail (dot) com
thank you so much!
@import url(/__debug__/m/toolbar.min.css);
and
<script type="text/javascript" src="/__debug__/m/toolbar.min.js"></script>
If I'm being dense forgive me. Any help would be greatly appreciated.
settings.py
================================
import re
DEBUG_IPS = (
re.compile(r'^192.168.1.*'),
)
================================
Then in the middleware.py I changed the show_toolbar method:
================================
def show_toolbar(self, request):
if not settings.DEBUG:
return False
if request.is_ajax():
return False
for user_agent_regex in settings.DEBUG_IPS:
if user_agent_regex.search(request.META['REMOTE_ADDR']):
return True
if not request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS:
return False
return True
================================
Thanks!
2. Got all installed and have simple django app going but don't see the toolbar??
Using local test server.
INTERNAL_IPS = INTERNAL_IPS = ('127.0.0.1',)
& rest of settings as per setup
Any pointers would be appreciated as I am keen to have a look.
Many Thanks
I saw it was working fine in django admin but not in my app.
After adding <html><header><body> tags it was ok,
Thanks
Great piece of software. I just installed it today, and I'm trying to understand a problem. The number of SQL queries I see in the toolbar always appears to be less than the number being reported in the debug context (available in "templates/django.core.context_processors.debug". Two reasons that I can think of: 1) where you introduce the middleware matters---that is if comes after the session and authentication middleware, then the sql requests for those are not included, and 2) the debug panel triggers some queries of some sort? Number one appears to be true for certain; I moved the middleware insertion point around to see the effect, but it doesn't explain ALL of the differences. Can you clue me in if something else is going on?
One place that differs between the toolbar's way of getting queries and the context processor is if you call the context processor and iterate over its results in a template that continues to do template calls further down the template, you may miss some queries getting called since the context processor gathers up its queries at the time it's called. Versus the toolbar that gathers up its queries via the process_response hook in the middleware. But what I'm describing usually leads to more queries appearing in the toolbar, not less.
One area that may trigger extra queries is if the template context contains objects whose __str__ or __unicode__ methods execute queries. Since the toolbar is attempting to print the objects in the template context, this would trigger extra queries if those methods execute queries.
As to the other--middleware placement--it does appear to make a difference. If I include the toolbar just before or right after the session/authentication middleware, the session/authentication queries show up in the tool bar, but not if I put it further down the list.
Again, thanks for this. It has been a great help so far.
Second, I'm having a little trouble getting the cache watcher to work in development. I run memcached in production, and a database table based system in development. When I check the table in the DB I see that pages are caching, but I'm not seeing any results in the toolbar. Ideas on what I'm screwing up?
Thanks in advance everybody.
I did modify the CSS a bit so that the bar aligns to the bottom instead of the top.
No issues until now, let me congratulate you and the rest for this great app. Thank you!