request_logger
Simple logger, stores all query parameter and post parameters for each query.
- debugging
- logger
Snippet List
One line SMTP sink server
Start simple SMTP server on localhost:25 and print to standard output all email headers and the email body. Useful for debugging outgoing mail without configuring SMTP daemon in development enviroment.
- debug
- smtp
- debugging
- debuggingserver
server with debugging backdoor
this starts up two servers - HTTP serving the django application on port 8000 and a port 8001 server that will start an interactive interpreter with any incoming connections. this enables you to have an interpreter in the same process as your server. $ wget http://localhost:8000/someurl/ (...) $ nc localhost 8001 Python 2.5.2 (r252:60911, Jul 8 2008, 21:21:10) [GCC 4.3.1 20080626 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.db import connection >>> connection.queries [ ... ]
- debugging
DebugFooter middleware
Adds a hidden footer to the bottom of every text/html page containing a list of SQL queries executed and templates that were loaded (including their full filesystem path to help debug complex template loading scenarios). To use, drop in to a file called 'debug_middleware.py' on your Python path and add 'debug_middleware.DebugFooter' to your MIDDLEWARE_CLASSES setting.
- sql
- middleware
- debugging
Debug SQL Query in Template
before this works, you'll need to satisfy all the criteria for getting debug information in your template context: Have 'django.core.context_processors.debug' in your TEMPLATE_CONTEXT_PROCESSORS setting (it was there in the default settings, last time I checked). Have your current IP in your INTERNAL_IPS setting. Use RequestContext when rendering the current template (if you're using a generic view, you're already using RequestContext). [Manuale Django](http://www.darioagliottone.it/django-guida/)
- sql
- template
- debug
- debugging
- sql_queries
Debug view: show available named URL patterns
Hook the show_url_patterns view function in to your URLconf to get a page which simply lists all of the named URL patterns in your system - useful for if your template developers need a quick reference as to what patterns they can use in the {% url %} tag.
- urlconf
- debug
- debugging
- urlpatterns
- documentation
- docs
logging to shell on dev server
You can customize the format. Also you can display variable values that support __str__ or another object-to-string method.
- debug
- debugging
- logging
Fetching list of SQL queries executed so far for all requests
These snippets together give you the ability to view all Django SQL queries executed across all incoming requests by visiting a particular URL (`/profiling` in the example). This is useful when developing with the Django test server. This is useful if most of the incoming requests are AJAX requests, because in such cases the debug toolbar will not be able to show which queries got executed. The `SqlProfilingMiddleware` class is the key one. At the end of every incoming request it appends the executed SQL queries to a static class member list. Any information request profiling information can be added in this way. The snippet does not add any security around viewing such information. This was done just to keep the code simple. But when implementing this you will definitely want to restrict access to this URL to only people allowed to view such information.
- sql
- debugging
- profiling
"Open file in Textmate"-support in werkzeug debugger browser view
1) Install django-extensions (requires werkzeug) 2) Paste snippet into settings.py 3) manage.py runserver_plus Now you should be able to open files in textmate by clicking the file links in the werkzeug error pages. It will also take you to the correct line number and highlight files that are in your project directory in a different color.
- debug
- error
- debugging
- textmate
Template tag to dump database query info
This snippet introduces two tags: `{%dbinfo%}` and `{%dbquerylist%}`. The `{%dbinfo%}` tag returns a string with the # of database queries and aggregate DB time. The `{%dbquerylist%}` tag expands to a set of <LI> elements containing the actual SQL queries executed. If `settings.TEMPLATE_DEBUG` is False, both tags return empty strings.
- tag
- db
- debugging
Firebug Lite Middleware
This middleware allows you to easily include the excellent debugging tool Firebug Lite in your projects. To install it, just add the middleware class to your list of installed middleware, pretty much anywhere in the list. If DEBUG is True, and your IP address is in the list of INTERNAL_IPS, Firebug Lite will load. It will, however, only load in browsers that are **not** Firefox, as I'm assuming that you have the **real** Firebug installed in Firefox. If you don't, go install it--what's wrong with you? Check out http://getfirebug.com/lite.html for more information.
- middleware
- debug
- ie
- debugging
- firebug
- msie
DebugFooter middleware with syntax highlighting and code inspection
based on Snippet [799](http://www.djangosnippets.org/snippets/799/) but added code inspection capabilities. Credit goes to django-logging for the actual inspection code. Got the idea from the [This Week in Django](http://blog.michaeltrier.com/2008/6/18/this-week-in-django-26-2008-06-16) Podcast ;) This adds the filename, lineno, functionname and the actual python-code line which caused a sql statement to be executed. Note that i am adding keys to 'connection.queries' dict on request, which may be dangerous, so use with care! The code inspection functionality can be toggled via FRAME_INSPECT.
- sql
- middleware
- debugging
Support IP ranges in INTERNAL_IPS
CIDR ( http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing ) is a well-known IP range syntax. This CIDR_LIST class can be used to make ranges of IPs considered "internal" for Django's debugging and security purposes. (Django only ever needs to do "ip in INTERNAL_IPS" so __contains__ is sufficient for the purpose.) For example, to make localhost and the entire block of 10.0.0.* considered to be internal, use: INTERNAL_IPS = CIDR_LIST([ '127.0.0.1', '10.0.0.0/24' ])
- debugging
- security
- ip
- cidr
- internal_ips
manage.py for eclipse with pydev debugging
This code is referenced in a [screencast](http://blog.vlku.com/index.php/2009/06/10/djangoeclipse-with-code-complete-screencast/) focused on showing a user how to configure Eclipse with PyDev to give you code complete, and breakpoints inside the IDE. It comes from a [2007 blog post](http://bear330.wordpress.com/2007/10/30/how-to-debug-django- web-application-with-autoreload/) (I've replicated it in case that post ever disappears.)
- debugging
- pydev
- eclipse
Technical 500 by group membership
Based loosely on [Eric's middleware](http://ericholscher.com/blog/2009/sep/5/debugging-django-production-revisited/), this middleware will show the technical 500 page (which you'd get if DEBUG == True) to any user who is (1) superuser and (2) a member of the settings.TECHNICAL_500_GROUP_NAME group. (If no setting exists, 'Technical Errors' is the presumed group name. I agreed with the comments that caching should be unnecessary given the (presumptive) edge case of exception + superuser. Assuming you don't have tons of superusers, this code is a good bit simpler.
- admin
- user
- auth
- debugging
- 500