DebugFooter middleware for django 1.0 and higher
Based on Snippet [766](http://www.djangosnippets.org/snippets/766/) & [799](http://www.djangosnippets.org/snippets/799/), edited for django 1.0 and higher.
- sql
- middleware
- debug
Based on Snippet [766](http://www.djangosnippets.org/snippets/766/) & [799](http://www.djangosnippets.org/snippets/799/), edited for django 1.0 and higher.
Tag to inspect template context, filter to inspect variable. Originally by denis, [http://www.djangosnippets.org/snippets/1550/](http://www.djangosnippets.org/snippets/1550/). This just extracts variables from the context to locals for quicker access and autocompletion (When using ipdb). Additionally, 'vars' holds context keys for quick reference to whats available in the template.
When running the Django development server, this middleware causes all executed SQL queries to get printed out to the console. This is based on [Snippet 161](http://www.djangosnippets.org/snippets/161/). The big difference is that 161 logs by adding stuff to your response text, which isn't very convenient IMO.
This snippet is a variation on snippet 1550 that works with the Eclipse pydev plugin. This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pydev_debug %}. Be sure to launch pydev in debugger mode first. Once you're in the debugger, you can explore the stack and quickly find which context variables are set. This can be especially useful inside for loops, etc., where you want to see how the templating code is mucking with the context. This can also be useful when your templates are ultimately rendered by code that might not understand very well, such as generics.
This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pdb_debug %}. You can then access your context variables using context.get(..) at the pdb prompt. Optionally, install the ipdb package for colors, completion, and more (easy_install ipdb).
I sometimes find that larger forms need data associated with them, but it's a bit of a pain to retype it each time when I'm debugging. The DebugForm base class lets you specify sets of testing data that will be inserted into your form if your project is in debug mode, randomly chosen from the DEBUG_DATA dict.
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.
Allows you to include globs of IP addresses in your INTERNAL_IPS. It's shell-style glob syntax (the [fnmatch module](http://docs.python.org/library/fnmatch.html)). This should be helpful with the [Debug Toolbar](http://github.com/robhudson/django-debug-toolbar/tree/master), among other things. Like [#1362](http://www.djangosnippets.org/snippets/1362/), but with no external dependencies.
http://steven.bitsetters.com/articles/2009/03/09/testing-email-registration-flows-in-django/ Testing email registration flows is typically a pain. Most of the time I just want to sign up with a test user, get the email link and finish the flow. I also want to be able to automate the whole process without having to write some SMTP code to check some mail box for the email. The best way I’ve found to do this is just to write out your emails to some file instead of actually sending them via SMTP when your testing. Below is some code to do just that. I’ve also created a Django management script that will open the last email sent out from your application, find the first link in it and open it in your web browser. Quite handy for following email registration links without logging into your email and clicking on them manually.
Simple debug middleware that uses [pycallgraph](http://pycallgraph.slowchop.com) to get a visual representation of the call graph, including number of calls and execution times. Usage: 1. Replace *myapp* in the snippet with the name of your application and or adjust include and exclude according to your needs 2. Add CallgraphMiddleware to your middlewares in settings.py 3. Append ?prof to any URL in your application to trigger the callgraph creation Each callgraph cerated will be named callgraph-*timestamp*.png. This is because multiple callgraphs will be created when a re-direction occurs for example.
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.
This shows a simple way of adding your project current SVN to the django debug toolbar by creating a custom debug panel.
a minor remix of simon's debug footer: <http://www.djangosnippets.org/snippets/766/> > 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). This version adds TextMate links : if you are working on your local machine and using TextMate you can click on the template paths and they will be opened in TextMate. This speeds up development time considerably ! also, this works with django 1.0 (simon's version got broke by the 'connect' refactor) update: the view function is now linked > 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.
Hi, I have developed a middleware that enables to view debugging information in production for a single user filtered by useragent or ip. The debug info is appended to the html code as a remark and can be viewed with a view source operation from the browser. Take a look at http://code.google.com/p/debugview/ Enjoy
A simple addition for the urls.py that exposes the 404/500 templates during development. This way you can test how those look. They're mounted under /404/ and /505/ respectively. Add this at the bottom of your main urls.py.
43 snippets posted so far.