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.
You can customize the format. Also you can display variable values that support __str__ or another object-to-string method.
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/)
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.
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.
Put this decorator on any function to capture any exceptions generated within and print to a stack trace. example: @catch def my_func(): # code that may raise an exception here
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' ])
runserver with extra development tools: 1. interactive debugger that pops up automatically if an exception occurs, courtesy of [Werkzeug](http://werkzeug.pocoo.org/documentation/dev/debug.html#using-the-debugger) 2. logging of print statements directly into HTML (div float), courtesy of [Paste](http://pythonpaste.org/modules/debug.prints.html). Credits: [piranha.org.ua](http://piranha.org.ua/)
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.
A number of people have kindly posted snippets on how to use pdb/ipdb with django. However, this only works when running the django development server. I thought it would be nice to have a trace() command that would turn into a no-op when the development server is not running, so you wouldn't have to worry about leaving trace() commands in your code if you want to quickly test with mod_wsgi or mod_python. The code above attempts (on Posix-like systems) to determine if the development server is running (by quickly checking if "manage.py runserver" is in the process list), and sets a DJANGO_SERVER setting appropriately. Then when you import the trace() method, it is defined as set_trace() if DJANGO_SERVER is True, or a no-op if DJANGO_SERVER is False. When you hit the trace() in pdb/ipdb, enter "u" to go up to the calling trace() statement.
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.)
Add the line shown, or something similar, to your settings/dev.py, so that you can more clearly see when django is silently hiding errors in your template tags.
If you would like to see the latest queries you have done when running a unittest, this is not so easy. You have to initialize the queries list and set DEBUG to True manually. Then you have to figure out a way to print the queries you want to see just now and format them. I.e., monitoring queries when doing TDD is a bit of a hassle, and this should help. This little helper does all this for you; your UnitTest only needs to import django.db.connection and store the current length (offset) of the queries list. Then, using Python's coroutine functionality, all you have to do is send that offset to the QueryPrinter coroutine (which you can, for example, initialize as a global variable or a class variable of your UnitTest) and you get the latest SQL printed as a simple table.
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.
Simple logger, stores all query parameter and post parameters for each query.