**Step 1**
Save somewhere in your project directory
**Step 2**
Add to your settings.py
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'utils.debug.UserBasedExceptionMiddleware',
)
Normal users will get your 500.html when debug = False, but If you are logged in as a super user then you get to see the stack trace in all its glory.
This middleware makes the admin error emails a lot more informative: you get the same HTML response that you get with `DEBUG=True`.
It uses the base class defined in [#638](http://www.djangosnippets.org/snippets/638/).
You will probably want to apply the patch for [#6748](http://code.djangoproject.com/ticket/6748) to help avoid slowdowns caused by unintentional database queries. As the ticket (and django-developers thread) notes, it isn't foolproof; you may still find this executing database queries.
The solution is based on [dballanc's snippet](http://www.djangosnippets.org/snippets/420/).
Can easily be combined with any of the [SQL tracing solutions](http://www.djangosnippets.org/tags/debug/).
You might want to run a separate logging server and redirect your logs there. Please refer to the [logging reference manual](http://docs.python.org/lib/module-logging.html).
Simple middelware that listens for redirect responses, store the request's query log in the session when it finds one, and starts the next request's log off with those queries from before the redirect.
Inspired by http://www.djangosnippets.org/snippets/159/
This context processor provides a new variable {{ sqldebug }}, which can
be used as follows:
{% if sqldebug %}...{% endif %}
{% if sqldebug.enabled %}...{% endif %}
This checks settings.SQL_DEBUG and settings.DEBUG. Both need to be True,
otherwise the above will evaluate to False and sql debugging is considered
to be disabled.
{{ sqldebug }}
This prints basic information like total number of queries and total time.
{{ sqldebug.time }}, {{ sqldebug.queries.count }}
Both pieces of data can be accessed manually as well.
{{ sqldebug.queries }}
Lists all queries as LI elements.
{% for q in sqldebug.queries %}
<li>{{ q.time }}: {{ q }}</li>
{% endfor %}
Queries can be iterated as well. The query is automatically escaped and contains
<wbr> tags to improve display of long queries. You can use {{ q.sql }} to access
the unmodified, raw query string.
Here's a more complex example. It the snippet from:
http://www.djangosnippets.org/snippets/93/
adjusted for this context processor.
{% if sqldebug %}
<div id="debug">
<p>
{{ sqldebug.queries.count }} Quer{{ sqldebug.queries|pluralize:"y,ies" }}, {{ sqldebug.time }} seconds
{% ifnotequal sql_queries|length 0 %}
(<span style="cursor: pointer;" onclick="var s=document.getElementById('debugQueryTable').style;s.display=s.display=='none'?'':'none';this.innerHTML=this.innerHTML=='Show'?'Hide':'Show';">Show</span>)
{% endifnotequal %}
</p>
<table id="debugQueryTable" style="display: none;">
<col width="1"></col>
<col></col>
<col width="1"></col>
<thead>
<tr>
<th scope="col">#</th>
<th scope="col">SQL</th>
<th scope="col">Time</th>
</tr>
</thead>
<tbody>
{% for query in sqldebug.queries %}<tr class="{% cycle odd,even %}">
<td>{{ forloop.counter }}</td>
<td>{{ query }}</td>
<td>{{ query.time }}</td>
</tr>{% endfor %}
</tbody>
</table>
</div>
{% endif %}
Use this to display a split of page execution time between python and the db in your base template when debugging.
I originally got the base of this code from another snippet, but I can't find it anymore and want to share with new folks because I find this handy.
This is based on [Snippet 161](/snippets/161/)
It marks duplicated SQL queries.
To avoid duplicates read:
[Caching and Queryset](http://www.djangoproject.com/documentation/db-api/#caching-and-querysets)
Sept. 07: Updated for current trunk: 'response' behaves like 'response.header'
22. October '07: Log into directory.
Simple template tag that allows you to inspect an object in the context for debugging. It will inspect django models and forms using introspection. Dicts and lists are formatted to truncate long data. Pretty much everything else just displays the __str__ representation + class name.
Example output: http://dsanity.net/introspectiontag.html
Usage:
put tag code as file introspection.py in your templatetags directory. Place the html template in your template path under "inspect_object.html".
Then in your template:
{% load introspection %}
{% inspect_object obj "test object" %}
The first parameter is the object to inspect, the second is the name used for display purposes.
Just put it in your python path and add it into MIDDLEWARE_CLASSES.
I know that there are a couple of snippets on this site that do something similar to this, but none of them quite suited me.
I wanted something that would indent and space the SQL so that I could differentiate it from the other output from the development server.
Also, I wanted something that would output total query execution time, which my solution does. I just hope that it's useful for someone else, too!
UPDATE: Now this should no longer get upset when running it on windows.
Displays hotshot profiling for any view.
http://yoursite.com/yourview/?prof
Add the "prof" key to query string by appending ?prof (or &prof=)
and you'll see the profiling results in your browser.
It's set up to only be available in django's debug mode,
but you really shouldn't add this middleware to any production configuration.
* Only tested on Linux
* You should probably use this one instead: http://djangosnippets.org/snippets/2126/
In development, we need a SMTP Server to see the results of send mail via SMTP protocol in Python application. Instead of configure a mail daemon, we could use this little script to receive the SMTP request, and save each session into an EML file. *.eml could be viewed with your favorite email client, you need not send them out.
[EML description](http://filext.com/detaillist.php?extdetail=EML)
**Update**: Fix bug for overwrite files when received multi-message in one SMTP session.
Here is a trivial way to keep your Django project in shared version control or in a public repository without exposing settings that could have security implications, and without needing to modify settings.py for your local test or production environments on checkout.
This is also a way to separate development settings from production settings, or to deploy the same code on multiple servers while only changing one site-specific "dotfile."
I often find something like this lurking at the end of my base templates - it'll show you which queries were run while generating the current page, but they'll start out hidden so as not to be a pain.
Of course, before this works, you'll need to satisfy all the criteria for getting debug information in your template context:
1. Have `'django.core.context_processors.debug'` in your `TEMPLATE_CONTEXT_PROCESSORS` setting (it was there in the default settings, last time I checked).
2. Have your current IP in your `INTERNAL_IPS` setting.
3. Use [RequestContext](http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext) when rendering the current template (if you're using a generic view, you're already using `RequestContext`).