static.static(prefix, view=django.views.static.serve, **kwargs) Helper function to return a URL pattern for serving files in debug mode: from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... the rest of your URLconf goes here ... ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

i18n_patterns(*urls, prefix_default_language=True) [source] This function can be used in a root URLconf and Django will automatically prepend the current active language code to all URL patterns defined within i18n_patterns(). Setting prefix_default_language to False removes the prefix from the default language (LANGUAGE_CODE). This can be useful when adding translations to existing site so that the current URLs won’t change. Example URL patterns: from django.conf.urls import include, url fr

HTTP clients can send a number of headers to tell the server about copies of a resource that they have already seen. This is commonly used when retrieving a Web page (using an HTTP GET request) to avoid sending all the data for something the client has already retrieved. However, the same headers can be used for all HTTP methods (POST, PUT, DELETE, etc.). For each page (response) that Django sends back from a view, it might provide two HTTP headers: the ETag header and the Last-Modified header.

django.conf.settings.configure(default_settings, **settings) Example: from django.conf import settings settings.configure(DEBUG=True) Pass configure() as many keyword arguments as you’d like, with each keyword argument representing a setting and its value. Each argument name should be all uppercase, with the same name as the settings described above. If a particular setting is not passed to configure() and is needed at some later point, Django will use the default setting value. Configurin

include(module, namespace=None, app_name=None) [source] include(pattern_list) include((pattern_list, app_namespace), namespace=None) include((pattern_list, app_namespace, instance_namespace)) A function that takes a full Python import path to another URLconf module that should be “included” in this place. Optionally, the application namespace and instance namespace where the entries will be included into can also be specified. Usually, the application namespace should be specified by t

This document describes Django’s built-in template tags and filters. It is recommended that you use the automatic documentation, if available, as this will also include documentation for any custom tags or filters installed. Built-in tag reference autoescape Controls the current auto-escaping behavior. This tag takes either on or off as an argument and that determines whether auto-escaping is in effect inside the block. The block is closed with an endautoescape ending tag. When auto-escaping is

The clickjacking middleware and decorators provide easy-to-use protection against clickjacking. This type of attack occurs when a malicious site tricks a user into clicking on a concealed element of another site which they have loaded in a hidden frame or iframe. An example of clickjacking Suppose an online store has a page where a logged in user can click “Buy Now” to purchase an item. A user has chosen to stay logged into the store all the time for convenience. An attacker site might create a

Class-based views API reference. For introductory material, see Using mixins with class-based views. Simple mixins Single object mixins Multiple object mixins Editing mixins Date-based mixins

A view is a callable which takes a request and returns a response. This can be more than just a function, and Django provides an example of some classes which can be used as views. These allow you to structure your views and reuse code by harnessing inheritance and mixins. There are also some generic views for simple tasks which we’ll get to later, but you may want to design your own structure of reusable views which suits your use case. For full details, see the class-based views reference doc

Writing Web applications can be monotonous, because we repeat certain patterns again and again. Django tries to take away some of that monotony at the model and template layers, but Web developers also experience this boredom at the view level. Django’s generic views were developed to ease that pain. They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to write too much code. We can recognize c