The django debug screens are great, but only when you can see them. Trying to debug javascript/ajax calls can be kind of a pain. This just a copy/paste of some code in django's internals stuck in a middleware so that exceptions also print to the dev server console.
Peeping middleware, that replaces active user to another one for current http request. Admin permissions required to activate, so you can place this snippet even on the production server. Very useful for debugging purposes. Wish it to be part of Django. How to use: Put this middleware after all other middlewares in the list. Then just add ?as_user=username or &as_user=username to the url, where username is the name of user whose views you want to see.
This is an example middleware that is highly inspired by how Symfony handles [i18n in URLs](http://www.symfony-project.com/book/trunk/13-I18n-and-L10n#Changing the Culture for a User). You basically set a (?P<dj_culture>[\w-]+) pattern in your URL and this middleware will determine the language to use for the i18n toolkit for Django. It also removes the dj_culture parameter after dealing with it, so that you don't have to change all the views you want this middleware to work with.
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.
The XhtmlDegraderMiddleware class is designed to make it easier to deploy XHTML contents onto the World Wide Web. The correct MIME media type for sending XHTML is `application/xhtml+xml` -- the `text/html` media type is also acceptable provided [certain guidelines](http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines) are followed. The vast majority of web browsers released from 2002 onwards have good XHTML support; this includes Mozilla Firefox, Opera, and Apple Safari. Two notable exceptions are Internet Explorer 7.0 and Netscape Navigator 4.8; instead of displaying XHTML, they present the user with a download dialog instead. The role of the XHTML Degrader, then, is to automatically detect when browsers do not support XHTML, and to degrade the contents into something they're capable of rendering. **How it works** XhtmlDegraderMiddleware checks the content type of all HTTP responses. If the XHTML media type is set, the `Accept` request header is examined to determine whether the user agent actually supports XHTML. If so, the contents is sent unaltered. If not, a number of silent changes are made to make the response more friendly to XHTML-challenged browsers and web crawlers. Firstly, the `Content-Type` header is set to the HTML media type. Any XML processing instructions are removed, and a `DOCTYPE` is added if none is present. In the case of Internet Explorer, this should ensure the content is rendered in "standards compliance" mode. Empty elements are made to have a space before their trailing slash. N.B. If an HTTP response is already set to `text/html`, or set to any media type other than `application/xhtml+xml`, the middleware will have no effect. Note also that if you use GZipMiddleware, you should ensure that it appears in your MIDDLEWARE_CLASSES setting before XhtmlDegraderMiddleware, to allow the XHTML Degrader to act first.
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.
Originally posted on [skam.webfactional.com](http://skam.webfactional.com/blog/2007/07/16/babel-integration-django/) This is a very simple middleware that uses babel (http://babel.edgewall.org) for accessing locale data in request objects through request.LOCALE attribute. It also provides a function to get locale data outside views. settings.py: MIDDLEWARE_CLASSES = ( ... cut ... 'django.middleware.locale.LocaleMiddleware', 'middleware.locale.BabelMiddleware', ... cut ... )
This middleware fixes generation of URLs for admin interface and {% url %} resolving when you're mounting application to the subtree of site, e.g. if you use SCGIMount /prefix/ and serve application using SCGI, or if you use WSGI and want to bind Django application to some prefix.
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.
This is something we're using over at Curse to keep things clean and simple for our users. * We needed a url for any language code (which the domain provides) vs a cookie * We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code) This consists of two major modifications: * LANGUAGES in settings.py is a completely different format and would need changed based on your setup * the locale middleware has a couple absolute instances of where to point a user by default.
A handy ANSI-colored logging mechanism to display the SQL queries and times in the terminal when using django-admin.py runserver. DEBUG mode must be true for this to work.
This middleware remembers the last URLs that the user visited on your Django-site and saves them into the `request.session`. The fields are `currently_visiting` for the URL that is opened by the user and `last_visited` which is the URL before. Most of the time, you'll need only `last_visited`, as `currently_visiting` is just an implementation detail. For what is this good for? Imagine, you have to implement something like JavaScripts `history.back()` or `history.forward(-1)` but without JavaScript. Things start to get difficult when using JavaScript is not possible, for whatever reason. This snippet was created because I needed to redirect the user to the page he's been watching before clicking on the "translate" link. One other alternative would be adding the URL the user was visiting as a GET field to the "translate" link, but I hoped to find a possibility to avoid GET. This snippet works quite well as a proof of concept, the only known wart is when the user uses tabs or multible windows on the site, things get messed up. This cannot be solved, it's a restriction imposed by the design of HTTP.
1) You've ported an existing web site to Django. 2) The new site URLs don't have html (or htm) extensions. 3) The old site had URLs with html extensions. 4) You want existing bookmarks to work. Use this middleware to removes trailing .htm and .html extensions from incoming URLs (GETs only) so that your new site honors existing bookmarks. Locate it in settings.MIDDLEWARE_CLASSES near CommonMiddleware because it has similar middleware stack location requirements. If an incoming URL has an html extension, ZapDotHtmlMiddleware strips it out and redirects.
A little tiny middleware that, when used in multilingual sites, will make Django I18N ignore any `Accept-Language` headers in the request, thus ensuring that every first-time visitor (with no explicit language preference set via session or cookie) will see the site in the language specified by `settings.LANGUAGE_CODE`. (Please note that I think that overriding user preferences is generally a bad practice, but I had my reasons to use it :) )
This is some very simple middleware that keeps track of the last 3 succesful requests for each visitor. This can be useful if you want to redirect the visitor to a previous path without relying on a hidden field in a form, or if you simply want to check if a visitor has recently visited a certain path. Note that this relies on the session framework and visitors actually accepting cookies. This can be easily modified to hold more requests if you have a need for it.
181 snippets posted so far.