mirror of https://github.com/django/django.git
Removed versionadded/changed annotations dating back to 1.4.
This commit is contained in:
parent
ef017a5f00
commit
7ee7599ab3
|
@ -333,8 +333,6 @@ Template filter code falls into one of two situations:
|
|||
Filters and time zones
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you write a custom filter that operates on :class:`~datetime.datetime`
|
||||
objects, you'll usually register it with the ``expects_localtime`` flag set to
|
||||
``True``:
|
||||
|
@ -764,8 +762,6 @@ Or, using decorator syntax:
|
|||
For more information on how the ``takes_context`` option works, see the section
|
||||
on :ref:`inclusion tags<howto-custom-template-tags-inclusion-tags>`.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you need to rename your tag, you can provide a custom name for it:
|
||||
|
||||
.. code-block:: python
|
||||
|
@ -776,8 +772,6 @@ If you need to rename your tag, you can provide a custom name for it:
|
|||
def some_function(value):
|
||||
return value - 2
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
``simple_tag`` functions may accept any number of positional or keyword
|
||||
arguments. For example:
|
||||
|
||||
|
@ -865,16 +859,14 @@ template loader, we'd register the tag like this:
|
|||
# Here, register is a django.template.Library instance, as before
|
||||
register.inclusion_tag('results.html')(show_results)
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Alternatively it is possible to register the inclusion tag using a
|
||||
:class:`django.template.Template` instance:
|
||||
|
||||
Alternatively it is possible to register the inclusion tag using a
|
||||
:class:`django.template.Template` instance:
|
||||
.. code-block:: python
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from django.template.loader import get_template
|
||||
t = get_template('results.html')
|
||||
register.inclusion_tag(t)(show_results)
|
||||
from django.template.loader import get_template
|
||||
t = get_template('results.html')
|
||||
register.inclusion_tag(t)(show_results)
|
||||
|
||||
As always, decorator syntax works as well, so we could have written:
|
||||
|
||||
|
@ -932,8 +924,6 @@ The ``takes_context`` parameter defaults to ``False``. When it's set to
|
|||
``True``, the tag is passed the context object, as in this example. That's the
|
||||
only difference between this case and the previous ``inclusion_tag`` example.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
``inclusion_tag`` functions may accept any number of positional or keyword
|
||||
arguments. For example:
|
||||
|
||||
|
@ -1046,8 +1036,6 @@ context-updating template tag, you might want to consider using an
|
|||
Assignment tags
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
To ease the creation of tags setting a variable in the context, Django provides
|
||||
a helper function, ``assignment_tag``. This function works the same way as
|
||||
:ref:`simple_tag<howto-custom-template-tags-simple-tags>`, except that it
|
||||
|
|
|
@ -28,8 +28,6 @@ callable object which the webserver uses to communicate with your code. This is
|
|||
commonly specified as an object named ``application`` in a Python module
|
||||
accessible to the server.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
The :djadmin:`startproject` command creates a :file:`projectname/wsgi.py` that
|
||||
contains such an application callable.
|
||||
|
||||
|
|
|
@ -106,8 +106,6 @@ The best way to disable this behavior is to set
|
|||
Filtering error reports
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Filtering sensitive information
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -185,15 +183,11 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
|
|||
def my_view(request):
|
||||
...
|
||||
|
||||
.. note::
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Since version 1.4, all POST parameters are systematically filtered out of
|
||||
error reports for certain :mod:`django.contrib.auth.views` views (
|
||||
``login``, ``password_reset_confirm``, ``password_change``, and
|
||||
``add_view`` and ``user_change_password`` in the ``auth`` admin) to prevent
|
||||
the leaking of sensitive information such as user passwords.
|
||||
All POST parameters are systematically filtered out of error reports for
|
||||
certain :mod:`django.contrib.auth.views` views (``login``,
|
||||
``password_reset_confirm``, ``password_change``, and ``add_view`` and
|
||||
``user_change_password`` in the ``auth`` admin) to prevent the leaking of
|
||||
sensitive information such as user passwords.
|
||||
|
||||
.. _custom-error-reports:
|
||||
|
||||
|
|
|
@ -40,11 +40,6 @@ FormMixin
|
|||
Retrieve initial data for the form. By default, returns a copy of
|
||||
:attr:`~django.views.generic.edit.FormMixin.initial`.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
In Django 1.3, this method was returning the
|
||||
:attr:`~django.views.generic.edit.FormMixin.initial` class variable
|
||||
itself.
|
||||
|
||||
.. method:: get_form_class()
|
||||
|
||||
Retrieve the form class to instantiate. By default
|
||||
|
|
|
@ -31,15 +31,11 @@ SingleObjectMixin
|
|||
|
||||
.. attribute:: slug_url_kwarg
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The name of the URLConf keyword argument that contains the slug. By
|
||||
default, ``slug_url_kwarg`` is ``'slug'``.
|
||||
|
||||
.. attribute:: pk_url_kwarg
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The name of the URLConf keyword argument that contains the primary key.
|
||||
By default, ``pk_url_kwarg`` is ``'pk'``.
|
||||
|
||||
|
|
|
@ -10,9 +10,6 @@ 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.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
The clickjacking middleware and decorators were added.
|
||||
|
||||
.. _clickjacking: http://en.wikipedia.org/wiki/Clickjacking
|
||||
|
||||
An example of clickjacking
|
||||
|
|
|
@ -180,8 +180,6 @@ subclass::
|
|||
values defined in :attr:`ModelAdmin.readonly_fields` to be displayed as
|
||||
read-only.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
To display multiple fields on the same line, wrap those fields in their own
|
||||
tuple. In this example, the ``url`` and ``title`` fields will display on the
|
||||
same line and the ``content`` field will be displayed below them in its
|
||||
|
@ -586,8 +584,6 @@ subclass::
|
|||
class PersonAdmin(UserAdmin):
|
||||
list_filter = ('company__name',)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
* a class inheriting from :mod:`django.contrib.admin.SimpleListFilter`,
|
||||
which you need to provide the ``title`` and ``parameter_name``
|
||||
attributes to and override the ``lookups`` and ``queryset`` methods,
|
||||
|
@ -673,8 +669,6 @@ subclass::
|
|||
birthday__lte=date(1999, 12, 31)).exists():
|
||||
yield ('90s', _('in the nineties'))
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
* a tuple, where the first element is a field name and the second
|
||||
element is a class inheriting from
|
||||
:mod:`django.contrib.admin.FieldListFilter`, for example::
|
||||
|
@ -691,8 +685,6 @@ subclass::
|
|||
The ``FieldListFilter`` API is considered internal and might be
|
||||
changed.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
It is possible to specify a custom template for rendering a list filter::
|
||||
|
||||
class FilterWithCustomTemplate(SimpleListFilter):
|
||||
|
@ -703,8 +695,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.list_max_show_all
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Set ``list_max_show_all`` to control how many items can appear on a "Show
|
||||
all" admin change list page. The admin will display a "Show all" link on the
|
||||
change list only if the total result count is less than or equal to this
|
||||
|
@ -738,15 +728,9 @@ subclass::
|
|||
If this isn't provided, the Django admin will use the model's default
|
||||
ordering.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you need to specify a dynamic order (for example depending on user or
|
||||
language) you can implement a :meth:`~ModelAdmin.get_ordering` method.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Django honors all elements in the list/tuple; before 1.4, only the first
|
||||
was respected.
|
||||
|
||||
.. attribute:: ModelAdmin.paginator
|
||||
|
||||
|
@ -1017,8 +1001,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_ordering(self, request)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``get_ordering`` method takes a``request`` as parameter and
|
||||
is expected to return a ``list`` or ``tuple`` for ordering similar
|
||||
to the :attr:`ordering` attribute. For example::
|
||||
|
@ -1033,8 +1015,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.save_related(self, request, form, formsets, change)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``save_related`` method is given the ``HttpRequest``, the parent
|
||||
``ModelForm`` instance, the list of inline formsets and a boolean value
|
||||
based on whether the parent is being added or changed. Here you can do any
|
||||
|
@ -1050,8 +1030,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_prepopulated_fields(self, request, obj=None)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``get_prepopulated_fields`` method is given the ``HttpRequest`` and the
|
||||
``obj`` being edited (or ``None`` on an add form) and is expected to return
|
||||
a ``dictionary``, as described above in the :attr:`ModelAdmin.prepopulated_fields`
|
||||
|
@ -1059,8 +1037,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_list_display(self, request)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``get_list_display`` method is given the ``HttpRequest`` and is
|
||||
expected to return a ``list`` or ``tuple`` of field names that will be
|
||||
displayed on the changelist view as described above in the
|
||||
|
@ -1068,8 +1044,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_list_display_links(self, request, list_display)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``get_list_display_links`` method is given the ``HttpRequest`` and
|
||||
the ``list`` or ``tuple`` returned by :meth:`ModelAdmin.get_list_display`.
|
||||
It is expected to return a ``list`` or ``tuple`` of field names on the
|
||||
|
@ -1341,10 +1315,6 @@ Other methods
|
|||
|
||||
Django view for the model instance edition page. See note below.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
The ``form_url`` parameter was added.
|
||||
|
||||
.. method:: ModelAdmin.changelist_view(self, request, extra_context=None)
|
||||
|
||||
Django view for the model instances change list/actions page. See note
|
||||
|
@ -1386,12 +1356,10 @@ provided some extra mapping data that would not otherwise be available::
|
|||
return super(MyModelAdmin, self).change_view(request, object_id,
|
||||
form_url, extra_context=extra_context)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
These views now return :class:`~django.template.response.TemplateResponse`
|
||||
These views return :class:`~django.template.response.TemplateResponse`
|
||||
instances which allow you to easily customize the response data before
|
||||
rendering. For more details, see the
|
||||
:doc:`TemplateResponse documentation </ref/template-response>`.
|
||||
rendering. For more details, see the :doc:`TemplateResponse documentation
|
||||
</ref/template-response>`.
|
||||
|
||||
.. _modeladmin-media-definitions:
|
||||
|
||||
|
@ -1514,9 +1482,6 @@ adds some of its own (the shared features are actually defined in the
|
|||
- :attr:`~InlineModelAdmin.raw_id_fields`
|
||||
- :meth:`~ModelAdmin.formfield_for_foreignkey`
|
||||
- :meth:`~ModelAdmin.formfield_for_manytomany`
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
- :meth:`~ModelAdmin.has_add_permission`
|
||||
- :meth:`~ModelAdmin.has_change_permission`
|
||||
- :meth:`~ModelAdmin.has_delete_permission`
|
||||
|
@ -2043,8 +2008,6 @@ your URLconf. Specifically, add these four patterns:
|
|||
the URLs starting with ``^admin/`` before the line that includes the admin app
|
||||
itself).
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
The presence of the ``admin_password_reset`` named URL will cause a "forgotten
|
||||
your password?" link to appear on the default admin log-in page under the
|
||||
password box.
|
||||
|
@ -2108,8 +2071,6 @@ if you specifically wanted the admin view from the admin instance named
|
|||
For more details, see the documentation on :ref:`reversing namespaced URLs
|
||||
<topics-http-reversing-url-namespaces>`.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
To allow easier reversing of the admin urls in templates, Django provides an
|
||||
``admin_urlname`` filter which takes an action as argument:
|
||||
|
||||
|
|
|
@ -222,11 +222,6 @@ Manager methods
|
|||
|
||||
.. method:: create_user(username, email=None, password=None)
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The ``email`` parameter was made optional. The username
|
||||
parameter is now checked for emptiness and raises a
|
||||
:exc:`~exceptions.ValueError` in case of a negative result.
|
||||
|
||||
Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
|
||||
|
||||
The :attr:`~django.contrib.auth.models.User.username` and
|
||||
|
|
|
@ -410,8 +410,6 @@ Utilities
|
|||
|
||||
.. function:: ensure_csrf_cookie(view)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This decorator forces a view to send the CSRF cookie.
|
||||
|
||||
Scenarios
|
||||
|
@ -517,8 +515,6 @@ whatever you want.
|
|||
CSRF_COOKIE_PATH
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the CSRF cookie. This should either match the URL path of your
|
||||
|
@ -531,8 +527,6 @@ its own CSRF cookie.
|
|||
CSRF_COOKIE_SECURE
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use a secure cookie for the CSRF cookie. If this is set to ``True``,
|
||||
|
|
|
@ -117,17 +117,9 @@ can do all of the work.
|
|||
:class:`~django.template.RequestContext` in rendering the
|
||||
template.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The middleware will only add a trailing slash and redirect (by looking
|
||||
at the :setting:`APPEND_SLASH` setting) if the resulting URL refers to
|
||||
a valid flatpage. Previously requesting a non-existent flatpage
|
||||
would redirect to the same URL with an apppended slash first and
|
||||
subsequently raise a 404.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Redirects by the middleware are permanent (301 status code) instead of
|
||||
temporary (302) to match behavior of the
|
||||
:class:`~django.middleware.common.CommonMiddleware`.
|
||||
The middleware will only add a trailing slash and redirect (by looking
|
||||
at the :setting:`APPEND_SLASH` setting) if the resulting URL refers to
|
||||
a valid flatpage. Redirects are permanent (301 status code).
|
||||
|
||||
If it doesn't find a match, the request continues to be processed as usual.
|
||||
|
||||
|
|
|
@ -100,10 +100,8 @@ Examples (when 'today' is 17 Feb 2007):
|
|||
naturaltime
|
||||
-----------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
For datetime values, returns a string representing how many seconds,
|
||||
minutes or hours ago it was -- falling back to the :tfilter:`timesince`
|
||||
minutes or hours ago it was -- falling back to the :tfilter:`timesince`
|
||||
format if the value is more than a day old. In case the datetime value is in
|
||||
the future the return value will automatically use an appropriate phrase.
|
||||
|
||||
|
|
|
@ -213,8 +213,6 @@ Sitemap class reference
|
|||
|
||||
.. attribute:: Sitemap.protocol
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
**Optional.**
|
||||
|
||||
This attribute defines the protocol (``'http'`` or ``'https'``) of the
|
||||
|
@ -308,8 +306,6 @@ You should create an index file if one of your sitemaps has more than 50,000
|
|||
URLs. In this case, Django will automatically paginate the sitemap, and the
|
||||
index will reflect that.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you're not using the vanilla sitemap view -- for example, if it's wrapped
|
||||
with a caching decorator -- you must name your sitemap view and pass
|
||||
``sitemap_url_name`` to the index view::
|
||||
|
@ -346,12 +342,10 @@ parameter to the ``sitemap`` and ``index`` views via the URLconf::
|
|||
)
|
||||
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
In addition, these views also return
|
||||
:class:`~django.template.response.TemplateResponse`
|
||||
instances which allow you to easily customize the response data before
|
||||
rendering. For more details, see the
|
||||
:doc:`TemplateResponse documentation </ref/template-response>`.
|
||||
These views return :class:`~django.template.response.TemplateResponse`
|
||||
instances which allow you to easily customize the response data before
|
||||
rendering. For more details, see the :doc:`TemplateResponse documentation
|
||||
</ref/template-response>`.
|
||||
|
||||
Context variables
|
||||
------------------
|
||||
|
@ -378,8 +372,6 @@ sitemap. Each URL exposes attributes as defined in the
|
|||
- ``location``
|
||||
- ``priority``
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``item`` attribute has been added for each URL to allow more flexible
|
||||
customization of the templates, such as `Google news sitemaps`_. Assuming
|
||||
Sitemap's :attr:`~Sitemap.items()` would return a list of items with
|
||||
|
|
|
@ -82,8 +82,6 @@ Default: ``'django.contrib.staticfiles.storage.StaticFilesStorage'``
|
|||
The file storage engine to use when collecting static files with the
|
||||
:djadmin:`collectstatic` management command.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
A ready-to-use instance of the storage backend defined in this setting
|
||||
can be found at ``django.contrib.staticfiles.storage.staticfiles_storage``.
|
||||
|
||||
|
@ -146,8 +144,6 @@ Files are searched by using the :setting:`enabled finders
|
|||
:setting:`STATICFILES_DIRS` and in the ``'static'`` directory of apps
|
||||
specified by the :setting:`INSTALLED_APPS` setting.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The :djadmin:`collectstatic` management command calls the
|
||||
:meth:`~django.contrib.staticfiles.storage.StaticFilesStorage.post_process`
|
||||
method of the :setting:`STATICFILES_STORAGE` after each run and passes
|
||||
|
@ -176,8 +172,6 @@ Some commonly used options are:
|
|||
.. django-admin-option:: -c
|
||||
.. django-admin-option:: --clear
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Clear the existing files before trying to copy or link the original file.
|
||||
|
||||
.. django-admin-option:: -l
|
||||
|
@ -187,8 +181,6 @@ Some commonly used options are:
|
|||
|
||||
.. django-admin-option:: --no-post-process
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Don't call the
|
||||
:meth:`~django.contrib.staticfiles.storage.StaticFilesStorage.post_process`
|
||||
method of the configured :setting:`STATICFILES_STORAGE` storage backend.
|
||||
|
@ -276,8 +268,6 @@ StaticFilesStorage
|
|||
|
||||
.. method:: post_process(paths, **options)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This method is called by the :djadmin:`collectstatic` management command
|
||||
after each run and gets passed the local storages and paths of found
|
||||
files as a dictionary, as well as the command line options.
|
||||
|
@ -291,8 +281,6 @@ CachedStaticFilesStorage
|
|||
|
||||
.. class:: storage.CachedStaticFilesStorage
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
A subclass of the :class:`~django.contrib.staticfiles.storage.StaticFilesStorage`
|
||||
storage backend which caches the files it saves by appending the MD5 hash
|
||||
of the file's content to the filename. For example, the file
|
||||
|
@ -370,8 +358,6 @@ static
|
|||
|
||||
.. templatetag:: staticfiles-static
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Uses the configured :setting:`STATICFILES_STORAGE` storage to create the
|
||||
full URL for the given relative path, e.g.:
|
||||
|
||||
|
|
|
@ -16,8 +16,6 @@ documentation or reference manuals.
|
|||
PostgreSQL notes
|
||||
================
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Django supports PostgreSQL 8.2 and higher.
|
||||
|
||||
PostgreSQL 8.2 to 8.2.4
|
||||
|
@ -173,18 +171,6 @@ running ``syncdb``::
|
|||
1005, "Can't create table '\\db_name\\.#sql-4a8_ab' (errno: 150)"
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
In previous versions of Django, fixtures with forward references (i.e.
|
||||
relations to rows that have not yet been inserted into the database) would fail
|
||||
to load when using the InnoDB storage engine. This was due to the fact that InnoDB
|
||||
deviates from the SQL standard by checking foreign key constraints immediately
|
||||
instead of deferring the check until the transaction is committed. This
|
||||
problem has been resolved in Django 1.4. Fixture data is now loaded with foreign key
|
||||
checks turned off; foreign key checks are then re-enabled when the data has
|
||||
finished loading, at which point the entire table is checked for invalid foreign
|
||||
key references and an `IntegrityError` is raised if any are found.
|
||||
|
||||
.. _storage engines: http://dev.mysql.com/doc/refman/5.5/en/storage-engines.html
|
||||
.. _MyISAM: http://dev.mysql.com/doc/refman/5.5/en/myisam-storage-engine.html
|
||||
.. _InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb.html
|
||||
|
|
|
@ -466,8 +466,6 @@ several lines in language files.
|
|||
|
||||
.. django-admin-option:: --no-location
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Use the ``--no-location`` option to not write '``#: filename:line``'
|
||||
comment lines in language files. Note that using this option makes it harder
|
||||
for technically skilled translators to understand each message's context.
|
||||
|
@ -482,9 +480,8 @@ supports the FastCGI protocol. See the :doc:`FastCGI deployment documentation
|
|||
</howto/deployment/fastcgi>` for details. Requires the Python FastCGI module from
|
||||
`flup`_.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
Internally, this wraps the WSGI application object specified by the
|
||||
:setting:`WSGI_APPLICATION` setting.
|
||||
Internally, this wraps the WSGI application object specified by the
|
||||
:setting:`WSGI_APPLICATION` setting.
|
||||
|
||||
.. _flup: http://www.saddi.com/software/flup/
|
||||
|
||||
|
@ -610,9 +607,8 @@ If you run this script as a user with normal privileges (recommended), you
|
|||
might not have access to start a port on a low port number. Low port numbers
|
||||
are reserved for the superuser (root).
|
||||
|
||||
.. versionadded:: 1.4
|
||||
This server uses the WSGI application object specified by the
|
||||
:setting:`WSGI_APPLICATION` setting.
|
||||
This server uses the WSGI application object specified by the
|
||||
:setting:`WSGI_APPLICATION` setting.
|
||||
|
||||
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
||||
security audits or performance tests. (And that's how it's gonna stay. We're in
|
||||
|
@ -658,11 +654,8 @@ Example usage::
|
|||
|
||||
.. django-admin-option:: --nothreading
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Since version 1.4, the development server is multithreaded by default.
|
||||
Use the ``--nothreading`` option to disable the use of threading in the
|
||||
development server.
|
||||
The development server is multithreaded by default. Use the ``--nothreading``
|
||||
option to disable the use of threading in the development server.
|
||||
|
||||
.. django-admin-option:: --ipv6, -6
|
||||
|
||||
|
@ -856,8 +849,6 @@ startapp <appname> [destination]
|
|||
Creates a Django app directory structure for the given app name in the current
|
||||
directory or the given destination.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
By default the directory created contains a ``models.py`` file and other app
|
||||
template files. (See the `source`_ for more details.) If only the app
|
||||
name is given, the app directory will be created in the current working
|
||||
|
@ -871,7 +862,6 @@ For example::
|
|||
|
||||
django-admin.py startapp myapp /Users/jezdez/Code/myapp
|
||||
|
||||
.. versionadded:: 1.4
|
||||
.. django-admin-option:: --template
|
||||
|
||||
With the ``--template`` option, you can use a custom app template by providing
|
||||
|
@ -893,8 +883,6 @@ zip files, you can use a URL like::
|
|||
|
||||
django-admin.py startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
When Django copies the app template files, it also renders certain files
|
||||
through the template engine: the files whose extensions match the
|
||||
``--extension`` option (``py`` by default) and the files whose names are passed
|
||||
|
@ -929,8 +917,6 @@ startproject <projectname> [destination]
|
|||
Creates a Django project directory structure for the given project name in
|
||||
the current directory or the given destination.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
By default, the new directory contains ``manage.py`` and a project package
|
||||
(containing a ``settings.py`` and other files). See the `template source`_ for
|
||||
details.
|
||||
|
@ -947,8 +933,6 @@ For example::
|
|||
|
||||
django-admin.py startproject myproject /Users/jezdez/Code/myproject_repo
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
As with the :djadmin:`startapp` command, the ``--template`` option lets you
|
||||
specify a directory, file path or URL of a custom project template. See the
|
||||
:djadmin:`startapp` documentation for details of supported project template
|
||||
|
@ -1044,14 +1028,12 @@ information.
|
|||
The ``--failfast`` option can be used to stop running tests and report the
|
||||
failure immediately after a test fails.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
.. django-admin-option:: --testrunner
|
||||
|
||||
The ``--testrunner`` option can be used to control the test runner class that
|
||||
is used to execute tests. If this value is provided, it overrides the value
|
||||
provided by the :setting:`TEST_RUNNER` setting.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
.. django-admin-option:: --liveserver
|
||||
|
||||
The ``--liveserver`` option can be used to override the default address where
|
||||
|
@ -1152,8 +1134,6 @@ the user given as parameter. If they both match, the new password will be
|
|||
changed immediately. If you do not supply a user, the command will attempt to
|
||||
change the password whose username matches the current user.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Use the ``--database`` option to specify the database to query for the user. If
|
||||
it's not supplied, Django will use the ``default`` database.
|
||||
|
||||
|
@ -1187,8 +1167,6 @@ using the ``--username`` and ``--email`` arguments on the command
|
|||
line. If either of those is not supplied, ``createsuperuser`` will prompt for
|
||||
it when running interactively.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Use the ``--database`` option to specify the database into which the superuser
|
||||
object will be saved.
|
||||
|
||||
|
|
|
@ -654,8 +654,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
``GenericIPAddressField``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. class:: GenericIPAddressField(**kwargs)
|
||||
|
||||
A field containing either an IPv4 or an IPv6 address.
|
||||
|
|
|
@ -542,8 +542,6 @@ Selector and checkbox widgets
|
|||
...
|
||||
</ul>
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
For more granular control over the generated markup, you can loop over the
|
||||
radio buttons in the template. Assuming a form ``myform`` with a field
|
||||
``beatles`` that uses a ``RadioSelect`` as its widget:
|
||||
|
|
|
@ -222,7 +222,4 @@ X-Frame-Options middleware
|
|||
|
||||
.. class:: XFrameOptionsMiddleware
|
||||
|
||||
.. versionadded:: 1.4
|
||||
``XFrameOptionsMiddleware`` was added.
|
||||
|
||||
Simple :doc:`clickjacking protection via the X-Frame-Options header </ref/clickjacking/>`.
|
||||
|
|
|
@ -804,8 +804,6 @@ for this field is a :class:`~django.forms.TextInput`.
|
|||
|
||||
.. class:: GenericIPAddressField([protocol=both, unpack_ipv4=False, **options])
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
An IPv4 or IPv6 address, in string format (e.g. ``192.0.2.30`` or
|
||||
``2a02:42fe::4``). The default form widget for this field is a
|
||||
:class:`~django.forms.TextInput`.
|
||||
|
|
|
@ -209,10 +209,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
ordering = ['-pub_date', 'author']
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The Django admin honors all elements in the list/tuple; before 1.4, only
|
||||
the first one was respected.
|
||||
|
||||
``permissions``
|
||||
---------------
|
||||
|
||||
|
|
|
@ -378,16 +378,12 @@ query spans multiple tables, it's possible to get duplicate results when a
|
|||
:meth:`values()` together, be careful when ordering by fields not in the
|
||||
:meth:`values()` call.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
As of Django 1.4, you can pass positional arguments (``*fields``) in order to
|
||||
specify the names of fields to which the ``DISTINCT`` should apply. This
|
||||
translates to a ``SELECT DISTINCT ON`` SQL query.
|
||||
|
||||
Here's the difference. For a normal ``distinct()`` call, the database compares
|
||||
*each* field in each row when determining which rows are distinct. For a
|
||||
``distinct()`` call with specified field names, the database will only compare
|
||||
the specified field names.
|
||||
You can pass positional arguments (``*fields``) in order to specify the names
|
||||
of fields to which the ``DISTINCT`` should apply. This translates to a
|
||||
``SELECT DISTINCT ON`` SQL query. Here's the difference. For a normal
|
||||
``distinct()`` call, the database compares *each* field in each row when
|
||||
determining which rows are distinct. For a ``distinct()`` call with specified
|
||||
field names, the database will only compare the specified field names.
|
||||
|
||||
.. note::
|
||||
This ability to specify field names is only available in PostgreSQL.
|
||||
|
@ -740,8 +736,6 @@ prefetch_related
|
|||
|
||||
.. method:: prefetch_related(*lookups)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Returns a ``QuerySet`` that will automatically retrieve, in a single batch,
|
||||
related objects for each of the specified lookups.
|
||||
|
||||
|
@ -1191,8 +1185,6 @@ select_for_update
|
|||
|
||||
.. method:: select_for_update(nowait=False)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Returns a queryset that will lock rows until the end of the transaction,
|
||||
generating a ``SELECT ... FOR UPDATE`` SQL statement on supported databases.
|
||||
|
||||
|
@ -1368,8 +1360,6 @@ bulk_create
|
|||
|
||||
.. method:: bulk_create(objs, batch_size=None)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This method inserts the provided list of objects into the database in an
|
||||
efficient manner (generally only 1 query, no matter how many objects there
|
||||
are)::
|
||||
|
|
|
@ -262,8 +262,6 @@ Methods
|
|||
|
||||
.. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Returns a cookie value for a signed cookie, or raises a
|
||||
:class:`~django.core.signing.BadSignature` exception if the signature is
|
||||
no longer valid. If you provide the ``default`` argument the exception
|
||||
|
@ -473,9 +471,6 @@ In addition, ``QueryDict`` has the following methods:
|
|||
It's guaranteed to return a list of some sort unless the default value
|
||||
was no list.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The ``default`` parameter was added.
|
||||
|
||||
.. method:: QueryDict.setlist(key, list_)
|
||||
|
||||
Sets the given key to ``list_`` (unlike ``__setitem__()``).
|
||||
|
@ -500,8 +495,6 @@ In addition, ``QueryDict`` has the following methods:
|
|||
|
||||
.. method:: QueryDict.dict()
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Returns ``dict`` representation of ``QueryDict``. For every (key, list)
|
||||
pair in ``QueryDict``, ``dict`` will have (key, item), where item is one
|
||||
element of the list, using same logic as :meth:`QueryDict.__getitem__()`::
|
||||
|
@ -705,8 +698,6 @@ Methods
|
|||
|
||||
.. method:: HttpResponse.set_signed_cookie(key, value='', salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Like :meth:`~HttpResponse.set_cookie()`, but
|
||||
:doc:`cryptographic signing </topics/signing>` the cookie before setting
|
||||
it. Use in conjunction with :meth:`HttpRequest.get_signed_cookie`.
|
||||
|
|
|
@ -325,8 +325,6 @@ want. See :doc:`/ref/contrib/csrf`.
|
|||
CSRF_COOKIE_PATH
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the CSRF cookie. This should either match the URL path of your
|
||||
|
@ -341,8 +339,6 @@ its own CSRF cookie.
|
|||
CSRF_COOKIE_SECURE
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use a secure cookie for the CSRF cookie. If this is set to ``True``,
|
||||
|
@ -756,11 +752,6 @@ name includes any of the following:
|
|||
* SIGNATURE
|
||||
* TOKEN
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
We changed ``'PASSWORD'`` ``'PASS'``. ``'API'``, ``'TOKEN'`` and ``'KEY'``
|
||||
were added.
|
||||
|
||||
Note that these are *partial* matches. ``'PASS'`` will also match PASSWORD,
|
||||
just as ``'TOKEN'`` will also match TOKENIZED and so on.
|
||||
|
||||
|
@ -1117,8 +1108,6 @@ Available formats are :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`,
|
|||
IGNORABLE_404_URLS
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``()``
|
||||
|
||||
List of compiled regular expression objects describing URLs that should be
|
||||
|
@ -1457,8 +1446,6 @@ See also :setting:`DECIMAL_SEPARATOR`, :setting:`THOUSAND_SEPARATOR` and
|
|||
PASSWORD_HASHERS
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
See :ref:`auth_password_storage`.
|
||||
|
||||
Default::
|
||||
|
@ -1544,8 +1531,6 @@ randomly-generated ``SECRET_KEY`` to each new project.
|
|||
SECURE_PROXY_SSL_HEADER
|
||||
-----------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``None``
|
||||
|
||||
A tuple representing a HTTP header/value combination that signifies a request
|
||||
|
@ -1677,9 +1662,6 @@ protected cookie data.
|
|||
|
||||
.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The default value of the setting was changed from ``False`` to ``True``.
|
||||
|
||||
.. setting:: SESSION_COOKIE_NAME
|
||||
|
||||
SESSION_COOKIE_NAME
|
||||
|
@ -1809,8 +1791,6 @@ See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
|||
SIGNING_BACKEND
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: 'django.core.signing.TimestampSigner'
|
||||
|
||||
The backend used for signing cookies and other data.
|
||||
|
@ -1901,10 +1881,6 @@ A tuple of callables that are used to populate the context in ``RequestContext``
|
|||
These callables take a request object as their argument and return a dictionary
|
||||
of items to be merged into the context.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
The ``django.core.context_processors.tz`` context processor
|
||||
was added in this release.
|
||||
|
||||
.. setting:: TEMPLATE_DEBUG
|
||||
|
||||
TEMPLATE_DEBUG
|
||||
|
@ -2029,9 +2005,6 @@ TIME_ZONE
|
|||
|
||||
Default: ``'America/Chicago'``
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The meaning of this setting now depends on the value of :setting:`USE_TZ`.
|
||||
|
||||
A string representing the time zone for this installation, or
|
||||
``None``. `See available choices`_. (Note that list of available
|
||||
choices lists more than one on the same line; you'll want to use just
|
||||
|
@ -2148,8 +2121,6 @@ See also :setting:`DECIMAL_SEPARATOR`, :setting:`NUMBER_GROUPING` and
|
|||
USE_TZ
|
||||
------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies if datetimes will be timezone-aware by default or not.
|
||||
|
@ -2180,8 +2151,6 @@ which sets this header is in use.
|
|||
WSGI_APPLICATION
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Default: ``None``
|
||||
|
||||
The full Python path of the WSGI application object that Django's built-in
|
||||
|
|
|
@ -480,8 +480,6 @@ Signals only sent when :ref:`running tests <running-tests>`.
|
|||
setting_changed
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. data:: django.test.signals.setting_changed
|
||||
:module:
|
||||
|
||||
|
|
|
@ -221,13 +221,12 @@ straight lookups. Here are some things to keep in mind:
|
|||
self.database_record.delete()
|
||||
sensitive_function.alters_data = True
|
||||
|
||||
* .. versionadded:: 1.4
|
||||
Occasionally you may want to turn off this feature for other reasons,
|
||||
and tell the template system to leave a variable un-called no matter
|
||||
what. To do so, set a ``do_not_call_in_templates`` attribute on the
|
||||
callable with the value ``True``. The template system then will act as
|
||||
if your variable is not callable (allowing you to access attributes of
|
||||
the callable, for example).
|
||||
* Occasionally you may want to turn off this feature for other reasons,
|
||||
and tell the template system to leave a variable un-called no matter
|
||||
what. To do so, set a ``do_not_call_in_templates`` attribute on the
|
||||
callable with the value ``True``. The template system then will act as
|
||||
if your variable is not callable (allowing you to access attributes of
|
||||
the callable, for example).
|
||||
|
||||
.. _invalid-template-variables:
|
||||
|
||||
|
|
|
@ -381,10 +381,6 @@ As you can see, the ``if`` tag may take one or several `` {% elif %}``
|
|||
clauses, as well as an ``{% else %}`` clause that will be displayed if all
|
||||
previous conditions fail. These clauses are optional.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``if`` tag now supports ``{% elif %}`` clauses.
|
||||
|
||||
Boolean operators
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
@ -743,8 +739,6 @@ escaped, because it's not a format character::
|
|||
|
||||
This would display as "It is the 4th of September".
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
.. note::
|
||||
|
||||
The format passed can also be one of the predefined ones
|
||||
|
@ -1289,10 +1283,6 @@ Z Time zone offset in seconds. The ``-43200`` to ``4320
|
|||
UTC is always positive.
|
||||
================ ======================================== =====================
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``e`` and ``o`` format specification characters were added in Django 1.4.
|
||||
|
||||
For example::
|
||||
|
||||
{{ value|date:"D d M Y" }}
|
||||
|
@ -2069,8 +2059,6 @@ If ``value`` is ``"my first post"``, the output will be ``"My First Post"``.
|
|||
truncatechars
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Truncates a string if it is longer than the specified number of characters.
|
||||
Truncated strings will end with a translatable ellipsis sequence ("...").
|
||||
|
||||
|
@ -2200,11 +2188,6 @@ It also supports domain-only links ending in one of the original top level
|
|||
domains (``.com``, ``.edu``, ``.gov``, ``.int``, ``.mil``, ``.net``, and
|
||||
``.org``). For example, ``djangoproject.com`` gets converted.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Until Django 1.4, only the ``.com``, ``.net`` and ``.org`` suffixes were
|
||||
supported for domain-only links.
|
||||
|
||||
Links can have trailing punctuation (periods, commas, close-parens) and leading
|
||||
punctuation (opening parens), and ``urlize`` will still do the right thing.
|
||||
|
||||
|
@ -2334,8 +2317,6 @@ See :ref:`topic-l10n-templates`.
|
|||
tz
|
||||
^^
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This library provides control over time zone conversions in templates.
|
||||
Like ``l10n``, you only need to load the library using ``{% load tz %}``,
|
||||
but you'll usually also set :setting:`USE_TZ` to ``True`` so that conversion
|
||||
|
|
|
@ -71,8 +71,6 @@ You can use ``kwargs`` instead of ``args``. For example::
|
|||
reverse_lazy()
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
A lazily evaluated version of `reverse()`_.
|
||||
|
||||
.. function:: reverse_lazy(viewname, [urlconf=None, args=None, kwargs=None, current_app=None])
|
||||
|
|
|
@ -114,9 +114,6 @@ value should suffice.
|
|||
See the documentation about :ref:`the 403 (HTTP Forbidden) view
|
||||
<http_forbidden_view>` for more information.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
``handler403`` is new in Django 1.4.
|
||||
|
||||
handler404
|
||||
----------
|
||||
|
||||
|
|
|
@ -138,8 +138,6 @@ results. Instead do::
|
|||
``django.utils.dateparse``
|
||||
==========================
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. module:: django.utils.dateparse
|
||||
:synopsis: Functions to parse datetime objects.
|
||||
|
||||
|
@ -788,8 +786,6 @@ For a complete discussion on the usage of the following see the
|
|||
|
||||
.. function:: override(language, deactivate=False)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
A Python context manager that uses
|
||||
:func:`django.utils.translation.activate` to fetch the translation object
|
||||
for a given language, installing it as the translation object for the
|
||||
|
@ -812,8 +808,6 @@ For a complete discussion on the usage of the following see the
|
|||
|
||||
.. function:: get_language_from_request(request, check_path=False)
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Analyzes the request to find what language the user wants the system to show.
|
||||
Only languages listed in settings.LANGUAGES are taken into account. If the user
|
||||
requests a sublanguage where we have a main language, we send out the main
|
||||
|
@ -838,8 +832,6 @@ For a complete discussion on the usage of the following see the
|
|||
``django.utils.timezone``
|
||||
=========================
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. module:: django.utils.timezone
|
||||
:synopsis: Timezone support.
|
||||
|
||||
|
|
|
@ -115,7 +115,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
``validate_ipv6_address``
|
||||
-------------------------
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. data:: validate_ipv6_address
|
||||
|
||||
|
@ -123,7 +122,6 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
|
||||
``validate_ipv46_address``
|
||||
--------------------------
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. data:: validate_ipv46_address
|
||||
|
||||
|
|
|
@ -522,12 +522,10 @@ The permission_required decorator
|
|||
As in the :func:`~django.contrib.auth.decorators.login_required` decorator,
|
||||
``login_url`` defaults to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Added ``raise_exception`` parameter. If given, the decorator will raise
|
||||
:exc:`~django.core.exceptions.PermissionDenied`, prompting
|
||||
:ref:`the 403 (HTTP Forbidden) view<http_forbidden_view>` instead of
|
||||
redirecting to the login page.
|
||||
If the ``raise_exception`` parameter is given, the decorator will raise
|
||||
:exc:`~django.core.exceptions.PermissionDenied`, prompting :ref:`the 403
|
||||
(HTTP Forbidden) view<http_forbidden_view>` instead of redirecting to the
|
||||
login page.
|
||||
|
||||
Applying permissions to generic views
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -552,8 +550,6 @@ password management. These make use of the :ref:`stock auth forms
|
|||
Django provides no default template for the authentication views - however the
|
||||
template context is documented for each view below.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The built-in views all return
|
||||
a :class:`~django.template.response.TemplateResponse` instance, which allows
|
||||
you to easily customize the response data before rendering. For more details,
|
||||
|
@ -747,11 +743,10 @@ patterns.
|
|||
that can be used to reset the password, and sending that link to the
|
||||
user's registered email address.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Users flagged with an unusable password (see
|
||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()`
|
||||
will not be able to request a password reset to prevent misuse
|
||||
when using an external authentication source like LDAP.
|
||||
Users flagged with an unusable password (see
|
||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()` aren't
|
||||
allowed to request a password reset to prevent misuse when using an
|
||||
external authentication source like LDAP.
|
||||
|
||||
**URL name:** ``password_reset``
|
||||
|
||||
|
@ -769,8 +764,6 @@ patterns.
|
|||
the subject of the email with the reset password link. Defaults
|
||||
to :file:`registration/password_reset_subject.txt` if not supplied.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
* ``password_reset_form``: Form that will be used to get the email of
|
||||
the user to reset the password for. Defaults to
|
||||
:class:`~django.contrib.auth.forms.PasswordResetForm`.
|
||||
|
|
|
@ -13,10 +13,8 @@ work with hashed passwords.
|
|||
How Django stores passwords
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.4
|
||||
Django 1.4 introduces a new flexible password storage system and uses
|
||||
PBKDF2 by default. Previous versions of Django used SHA1, and other
|
||||
algorithms couldn't be chosen.
|
||||
Django provides a flexible password storage system and uses PBKDF2 by default.
|
||||
Older versions of Django used SHA1, and other algorithms couldn't be chosen.
|
||||
|
||||
The :attr:`~django.contrib.auth.models.User.password` attribute of a
|
||||
:class:`~django.contrib.auth.models.User` object is a string in this format::
|
||||
|
@ -173,15 +171,12 @@ Manually managing a user's password
|
|||
|
||||
.. module:: django.contrib.auth.hashers
|
||||
|
||||
.. versionadded:: 1.4
|
||||
The :mod:`django.contrib.auth.hashers` module provides a set of functions
|
||||
to create and validate hashed password. You can use them independently
|
||||
from the ``User`` model.
|
||||
|
||||
.. function:: check_password(password, encoded)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you'd like to manually authenticate a user by comparing a plain-text
|
||||
password to the hashed password in the database, use the convenience
|
||||
function :func:`django.contrib.auth.hashers.check_password`. It takes two
|
||||
|
@ -191,8 +186,6 @@ Manually managing a user's password
|
|||
|
||||
.. function:: make_password(password[, salt, hashers])
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Creates a hashed password in the format used by this application. It takes
|
||||
one mandatory argument: the password in plain-text. Optionally, you can
|
||||
provide a salt and a hashing algorithm to use, if you don't want to use the
|
||||
|
@ -206,7 +199,5 @@ Manually managing a user's password
|
|||
|
||||
.. function:: is_password_usable(encoded_password)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Checks if the given string is a hashed password that has a chance
|
||||
of being verified against :func:`django.contrib.auth.hashers.check_password`.
|
||||
|
|
|
@ -482,8 +482,6 @@ include the name of the active :term:`language<language code>` -- see also
|
|||
:ref:`how-django-discovers-language-preference`). This allows you to easily
|
||||
cache multilingual sites without having to create the cache key yourself.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
Cache keys also include the active :term:`language <language code>` when
|
||||
:setting:`USE_L10N` is set to ``True`` and the :ref:`current time zone
|
||||
<default-current-time-zone>` when :setting:`USE_TZ` is set to ``True``.
|
||||
|
|
|
@ -412,14 +412,13 @@ translates (roughly) into the following SQL::
|
|||
|
||||
.. _`Keyword Arguments`: http://docs.python.org/tutorial/controlflow.html#keyword-arguments
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The field specified in a lookup has to be the name of a model field.
|
||||
There's one exception though, in case of a
|
||||
:class:`~django.db.models.ForeignKey` you can specify the field
|
||||
name suffixed with ``_id``. In this case, the value parameter is expected
|
||||
to contain the raw value of the foreign model's primary key. For example:
|
||||
The field specified in a lookup has to be the name of a model field. There's
|
||||
one exception though, in case of a :class:`~django.db.models.ForeignKey` you
|
||||
can specify the field name suffixed with ``_id``. In this case, the value
|
||||
parameter is expected to contain the raw value of the foreign model's primary
|
||||
key. For example:
|
||||
|
||||
>>> Entry.objects.filter(blog_id__exact=4)
|
||||
>>> Entry.objects.filter(blog_id__exact=4)
|
||||
|
||||
If you pass an invalid keyword argument, a lookup function will raise
|
||||
``TypeError``.
|
||||
|
|
|
@ -68,6 +68,3 @@ PostgreSQL and Oracle support tablespaces. SQLite and MySQL don't.
|
|||
|
||||
When you use a backend that lacks support for tablespaces, Django ignores all
|
||||
tablespace-related options.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Since Django 1.4, the PostgreSQL backend supports tablespaces.
|
||||
|
|
|
@ -238,9 +238,6 @@ with the PostgreSQL 8, Oracle and MySQL (when using the InnoDB storage engine)
|
|||
backends. Other backends provide the savepoint functions, but they're empty
|
||||
operations -- they don't actually do anything.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Savepoint support for the MySQL backend was added in Django 1.4.
|
||||
|
||||
Savepoints aren't especially useful if you are using the default
|
||||
``autocommit`` behavior of Django. However, if you are using
|
||||
``commit_on_success`` or ``commit_manually``, each open transaction will build
|
||||
|
|
|
@ -139,8 +139,6 @@ As we can see, ``formset.errors`` is a list whose entries correspond to the
|
|||
forms in the formset. Validation was performed for each of the two forms, and
|
||||
the expected error message appears for the second item.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
We can also check if form data differs from the initial data (i.e. the form was
|
||||
sent without any data)::
|
||||
|
||||
|
|
|
@ -625,8 +625,6 @@ exclude::
|
|||
Providing initial values
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
As with regular formsets, it's possible to :ref:`specify initial data
|
||||
<formsets-initial-data>` for forms in the formset by specifying an ``initial``
|
||||
parameter when instantiating the model formset class returned by
|
||||
|
|
|
@ -39,8 +39,6 @@ a :class:`django.http.HttpResponseNotAllowed` if the conditions are not met.
|
|||
|
||||
.. function:: require_safe()
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Decorator to require that a view only accept the GET and HEAD methods.
|
||||
These methods are commonly considered "safe" because they should not have
|
||||
the significance of taking an action other than retrieving the requested
|
||||
|
|
|
@ -110,8 +110,6 @@ server has permissions to read and write to this location.
|
|||
Using cookie-based sessions
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
To use cookies-based sessions, set the :setting:`SESSION_ENGINE` setting to
|
||||
``"django.contrib.sessions.backends.signed_cookies"``. The session data will be
|
||||
stored using Django's tools for :doc:`cryptographic signing </topics/signing>`
|
||||
|
@ -558,9 +556,6 @@ consistently by all browsers. However, when it is honored, it can be a
|
|||
useful way to mitigate the risk of client side script accessing the
|
||||
protected cookie data.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The default value of the setting was changed from ``False`` to ``True``.
|
||||
|
||||
.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
|
||||
|
||||
SESSION_COOKIE_NAME
|
||||
|
|
|
@ -26,10 +26,9 @@ This mapping can be as short or as long as needed. It can reference other
|
|||
mappings. And, because it's pure Python code, it can be constructed
|
||||
dynamically.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
Django also provides a way to translate URLs according to the active
|
||||
language. See the :ref:`internationalization documentation
|
||||
<url-internationalization>` for more information.
|
||||
Django also provides a way to translate URLs according to the active
|
||||
language. See the :ref:`internationalization documentation
|
||||
<url-internationalization>` for more information.
|
||||
|
||||
.. _how-django-processes-a-request:
|
||||
|
||||
|
@ -246,9 +245,6 @@ The variables are:
|
|||
* ``handler500`` -- See :data:`django.conf.urls.handler500`.
|
||||
* ``handler403`` -- See :data:`django.conf.urls.handler403`.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
``handler403`` is new in Django 1.4.
|
||||
|
||||
.. _urlpatterns-view-prefix:
|
||||
|
||||
The view prefix
|
||||
|
|
|
@ -199,8 +199,6 @@ One thing to note about 500 views:
|
|||
The 403 (HTTP Forbidden) view
|
||||
-----------------------------
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
In the same vein as the 404 and 500 views, Django has a view to handle 403
|
||||
Forbidden errors. If a view results in a 403 exception then Django will, by
|
||||
default, call the view ``django.views.defaults.permission_denied``.
|
||||
|
|
|
@ -4,8 +4,6 @@
|
|||
Time zones
|
||||
==========
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. _time-zones-overview:
|
||||
|
||||
Overview
|
||||
|
|
|
@ -287,8 +287,6 @@ will appear in the ``.po`` file as:
|
|||
msgid "May"
|
||||
msgstr ""
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Contextual markers are also supported by the :ttag:`trans` and
|
||||
:ttag:`blocktrans` template tags.
|
||||
|
||||
|
@ -507,7 +505,6 @@ It's not possible to mix a template variable inside a string within ``{% trans
|
|||
%}``. If your translations require strings with variables (placeholders), use
|
||||
``{% blocktrans %}`` instead.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
If you'd like to retrieve a translated string without displaying it, you can
|
||||
use the following syntax::
|
||||
|
@ -533,8 +530,6 @@ or should be used as arguments for other template tags or filters::
|
|||
{% endfor %}
|
||||
</p>
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
``{% trans %}`` also supports :ref:`contextual markers<contextual-markers>`
|
||||
using the ``context`` keyword:
|
||||
|
||||
|
@ -574,8 +569,6 @@ You can use multiple expressions inside a single ``blocktrans`` tag::
|
|||
.. note:: The previous more verbose format is still supported:
|
||||
``{% blocktrans with book|title as book_t and author|title as author_t %}``
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
If resolving one of the block arguments fails, blocktrans will fall back to
|
||||
the default language by deactivating the currently active language
|
||||
temporarily with the :func:`~django.utils.translation.deactivate_all`
|
||||
|
@ -620,8 +613,6 @@ be retrieved (and stored) beforehand::
|
|||
This is a URL: {{ the_url }}
|
||||
{% endblocktrans %}
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
``{% blocktrans %}`` also supports :ref:`contextual
|
||||
markers<contextual-markers>` using the ``context`` keyword:
|
||||
|
||||
|
@ -1410,8 +1401,6 @@ For example, your :setting:`MIDDLEWARE_CLASSES` might look like this::
|
|||
``LocaleMiddleware`` tries to determine the user's language preference by
|
||||
following this algorithm:
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
* First, it looks for the language prefix in the requested URL. This is
|
||||
only performed when you are using the ``i18n_patterns`` function in your
|
||||
root URLconf. See :ref:`url-internationalization` for more information
|
||||
|
|
|
@ -504,8 +504,6 @@ logging module.
|
|||
|
||||
.. class:: CallbackFilter(callback)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This filter accepts a callback function (which should accept a single
|
||||
argument, the record to be logged), and calls it for each record that passes
|
||||
through the filter. Handling of that record will not proceed if the callback
|
||||
|
@ -542,8 +540,6 @@ logging module.
|
|||
|
||||
.. class:: RequireDebugFalse()
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This filter will only pass on records when settings.DEBUG is False.
|
||||
|
||||
This filter is used as follows in the default :setting:`LOGGING`
|
||||
|
|
|
@ -126,12 +126,6 @@ pages along with any interesting information from the objects themselves::
|
|||
</span>
|
||||
</div>
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Previously, you would need to use
|
||||
``{% for contact in contacts.object_list %}``, since the ``Page``
|
||||
object was not iterable.
|
||||
|
||||
|
||||
``Paginator`` objects
|
||||
=====================
|
||||
|
||||
|
@ -234,7 +228,6 @@ using :meth:`Paginator.page`.
|
|||
|
||||
.. class:: Page(object_list, number, paginator)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
A page acts like a sequence of :attr:`Page.object_list` when using
|
||||
``len()`` or iterating it directly.
|
||||
|
||||
|
|
|
@ -5,8 +5,6 @@ Cryptographic signing
|
|||
.. module:: django.core.signing
|
||||
:synopsis: Django's signing framework.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The golden rule of Web application security is to never trust data from
|
||||
untrusted sources. Sometimes it can be useful to pass data through an
|
||||
untrusted medium. Cryptographically signed values can be passed through an
|
||||
|
|
|
@ -242,8 +242,6 @@ set up, execute and tear down the test suite.
|
|||
write your own test runner, ensure accept and handle the ``**kwargs``
|
||||
parameter.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Your test runner may also define additional command-line options.
|
||||
If you add an ``option_list`` attribute to a subclassed test runner,
|
||||
those options will be added to the list of command-line options that
|
||||
|
@ -254,8 +252,6 @@ Attributes
|
|||
|
||||
.. attribute:: DjangoTestSuiteRunner.option_list
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
This is the tuple of ``optparse`` options which will be fed into the
|
||||
management command's ``OptionParser`` for parsing arguments. See the
|
||||
documentation for Python's ``optparse`` module for more details.
|
||||
|
|
|
@ -860,8 +860,6 @@ SimpleTestCase
|
|||
|
||||
.. class:: SimpleTestCase()
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
A very thin subclass of :class:`unittest.TestCase`, it extends it with some
|
||||
basic functionality like:
|
||||
|
||||
|
@ -992,8 +990,6 @@ additions, including:
|
|||
LiveServerTestCase
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. class:: LiveServerTestCase()
|
||||
|
||||
``LiveServerTestCase`` does basically the same as
|
||||
|
@ -1346,8 +1342,6 @@ Overriding settings
|
|||
|
||||
.. method:: TestCase.settings
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
For testing purposes it's often useful to change a setting temporarily and
|
||||
revert to the original value after running the testing code. For this use case
|
||||
Django provides a standard Python context manager (see :pep:`343`)
|
||||
|
@ -1459,8 +1453,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Asserts that execution of callable ``callable_obj`` raised the
|
||||
``expected_exception`` exception and that such exception has an
|
||||
``expected_message`` representation. Any other outcome is reported as a
|
||||
|
@ -1469,8 +1461,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Asserts that a form field behaves correctly with various inputs.
|
||||
|
||||
:param fieldclass: the class of the field to be tested.
|
||||
|
@ -1495,8 +1485,6 @@ your test suite.
|
|||
that ``text`` appears in the content of the response. If ``count`` is
|
||||
provided, ``text`` must occur exactly ``count`` times in the response.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Set ``html`` to ``True`` to handle ``text`` as HTML. The comparison with
|
||||
the response content will be based on HTML semantics instead of
|
||||
character-by-character equality. Whitespace is ignored in most cases,
|
||||
|
@ -1508,8 +1496,6 @@ your test suite.
|
|||
Asserts that a ``Response`` instance produced the given ``status_code`` and
|
||||
that ``text`` does not appears in the content of the response.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Set ``html`` to ``True`` to handle ``text`` as HTML. The comparison with
|
||||
the response content will be based on HTML semantics instead of
|
||||
character-by-character equality. Whitespace is ignored in most cases,
|
||||
|
@ -1538,8 +1524,6 @@ your test suite.
|
|||
|
||||
The name is a string such as ``'admin/index.html'``.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
You can use this as a context manager, like this::
|
||||
|
||||
with self.assertTemplateUsed('index.html'):
|
||||
|
@ -1552,8 +1536,6 @@ your test suite.
|
|||
Asserts that the template with the given name was *not* used in rendering
|
||||
the response.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
You can use this as a context manager in the same way as
|
||||
:meth:`~TestCase.assertTemplateUsed`.
|
||||
|
||||
|
@ -1580,12 +1562,6 @@ your test suite.
|
|||
provide an implicit ordering, you can set the ``ordered`` parameter to
|
||||
``False``, which turns the comparison into a Python set comparison.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The ``ordered`` parameter is new in version 1.4. In earlier versions,
|
||||
you would need to ensure the queryset is ordered consistently, possibly
|
||||
via an explicit ``order_by()`` call on the queryset prior to
|
||||
comparison.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
The method now checks for undefined order and raises ``ValueError``
|
||||
if undefined order is spotted. The ordering is seen as undefined if
|
||||
|
@ -1612,8 +1588,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertHTMLEqual(html1, html2, msg=None)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Asserts that the strings ``html1`` and ``html2`` are equal. The comparison
|
||||
is based on HTML semantics. The comparison takes following things into
|
||||
account:
|
||||
|
@ -1643,8 +1617,6 @@ your test suite.
|
|||
|
||||
.. method:: SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
Asserts that the strings ``html1`` and ``html2`` are *not* equal. The
|
||||
comparison is based on HTML semantics. See
|
||||
:meth:`~SimpleTestCase.assertHTMLEqual` for details.
|
||||
|
|
Loading…
Reference in New Issue