mirror of
https://github.com/django/django.git
synced 2025-12-04 00:55:36 +00:00
Fixed #8753: converted "new in ..." callouts to proper Sphinx "versionadded/versionchanged" directives. Thanks to Marc Fargas for all the heavy lifting here.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8843 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
c435975cc7
commit
64a9469127
47 changed files with 303 additions and 232 deletions
|
|
@ -3,7 +3,7 @@
|
|||
Writing custom django-admin commands
|
||||
====================================
|
||||
|
||||
**New in Django development version**
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Applications can register their own actions with ``manage.py``. For example,
|
||||
you might want to add a ``manage.py`` action for a Django app that you're
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Writing custom model fields
|
||||
===========================
|
||||
|
||||
**New in Django development version**
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ will use the function's name as the filter name.
|
|||
Filters and auto-escaping
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**New in Django development version**
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When writing a custom filter, give some thought to how the filter will interact
|
||||
with Django's auto-escaping behavior. Note that three types of strings can be
|
||||
|
|
@ -422,7 +422,7 @@ without having to be parsed multiple times.
|
|||
Auto-escaping considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**New in Django development version**
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The output from template tags is **not** automatically run through the
|
||||
auto-escaping filters. However, there are still a couple of things you should
|
||||
|
|
@ -547,7 +547,7 @@ current context, available in the ``render`` method::
|
|||
``resolve_variable`` will try to resolve ``blog_entry.date_updated`` and then
|
||||
format it accordingly.
|
||||
|
||||
.. admonition:: New in development version:
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Variable resolution has changed in the development version of Django.
|
||||
``template.resolve_variable()`` is still available, but has been deprecated
|
||||
|
|
|
|||
|
|
@ -49,7 +49,10 @@ This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
|
|||
Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE
|
||||
<django-settings-module>` so mod_python knows which settings to use.
|
||||
|
||||
**New in Django development version:** Because mod_python does not know we are
|
||||
.. versionadded:: 1.0
|
||||
The ``PythonOption django.root ...`` is new in this version.
|
||||
|
||||
Because mod_python does not know we are
|
||||
serving this site from underneath the ``/mysite/`` prefix, this value needs to
|
||||
be passed through to the mod_python handler in Django, via the ``PythonOption
|
||||
django.root ...`` line. The value set on that line (the last item) should
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue