Примечания к выпуску Django 1.4 ¶
23 марта 2012 г.
Добро пожаловать в Django 1.4!
Эти примечания к выпуску охватывают новые функции , а также некоторые обратно несовместимые изменения, о которых вам нужно знать при обновлении с Django 1.3 или более старых версий. Мы также отказались от некоторых функций, которые подробно описаны в нашем плане прекращения поддержки , и начали процесс прекращения поддержки некоторых функций .
Обзор ¶
Самая большая новая функция в Django 1.4 - поддержка часовых поясов при обработке даты и времени. Когда этот параметр включен, этот Django будет хранить дату / время в формате UTC, использовать внутренние объекты с учетом часового пояса и переводить их в местные часовые пояса пользователей для отображения.
Если вы обновляете существующий проект до Django 1.4, переключение в режим с учетом часового пояса может потребовать некоторой осторожности: новый режим запрещает некоторые довольно небрежные действия, которые раньше допускались. Мы рекомендуем всем, кто обновляется, ознакомиться с руководством по переносу часовых поясов и часто задаваемыми вопросами о часовых поясах для получения полезных указателей.
Другие заметные новые функции в Django 1.4 включают:
- Ряд улучшений ORM, включая поддержку SELECT FOR UPDATE , возможность массовой вставки
больших наборов данных для повышения производительности и
QuerySet.prefetch_related , метод пакетной загрузки связанных объектов в областях, где
select_related()
это не работает. - Некоторые приятные дополнения к безопасности, включая улучшенное хеширование паролей (с поддержкой PBKDF2 и bcrypt ), новые инструменты для криптографической подписи , несколько улучшений CSRF и простая защита от кликджекинга .
- Обновленный макет проекта по умолчанию и manage.py , который удаляет «магию» из предыдущих версий. А для тех, кому не нравится новый макет, вы можете использовать собственные шаблоны проектов и приложений !
- Поддержка фреймворков для тестирования в браузере (например, Selenium ).
- … И многое другое; см. ниже !
По возможности мы стараемся внедрять новые функции обратно совместимым образом в соответствии с нашей политикой политики стабильности API . Однако, как и в предыдущих выпусках, Django 1.4 поставляется с некоторыми незначительными обратно несовместимыми изменениями ; люди, обновляющиеся с предыдущих версий Django, должны внимательно прочитать этот список.
Совместимость с Python ¶
Django 1.4 отказался от поддержки Python 2.4. Python 2.5 теперь является минимально необходимой версией Python. Django протестирован и поддерживается на Python 2.5, 2.6 и 2.7.
Это изменение должно коснуться только небольшого числа пользователей Django, так как большинство поставщиков операционных систем сегодня поставляют Python 2.5 или новее в качестве версии по умолчанию. Однако, если вы все еще используете Python 2.4, вам нужно придерживаться Django 1.3, пока вы не обновитесь. Согласно нашей политике поддержки , Django 1.3 продолжит получать поддержку безопасности до выпуска Django 1.5.
Django в настоящее время не поддерживает Python 3.x. В какой-то момент перед выпуском Django 1.4 мы планируем опубликовать документ с изложением наших полных сроков прекращения поддержки Python 2.x и перехода на Python 3.x.
Что нового в Django 1.4 ¶
Поддержка часовых поясов ¶
В предыдущих версиях Django использовал «наивные» дату / время (то есть дату / время без соответствующего часового пояса), оставляя на усмотрение каждого разработчика интерпретировать, что данная дата / время «на самом деле означает». Это может вызвать всевозможные тонкие ошибки, связанные с часовым поясом.
В Django 1.4 теперь вы можете переключить Django в более правильный режим с учетом часовых поясов. В этом режиме Django хранит информацию о дате и времени в формате UTC в базе данных, использует внутренние объекты datetime с учетом часового пояса и переводит их в часовой пояс конечного пользователя в шаблонах и формах. Причины использования этой функции:
- Настройка отображения даты и времени для пользователей по всему миру.
- Сохранение даты и времени в формате UTC для переносимости и взаимодействия базы данных. (Этот аргумент неприменим к PostgreSQL, потому что он уже хранит временные метки с информацией о часовом поясе в Django 1.3.)
- Предотвращение проблем с повреждением данных при переходе на летнее время.
Поддержка часовых поясов включена по умолчанию в новых проектах, созданных с помощью
startproject
. Если вы хотите использовать эту функцию в существующем проекте, прочтите руководство по миграции . Если у вас возникнут проблемы, есть полезный FAQ .
Поддержка фреймворков для тестирования в браузере ¶
Django 1.4 поддерживает интеграцию с фреймворками для тестирования в браузере, такими как
Selenium . Новый django.test.LiveServerTestCase
базовый класс позволяет более полно тестировать взаимодействие между внешним и внутренним интерфейсом вашего сайта. См.
documentation
Более подробную информацию и конкретные примеры.
Обновлен макет проекта по умолчанию и manage.py
¶
Django 1.4 поставляется с обновленным макетом проекта по умолчанию и manage.py
файлом для команды startproject
управления. Это устраняет некоторые проблемы с предыдущей manage.py
обработкой путей импорта Python, которые вызывали двойной импорт, проблемы при переходе от разработки к развертыванию и другие проблемы с путями, которые трудно отлаживать.
Предыдущие manage.py
вызываемые функции, которые теперь устарели, и, следовательно, проекты, обновляющиеся до Django 1.4, должны обновить свои manage.py
. (Старый стиль manage.py
будет продолжать работать, как и раньше, до Django 1.6. В 1.5 он будет повышаться DeprecationWarning
).
Новый рекомендуемый manage.py
файл должен выглядеть так:
#!/usr/bin/env python
import os, sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
{{ project_name }}
следует заменить на имя пакета Python фактического проекта.
Если настройки, URLconfs и приложения в проекте импортируются или на них ссылаются с использованием префикса имени проекта (например myproject.settings
, и т. Д.), Новый необходимо переместить на один каталог вверх, чтобы он находился за пределами пакета проекта, а не рядом с
и .ROOT_URLCONF =
"myproject.urls"
manage.py
settings.py
urls.py
Например, со следующей компоновкой:
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
Вы можете импортировать mysite.settings
, mysite.urls
и mysite.myapp
, но не settings
, urls
или в myapp
качестве топ-уровня модулей.
Все, что импортировано как модуль верхнего уровня, можно разместить рядом с новым
manage.py
. Например, чтобы отделить «myapp» от модуля проекта и импортировать его просто myapp
, поместите его вне mysite/
каталога:
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
Если один и тот же код импортируется непоследовательно (где-то с префиксом проекта, где-то без него), импорт необходимо будет очистить при переходе на новый manage.py
.
Пользовательские шаблоны проектов и приложений ¶
startapp
И startproject
команда управления теперь имеет --template
опцию для указания пути или URL для пользовательского приложения или шаблона проекта.
Например, Django будет использовать /path/to/my_project_template
каталог, когда вы запустите следующую команду:
django-admin.py startproject --template=/path/to/my_project_template myproject
Теперь вы также можете указать целевой каталог в качестве второго аргумента для обоих startapp
и startproject
:
django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project
Для получения дополнительной информации см startapp
и startproject
документации.
Улучшенная поддержка WSGI ¶
Команда startproject
управления теперь добавляет wsgi.py
модуль в исходный макет проекта, содержащий простое приложение WSGI, которое можно использовать для развертывания с серверами приложений WSGI .
Теперь поддерживает с использованием внешне определенной WSGI Callable, что делает возможным запуск
с такой же конфигурацией WSGI , который используется для развертывания. Новый
параметр позволяет вам настроить, какой объект WSGI
использует.built-in development server
runserver
WSGI_APPLICATION
runserver
(Команда runfcgi
управления также внутренне обертывает вызываемый объект WSGI, настроенный через WSGI_APPLICATION
.)
SELECT FOR UPDATE
поддержка ¶
Django 1.4 включает QuerySet.select_for_update()
метод, который генерирует
SQL-запрос. Это заблокирует строки до конца транзакции, то есть другие транзакции не смогут изменять или удалять строки, соответствующие запросу.SELECT ... FOR UPDATE
FOR UPDATE
Для получения дополнительных сведений см. Документацию для
select_for_update()
.
Model.objects.bulk_create
в ORM ¶
Этот метод позволяет более эффективно создавать несколько объектов. Это может привести к значительному увеличению производительности, если у вас много объектов.
Django использует это для внутренних целей, что означает, что некоторые операции (например, настройка базы данных для наборов тестов) в результате показали повышение производительности.
Дополнительную bulk_create()
информацию см. В документации.
Улучшено хеширование паролей ¶
Система аутентификации Django ( django.contrib.auth
) хранит пароли с использованием одностороннего алгоритма. Django 1.3 использует алгоритм SHA1 , но увеличение скорости процессора и теоретические атаки показали, что SHA1 не так безопасен, как хотелось бы. Таким образом, Django 1.4 представляет новую систему хранения паролей: по умолчанию Django теперь использует алгоритм PBKDF2 (как рекомендовано NIST ). Вы также можете легко выбрать другой алгоритм (включая популярный алгоритм bcrypt ). Дополнительные сведения см. В разделе Как Django хранит пароли .
Тип документа HTML5 ¶
Мы переключили админку и другие связанные шаблоны на использование типа документа HTML5. Хотя Django будет осторожно поддерживать совместимость со старыми браузерами, это изменение означает, что вы можете использовать любые функции HTML5, которые вам нужны на страницах администратора, без потери валидности HTML или переопределения предоставленных шаблонов для изменения типа документа.
Список фильтров в интерфейсе администратора ¶
До Django 1.4 admin
приложение позволяло указывать фильтры списка изменений, задавая поиск по полю, но не позволяло создавать собственные фильтры. Это было исправлено с помощью простого API (ранее использовавшегося внутри компании и известного как «FilterSpec»). Для получения дополнительных сведений см. Документацию для list_filter
.
Множественная сортировка в админке ¶
Список изменений администратора теперь поддерживает сортировку по нескольким столбцам. Он учитывает все элементы ordering
атрибута, а сортировка по нескольким столбцам путем нажатия на заголовки предназначена для имитации поведения графических интерфейсов рабочего стола. Мы также добавили
get_ordering()
метод динамического определения порядка (т. Е. В зависимости от запроса).
Новые ModelAdmin
методы ¶
Мы добавили save_related()
метод, чтобы
ModelAdmin
упростить настройку того, как связанные объекты сохраняются в админке.
Два других новых ModelAdmin
метода
get_list_display()
и
get_list_display_links()
возможность динамической настройки полей и ссылок, отображаемых в списке изменений администратора.
Администратор инлайн уважает права пользователей ¶
Встроенные админки теперь разрешают только те действия, на которые у пользователя есть разрешение. Для ManyToMany
отношений с автоматически созданной промежуточной моделью (которая не имеет собственных разрешений) разрешение на изменение для связанной модели определяет, есть ли у пользователя разрешение на добавление, изменение или удаление отношений.
Инструменты для криптографической подписи ¶
Django 1.4 добавляет как низкоуровневый API для подписи значений, так и высокоуровневый API для установки и чтения подписанных файлов cookie, что является одним из наиболее распространенных способов использования подписи в веб-приложениях.
Дополнительную информацию см. В документации по криптографической подписи .
Серверная часть сеанса на основе файлов cookie ¶
Django 1.4 представляет бэкэнд сеанса на основе файлов cookie, который использует инструменты криптографической подписи для хранения данных сеанса в браузере клиента.
Предупреждение
Данные сеанса подписываются и проверяются сервером, но не зашифрованы. Это означает, что пользователь может просматривать любые данные, хранящиеся в сеансе, но не может их изменять. Пожалуйста, прочтите документацию для дальнейших разъяснений, прежде чем использовать этот бэкэнд.
Дополнительную информацию см. В документации по серверной части сеанса на основе файлов cookie .
Мастер создания новой формы ¶
Предыдущий FormWizard
from django.contrib.formtools
был заменен новой реализацией, основанной на представлениях на основе классов, представленных в Django 1.3. Он имеет подключаемый API хранилища и не требует от мастера обхода скрытых полей на каждом предыдущем шаге.
Django 1.4 поставляется с серверной частью хранилища на основе сеансов и серверной частью хранилища на основе файлов cookie. Последний использует инструменты для криптографической подписи, также представленные в Django 1.4, для сохранения состояния мастера в файлах cookie пользователя.
reverse_lazy
¶
Была reverse()
добавлена версия с отложенной оценкой, позволяющая использовать реверсирование URL-адресов до загрузки URLconf проекта.
Перевод шаблонов URL ¶
Django теперь может искать языковой префикс в шаблоне URL при использовании новой
i18n_patterns()
вспомогательной функции. Также теперь можно определять переводимые шаблоны URL-адресов с помощью
django.utils.translation.ugettext_lazy()
. См. Раздел
Интернационализация: в шаблонах URL-адресов для получения дополнительной информации о языковом префиксе и способах интернационализации шаблонов URL-адресов.
Поддержка контекстного перевода для и ¶{% trans %}
{% blocktrans %}
Поддержка контекстного перевода, представленная в Django 1.3 с помощью pgettext
функции, была расширена на
теги шаблонов trans
и blocktrans
с помощью context
ключевого слова new .
Настраиваемый SingleObjectMixin
URLConf kwargs ¶
Два новых атрибута,
pk_url_kwarg
и
slug_url_kwarg
, были добавлены для SingleObjectMixin
обеспечения возможности настройки аргументов ключевого слова URLconf, используемых для общих представлений одного объекта.
Теги шаблона присвоения ¶
Была assignment_tag
добавлена новая вспомогательная функция, чтобы template.Library
упростить создание тегов шаблона, которые хранят данные в указанной переменной контекста.
*args
и **kwargs
поддержка вспомогательных функций тегов шаблона ¶
Simple_tag ,
inclusion_tag и вновь введенные assignment_tag
шаблон вспомогательные функции теперь могут принимать любое количество позиционных или именованных аргументов. Например:
@register.simple_tag
def my_tag(a, b, *args, **kwargs):
warning = kwargs['warning']
profile = kwargs['profile']
...
return ...
Затем в шаблоне тегу шаблона может быть передано любое количество аргументов. Например:
{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
Нет оборачивания исключений в TEMPLATE_DEBUG
режиме ¶
В предыдущих версиях Django, всякий раз, когда этот TEMPLATE_DEBUG
параметр был установлен True
, любое исключение, возникающее во время рендеринга шаблона (даже исключения, не связанные с синтаксисом шаблона), было заключено в оболочку TemplateSyntaxError
и повторно вызвано. Это было сделано для того, чтобы предоставить подробную информацию о местоположении источника шаблона на странице отладки 500.
В Django 1.4 исключения больше не обертываются. Вместо этого исходное исключение аннотируется исходной информацией. Это означает, что перехват исключений из рендеринга шаблона теперь согласован независимо от значения
TEMPLATE_DEBUG
, и нет необходимости перехватывать и разворачивать
TemplateSyntaxError
, чтобы отловить другие ошибки.
truncatechars
шаблонный фильтр ¶
Этот новый фильтр усекает строку, чтобы она не превышала указанное количество символов. Усеченные строки заканчиваются переводимой последовательностью многоточия («…»). См. Документацию для truncatechars
получения более подробной информации.
static
тег шаблона ¶
В staticfiles
приложении contrib появился новый
static
тег шаблона для ссылки на файлы, сохраненные в
STATICFILES_STORAGE
бэкэнде хранилища. Он использует метод серверной части хранилища
url
и, следовательно, поддерживает расширенные функции, такие как обслуживание файлов из облачной службы .
CachedStaticFilesStorage
серверная часть хранилища ¶
У staticfiles
приложения contrib теперь есть
django.contrib.staticfiles.storage.CachedStaticFilesStorage
бэкэнд, который кэширует файлы, которые оно сохраняет (при запуске команды collectstatic
управления), добавляя хеш MD5 содержимого файла к имени файла. Например, файл css/styles.css
также будет сохранен как
css/styles.55e7cbb9ba48.css
Простая защита от кликджекинга ¶
Мы добавили промежуточное ПО, чтобы обеспечить простую защиту от кликджекинга с помощью X-Frame-Options
заголовка. Он не включен по умолчанию из соображений обратной совместимости, но вы почти наверняка захотите включить его, чтобы закрыть эту дыру в безопасности для браузеров, поддерживающих заголовок.
Улучшения CSRF ¶
Мы внесли различные улучшения в наши функции CSRF, включая
ensure_csrf_cookie()
декоратор, который может помочь с сайтами с большим количеством AJAX; защита от запросов PUT и DELETE; а
CSRF_COOKIE_SECURE
и CSRF_COOKIE_PATH
настройки, которые могут улучшить безопасность и полезность защиты CSRF. Дополнительную информацию см. В документации CSRF .
Фильтрация отчетов об ошибках ¶
Мы добавили два декоратора функций
sensitive_variables()
и
sensitive_post_parameters()
, чтобы можно было назначать локальные переменные и параметры POST, которые могут содержать конфиденциальную информацию и должны быть отфильтрованы из отчетов об ошибках.
Все параметры POST теперь систематически отфильтровываются из отчетов об ошибках для определенных видов ( login
, password_reset_confirm
, password_change
и
add_view
в django.contrib.auth.views
, а также
user_change_password
в приложении администратора) , чтобы предотвратить утечку конфиденциальной информации , такой как пароли пользователей.
Вы можете переопределить или настроить фильтрацию по умолчанию, написав собственный фильтр . Дополнительные сведения см. В документации по отчетам об ошибках фильтрации .
Расширенная поддержка IPv6 ¶
Django 1.4 теперь может лучше обрабатывать IPv6-адреса с новым
GenericIPAddressField
полем модели, полем
GenericIPAddressField
формы и валидаторами validate_ipv46_address
и
validate_ipv6_address
.
HTML сравнения в тестах ¶
У базовых классов django.test
теперь есть несколько помощников для сравнения HTML, не спотыкаясь о несущественных различиях в пробелах, цитировании / упорядочивании аргументов и закрытии самозакрывающихся тегов. Вы можете либо сравнить HTML напрямую с новыми
утверждениями assertHTMLEqual()
и
assertHTMLNotEqual()
утверждениями, либо использовать html=True
флаг с
assertContains()
и,
assertNotContains()
чтобы проверить, содержит ли ответ клиента данный фрагмент HTML. Дополнительную информацию см. В документации по утверждениям .
Две новые строки формата даты ¶
date
Были добавлены два новых формата для использования в фильтрах шаблонов, тегах шаблонов и локализации формата :
e
- имя часового пояса данного объекта datetimeo
- номер года ISO 8601
Пожалуйста , не забудьте обновить ваши пользовательские файлы формата , если они содержат либо e
или o
в строке формата. Например, в испанском формате локализации ранее использовался только экранированный
d
символ формата:
DATE_FORMAT = r'j \de F \de Y'
Но теперь ему также нужно убежать e
и o
:
DATE_FORMAT = r'j \d\e F \d\e Y'
Для получения дополнительной информации см. date
Документацию.
Незначительные особенности ¶
Django 1.4 также включает несколько небольших улучшений, на которые стоит обратить внимание:
- Более удобная трассировка стека на технической странице 500. Фреймы в трассировке стека, которые ссылаются на код фреймворка Django, затемнены, а фреймы в коде приложения слегка выделены. Это изменение упрощает сканирование трассировки стека на предмет проблем в коде приложения.
- Поддержка табличных пространств в PostgreSQL.
- Настраиваемые имена для
simple_tag()
. - В документации полезная страница обзора безопасности .
django.contrib.auth.models.check_password
Функция была перенесена вdjango.contrib.auth.hashers
модуль. Импорт из старого местоположения по-прежнему будет работать, но вам следует обновить импорт.- У
collectstatic
команды управления теперь есть--clear
возможность удалить все файлы в месте назначения перед копированием или связыванием статических файлов. - Теперь можно загружать фикстуры, содержащие прямые ссылки, при использовании MySQL с движком базы данных InnoDB.
- Новый обработчик ответа 403 был добавлен как
'django.views.defaults.permission_denied'
. Вы можете установить свой собственный обработчик, установив значениеdjango.conf.urls.handler403
. Дополнительную информацию см. В документации о представлении 403 (HTTP запрещено) . - Команда
makemessages
использует новый и более точный лексер JsLex для извлечения переводимых строк из файлов JavaScript.
trans
Шаблонный тег теперь принимает необязательныйas
аргумент , чтобы иметь возможность получить строку перевода без его отображения , но установка переменного контекста шаблона вместо.if
Шаблонный тег теперь поддерживает положения.{% elif %}
Если ваше приложение Django находится за прокси-сервером, вы можете найти новую
SECURE_PROXY_SSL_HEADER
настройку полезной. Это решает проблему того, что ваш прокси-сервер «съедает» тот факт, что запрос пришел через HTTPS. Но используйте этот параметр, только если знаете, что делаете.Новая, обычный текст, версия коды состояния внутренней страницы ошибок HTTP 500 подается , когда
DEBUG
будетTrue
теперь отправляется клиенту , когда Джанго обнаруживает , что запрос возник в коде JavaScript. (is_ajax()
для этого используется.)Как и его HTML-аналог, он содержит набор различной информации о состоянии приложения.
Это должно упростить чтение при отладке взаимодействия с клиентским JavaScript.
Добавлена опция.
makemessages --no-location
Изменен
locmem
бэкэнд кешированияpickle.HIGHEST_PROTOCOL
для лучшей совместимости с другими бэкэндами кеша.Добавлена поддержка в ORM для генерации
SELECT
запросов, содержащих файлы .DISTINCT ON
Теперь
distinct()
QuerySet
метод принимает необязательный список имен полей модели. Если указано, тоDISTINCT
оператор ограничивается этими полями. Это поддерживается только в PostgreSQL.Для получения дополнительных сведений см. Документацию для
distinct()
.На странице входа администратора будет добавлена ссылка для сброса пароля, если вы
'admin_password_reset'
включите URL-адрес с именем в свой urls.py, поэтому подключить встроенный механизм сброса пароля и сделать его доступным теперь намного проще. Подробнее см. Добавление функции сброса пароля .Серверная часть базы данных MySQL теперь может использовать функцию точки сохранения, реализованную в MySQL версии 5.0.3 или новее с механизмом хранения InnoDB.
Теперь можно передавать начальные значения в формы модели, которые являются частью как наборов форм модели, так и наборов форм встроенных моделей, возвращаемых из фабричных функций
modelformset_factory
и,inlineformset_factory
соответственно, точно так же, как с обычными наборами форм. Однако начальные значения применяются только к дополнительным формам, то есть к тем, которые не привязаны к существующему экземпляру модели.Платформа карты сайта теперь может обрабатывать ссылки HTTPS с помощью нового
Sitemap.protocol
атрибута класса.Новый
django.test.SimpleTestCase
подклассunittest.TestCase
светлееdjango.test.TestCase
и рота. Это может быть полезно в тестах, которые не требуют обращения к базе данных. См. Иерархию классов модульного тестирования Django .
Обратно несовместимые изменения в 1.4 ¶
Требуется настройка SECRET_KEY ¶
Запуск Django с пустым или известным значением SECRET_KEY
отключает многие средства защиты Django и может привести к уязвимостям удаленного выполнения кода. Ни один сайт Django не должен запускаться без файла
SECRET_KEY
.
В Django 1.4 запуск Django с пустым файлом SECRET_KEY
вызовет
расширение DeprecationWarning
. В Django 1.5 это вызовет исключение, и Django откажется запускаться. Это немного ускорено по сравнению с обычным путем отказа от поддержки из-за серьезности последствий запуска Django без
SECRET_KEY
.
django.contrib.admin
¶
Включенное приложение администрирования django.contrib.admin
уже давно поставляется с набором статических файлов по умолчанию, таких как JavaScript, изображения и таблицы стилей. В Django 1.3 добавлено новое приложение contrib django.contrib.staticfiles
для универсальной обработки таких файлов и определены соглашения для статических файлов, включенных в приложения.
Начиная с Django 1.4 статические файлы администратора также следуют этому соглашению, чтобы упростить развертывание файлов. В предыдущих версиях Django также было принято определять ADMIN_MEDIA_PREFIX
параметр, указывающий на URL-адрес, по которому статические файлы администратора находятся на веб-сервере. Этот параметр устарел и заменен более общим параметром STATIC_URL
. Теперь Django ожидает найти статические файлы администратора по URL-адресу
<STATIC_URL>/admin/
.
Если вы ранее использовали URL - путь ADMIN_MEDIA_PREFIX
(например
/media/
) , просто убедитесь , STATIC_URL
и STATIC_ROOT
настроены , и ваш веб - сервер правильно выполняет эти файлы. Сервер разработки продолжает обслуживать файлы администратора, как и раньше. Прочтите инструкции по статическим файлам для получения более подробной информации.
Если ваш ADMIN_MEDIA_PREFIX
установлен на конкретный домен (например
http://media.example.com/admin/
), не забудьте также установить
STATIC_URL
правильный URL-адрес - например
http://media.example.com/
,.
Предупреждение
Если вы неявно полагаетесь на путь статических файлов администратора в исходном коде Django, вам необходимо обновить этот путь. Файлы были перемещены из django/contrib/admin/media/
в
django/contrib/admin/static/admin/
.
Поддерживаемые браузеры для админа ¶
У Django не было четкой политики, согласно которой браузеры поддерживаются приложением администратора. Наша новая политика формализует существующие практики: браузеры YUI A-grade должны предоставлять полнофункциональные возможности администрирования, за заметным исключением Internet Explorer 6, который больше не поддерживается.
IE6, выпущенный более 10 лет назад, накладывает множество ограничений на современную веб-разработку. Практические последствия этой политики заключаются в том, что участники могут свободно улучшать админку без учета этих ограничений.
Эта новая политика не влияет на сайты, которые вы разрабатываете с помощью Django. Это относится только к администратору Django. Не стесняйтесь разрабатывать приложения, совместимые с любым диапазоном браузеров.
Удалены иконки админки ¶
В рамках усилий по повышению производительности и удобства использования интерфейса сортировки списков изменений администратора horizontal
и vertical
виджетов «фильтров» некоторые файлы значков были удалены и сгруппированы в два файла спрайтов.
В частности: selector-add.gif
, selector-addall.gif
,
selector-remove.gif
, selector-removeall.gif
,
selector_stacked-add.gif
и selector_stacked-remove.gif
были объединены в selector-icons.gif
; и arrow-up.gif
и
arrow-down.gif
были объединены в sorting-icons.gif
.
Если вы использовали эти значки для настройки администратора, вам нужно будет заменить их своими собственными значками или получить файлы из предыдущей версии.
Имена классов CSS в формах администратора ¶
Чтобы избежать конфликтов с другими общими именами классов CSS (например, «кнопка»), мы добавили префикс («поле-») ко всем именам классов CSS, автоматически генерируемым из имен полей формы в основных административных формах, составных встроенных форм и табличных встроенных клетки. Вам нужно будет учитывать этот префикс в своих таблицах стилей или файлах JavaScript, если вы ранее использовали простые имена полей в качестве селекторов для пользовательских стилей или преобразований JavaScript.
Совместимость со старыми подписанными данными ¶
Django 1.3 изменил механизмы криптографической подписи, используемые в ряде мест в Django. В то время как Django 1.3 сохранил резервные копии, которые принимали бы хэши, созданные предыдущими методами, эти резервные варианты удалены в Django 1.4.
Итак, если вы обновитесь до Django 1.4 напрямую с 1.2 или более ранней версии, вы можете потерять / сделать недействительными определенные части данных, которые были криптографически подписаны с использованием старого метода. Чтобы избежать этого, сначала используйте Django 1.3 в течение определенного периода времени, чтобы подписанные данные истекли естественным образом. Затронутые части подробно описаны ниже: 1) последствия игнорирования этого совета и 2) количество времени, необходимое для запуска Django 1.3, чтобы данные устарели или стали неактуальными.
contrib.sessions
проверка целостности данных- Последствия: пользователь выйдет из системы, и данные сеанса будут потеряны.
- Период времени: определяется пользователем
SESSION_COOKIE_AGE
.
contrib.auth
хеш сброса пароля- Последствия: ссылки для сброса пароля, использованные до обновления, не работают.
- Период времени: определяется пользователем
PASSWORD_RESET_TIMEOUT_DAYS
.
Хэши, связанные с формами: они имеют гораздо более короткий срок жизни и актуальны только для короткого окна, где пользователь может заполнить форму, созданную экземпляром Django перед обновлением, и попытаться отправить ее в обновленный экземпляр Django:
contrib.comments
сформировать хэш безопасности- Последствия: пользователь увидит ошибку проверки «Ошибка хэша безопасности».
- Период времени: ожидаемое количество времени, которое пользователи потратят на заполнение форм комментариев.
FormWizard
хэш безопасности- Последствия: пользователь увидит ошибку об истечении срока действия формы и будет отправлен обратно на первую страницу мастера, при этом введенные данные будут утеряны.
- Период времени: ожидаемое количество времени, которое пользователи потратят на заполнение затронутых форм.
- CSRF проверка
- Примечание. На самом деле это резервный вариант Django 1.1, а не Django 1.2, и он применяется только при обновлении с 1.1.
- Последствия: пользователь увидит ошибку 403 в любой форме POST, защищенной CSRF.
- Период времени: ожидаемое количество времени, которое пользователь потратит на заполнение таких форм.
contrib.auth
последовательность обновления хэша пароля пользователя- Последствия: пароль каждого пользователя будет обновлен до более надежного хэша пароля, когда он будет записан в базу данных в версии 1.4. Это означает, что если вы обновитесь до 1.4, а затем вам потребуется перейти на более раннюю версию 1.3, версия 1.3 не сможет читать обновленные пароли.
- Способ устранения:
PASSWORD_HASHERS
при первоначальном обновлении до версии 1.4 установите использование исходного хеширования пароля. После того, как вы подтвердите, что ваше приложение работает с Django 1.4 и вам не придется откатываться до версии 1.3, включите новые хэши паролей.
django.contrib.flatpages
¶
Начиная с версии 1.4,
FlatpageFallbackMiddleware
добавляется косая черта в конце и выполняется перенаправление только в том случае, если полученный URL ссылается на существующую плоскую страницу. Например, запрос /notaflatpageoravalidurl
в предыдущей версии будет перенаправлять на /notaflatpageoravalidurl/
, что впоследствии вызовет 404. Запрос /notaflatpageoravalidurl
сейчас немедленно вызовет 404.
Кроме того, перенаправления, возвращаемые плоскими страницами, теперь являются постоянными (с кодом состояния 301), чтобы соответствовать поведению CommonMiddleware
.
Сериализация datetime
и ¶time
Вследствие поддержки часовых поясов и в соответствии со спецификацией ECMA-262 мы внесли изменения в сериализатор JSON:
- Он включает часовой пояс для известных объектов datetime. Это вызывает исключение для известных объектов времени.
- Он включает миллисекунды для объектов datetime и time. По-прежнему есть некоторая потеря точности, потому что Python хранит микросекунды (6 цифр), а JSON поддерживает только миллисекунды (3 цифры). Однако это лучше, чем полностью отбрасывать микросекунды.
Мы изменили сериализатор XML для использования формата даты и времени ISO8601. Буква T
используется для отделения части даты от части времени, а не пробела. Информация о часовом поясе включена в [+-]HH:MM
формат.
Хотя сериализаторы теперь используют эти новые форматы при создании фикстур, они все еще могут загружать фикстуры, использующие старый формат.
supports_timezone
изменен на False
для SQLite ¶
Функция базы данных supports_timezone
раньше была True
для SQLite. Действительно, если вы сохранили известный объект datetime, SQLite сохранил строку, которая включала смещение UTC. Однако это смещение было проигнорировано при загрузке значения обратно из базы данных, что могло повредить данные.
В контексте поддержки часовых поясов этот флаг был изменен на False
, и теперь дата и время хранятся без информации о часовом поясе в SQLite. Когда
USE_TZ
есть False
, если вы попытаетесь сохранить известный объект datetime, Django выдаст исключение.
MySQLdb
-специфические исключения ¶
Исторически сложилось так, что серверная часть MySQL MySQLdb.OperationalError
срабатывала, когда запрос вызывал исключение. Мы исправили эту ошибку и теперь делаем рейз
django.db.DatabaseError
. Если вы тестировали
MySQLdb.OperationalError
, вам нужно обновить свои except
предложения.
Расположение потока подключения к базе данных ¶
DatabaseWrapper
объекты (т. е. объекты соединения, на которые ссылается
django.db.connection
и django.db.connections["some_alias"]
) раньше были локальными для потока. Теперь они являются глобальными объектами, которые потенциально могут использоваться несколькими потоками. Хотя отдельные объекты соединения теперь являются глобальными, django.db.connections
словарь, ссылающийся на эти объекты, по-прежнему является локальным для потока. Поэтому, если вы просто используете ORM или,
DatabaseWrapper.cursor()
то поведение останется таким же, как и раньше. Обратите внимание, однако, что django.db.connection
это больше не ссылается напрямую на DatabaseWrapper
объект по умолчанию и теперь является прокси для доступа к атрибутам этого объекта. Если вам нужен доступ к фактическому DatabaseWrapper
объекту, используйте django.db.connections[DEFAULT_DB_ALIAS]
вместо него.
В рамках этого изменения все базовые соединения SQLite теперь включены для потенциального совместного использования потоков (путем передачи check_same_thread=False
атрибута в pysqlite). DatabaseWrapper
однако сохраняет предыдущее поведение, отключая совместное использование потоков по умолчанию, поэтому это не влияет на какой-либо существующий код, который полностью полагается на ORM или на DatabaseWrapper.cursor()
.
Наконец, хотя теперь можно передавать соединения между потоками, Django не прилагает никаких усилий для синхронизации доступа к базовому бэкэнду. Поведение параллелизма определяется базовой внутренней реализацией. Подробности смотрите в их документации.
COMMENTS_BANNED_USERS_GROUP
настройка ¶
Комментарии Django исторически поддерживали исключение комментариев специальной группы пользователей, но мы никогда не документировали эту функцию должным образом и не применяли исключение в других частях приложения, таких как теги шаблонов. Чтобы решить эту проблему, мы удалили код из класса фида.
Если вы полагаетесь на эту функцию и хотите восстановить прежнее поведение, используйте настраиваемый менеджер модели комментариев, чтобы исключить группу пользователей, например:
from django.conf import settings
from django.contrib.comments.managers import CommentManager
class BanningCommentManager(CommentManager):
def get_query_set(self):
qs = super().get_query_set()
if getattr(settings, 'COMMENTS_BANNED_USERS_GROUP', None):
where = ['user_id NOT IN (SELECT user_id FROM auth_user_groups WHERE group_id = %s)']
params = [settings.COMMENTS_BANNED_USERS_GROUP]
qs = qs.extra(where=where, params=params)
return qs
Сохраните этот менеджер моделей в своем приложении для пользовательских комментариев (например, в
my_comments_app/managers.py
) и добавьте его в свою модель приложения для пользовательских комментариев:
from django.db import models
from django.contrib.comments.models import Comment
from my_comments_app.managers import BanningCommentManager
class CommentWithTitle(Comment):
title = models.CharField(max_length=300)
objects = BanningCommentManager()
IGNORABLE_404_STARTS
и IGNORABLE_404_ENDS
настройки ¶
До Django 1.3 можно было исключить некоторые URL-адреса из отчетов об ошибках 404 Django,
добавляя префиксы к
IGNORABLE_404_STARTS
и суффиксы к IGNORABLE_404_ENDS
.
В Django 1.4 эти две настройки заменены на
IGNORABLE_404_URLS
, который представляет собой список скомпилированных регулярных выражений. Django не отправляет электронное письмо с ошибками 404 для URL-адресов, соответствующих любому из них.
Кроме того, предыдущие настройки имели довольно произвольные значения по умолчанию:
IGNORABLE_404_STARTS = ('/cgi-bin/', '/_vti_bin', '/_vti_inf')
IGNORABLE_404_ENDS = ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi',
'favicon.ico', '.php')
Django не должен решать, есть ли на вашем веб-сайте унаследованный /cgi-bin/
раздел или favicon.ico
. Как следствие, все значения по умолчанию
IGNORABLE_404_URLS
, IGNORABLE_404_STARTS
и
IGNORABLE_404_ENDS
теперь пусты.
Если вы настроили IGNORABLE_404_STARTS
или IGNORABLE_404_ENDS
, или если хотите сохранить старое значение по умолчанию, вам следует добавить следующие строки в свой файл настроек:
import re
IGNORABLE_404_URLS = (
# for each <prefix> in IGNORABLE_404_STARTS
re.compile(r'^<prefix>'),
# for each <suffix> in IGNORABLE_404_ENDS
re.compile(r'<suffix>$'),
)
Не забывайте экранировать символы, которые имеют особое значение в регулярном выражении, например точки.
Защита CSRF расширена до PUT и DELETE ¶
Ранее защита Django от CSRF обеспечивала защиту только от запросов POST. Поскольку использование методов PUT и DELETE в приложениях AJAX становится все более распространенным, теперь мы защищаем все методы, не определенные как безопасныеRFC 2616 - то есть мы исключаем GET, HEAD, OPTIONS и TRACE, и мы обеспечиваем защиту всего остального.
Если вы используете методы PUT или DELETE в приложениях AJAX, ознакомьтесь с инструкциями по использованию AJAX и CSRF .
Просмотр сброса пароля теперь поддерживает subject_template_name
¶
password_reset
Вид в django.contrib.auth
настоящее принимает
subject_template_name
параметр, который передается с паролем сохранить форму в качестве ключевого слова аргумента. Если вы используете это представление с настраиваемой формой сброса пароля, вам необходимо убедиться, что save()
метод вашей формы принимает этот аргумент ключевого слова.
django.core.template_loaders
¶
Это был псевдоним django.template.loader
с 2005 года, и мы удалили его без предупреждения из-за продолжительности устаревания. Если ваш код все еще ссылается на это, используйте django.template.loader
вместо этого.
django.db.models.fields.URLField.verify_exists
¶
Эта функция была удалена из-за неразрешимых проблем с производительностью и безопасностью. Любое существующее использование verify_exists
должно быть удалено.
django.core.files.storage.Storage.open
¶
open
Метод базового класса Storage используется принять неясный параметр
, mixin
который позволял динамически изменять базовые классы возвращенного объекта файла. Это было удалено. В редких случаях, когда вы полагались на
mixin
параметр, вы можете легко добиться того же, переопределив open
метод, например:
from django.core.files import File
from django.core.files.storage import FileSystemStorage
class Spam(File):
"""
Spam, spam, spam, spam and spam.
"""
def ham(self):
return 'eggs'
class SpamStorage(FileSystemStorage):
"""
A custom file storage backend.
"""
def open(self, name, mode='rb'):
return Spam(open(self.path(name), mode))
Десериализатор YAML теперь использует yaml.safe_load
¶
yaml.load
может создать любой объект Python, который может вызвать выполнение произвольного кода, если вы обрабатываете документ YAML, полученный из ненадежного источника. Эта функция не требуется для десериализатора Django YAML, основное назначение которого - загрузка фикстур, состоящих из простых объектов. Несмотря на то, что фикстуры являются надежными данными, десериализатор YAML теперь использует их yaml.safe_load
для дополнительной безопасности.
Сессионные куки теперь имеют httponly
флаг по умолчанию ¶
Сеансовые куки-файлы теперь включают httponly
атрибут по умолчанию, чтобы уменьшить влияние потенциальных XSS-атак. В результате этого изменения данные cookie сеанса, включая sessionid, больше не доступны из JavaScript во многих браузерах. Для строгой обратной совместимости используйте в файле настроек.SESSION_COOKIE_HTTPONLY = False
Не urlize
фильтр больше не ускользает каждый URL ¶
Когда URL-адрес содержит %xx
последовательность, состоящую xx
из двух шестнадцатеричных цифр, urlize
теперь предполагается, что URL-адрес уже экранирован, и не применяет экранирование URL-адреса снова. Это неверно для URL-адресов, чья форма без кавычек содержит %xx
последовательность, но такие URL-адреса очень маловероятны, потому что они также сбивают с толку браузеры.
assertTemplateUsed
и assertTemplateNotUsed
как менеджер контекста ¶
Теперь можно проверить, использовался ли шаблон в блоке кода, с помощью assertTemplateUsed()
и
assertTemplateNotUsed()
. И их можно использовать как диспетчер контекста:
with self.assertTemplateUsed('index.html'):
render_to_string('index.html')
with self.assertTemplateNotUsed('base.html'):
render_to_string('index.html')
См. Дополнительную информацию в документации по утверждениям .
Подключения к базе данных после запуска набора тестов ¶
Средство выполнения тестов по умолчанию больше не восстанавливает соединения с базой данных после выполнения тестов. Это предотвращает доступ к производственной базе данных для потенциальных потоков, которые все еще работают и пытаются создавать новые соединения.
Если ваш код полагался на подключения к производственной базе данных, создаваемой после выполнения тестов, вы можете восстановить предыдущее поведение, создав подклассы DjangoTestRunner
и переопределив его teardown_databases()
метод.
Выход ¶manage.py help
manage.py help
теперь группирует доступные команды по приложениям. Если вы зависели от вывода этой команды - если вы, например, проанализировали его, - вам необходимо обновить свой код. Чтобы получить список всех доступных команд управления в сценарии, используйте
вместо этого.manage.py help --commands
extends
тег шаблона ¶
Раньше extends
тег использовал ошибочный метод анализа аргументов, что могло привести к ошибочному рассмотрению аргумента как строкового литерала, когда это не так. Теперь он использует parser.compile_filter
, как и другие теги.
Внутренняя часть тега не является частью официального стабильного API, но в интересах полного раскрытия информации ExtendsNode.__init__
определение было изменено, что может нарушить работу любых настраиваемых тегов, использующих этот класс.
Загрузка некоторых неполных светильников больше не работает ¶
До версии 1.4 значение по умолчанию было вставлено для объектов фикстуры, у которых отсутствовала конкретная дата или значение datetime, когда для поля были установлены auto_now или auto_now_add. Это было то, что не должно было работать, и в версии 1.4 загрузка таких неполных приспособлений не удастся. Поскольку фикстуры являются необработанным импортом, они должны явно указывать все значения полей, независимо от параметров поля в модели.
Многопоточность сервера разработки ¶
Сервер разработки теперь по умолчанию является многопоточным. Используйте
параметр, чтобы отключить использование потоковой передачи на сервере разработки:runserver --nothreading
django-admin.py runserver --nothreading
Атрибуты отключены в уценке при установке безопасного режима ¶
До Django 1.4 атрибуты включались в любой вывод уценки независимо от настройки безопасного режима фильтра. В версии> 2.1 библиотеки Python-Markdown была добавлена опция enable_attributes. Когда безопасный аргумент передается уценки фильтра, как safe_mode=True
и
enable_attributes=False
параметры установлены. Если используется версия библиотеки Python-Markdown ниже 2.1, выдается предупреждение о том, что вывод небезопасен.
FormMixin get_initial возвращает словарь для конкретного экземпляра ¶
В Django 1.3 get_initial
метод
django.views.generic.edit.FormMixin
класса возвращал initial
словарь класса . Это было исправлено, чтобы возвращать копию этого словаря, поэтому экземпляры формы могут изменять свои начальные данные, не вмешиваясь в переменную класса.
Функции, устаревшие в версии 1.4 ¶
Старые стили вызова cache_page
декоратора ¶
Некоторые устаревшие способы вызова cache_page()
устарели. Пожалуйста, обратитесь к документации, чтобы узнать, как правильно использовать этот декоратор.
Поддержка версий PostgreSQL старше 8.2 ¶
Django 1.3 отказался от поддержки версий PostgreSQL старше 8.0, и мы предложили использовать более свежую версию из-за повышения производительности и, что более важно, близился конец периодов поддержки исходных версий для 8.0 и 8.1 (ноябрь 2010 г.).
Django 1.4 развивает эту политику и устанавливает минимальную официально поддерживаемую версию PostgreSQL 8.2.
Исключения запросов теперь всегда регистрируются ¶
Когда мы добавили поддержку ведения журнала в Django в версии 1.3, поддержка электронной почты при ошибках администратора была перенесена в файл
django.utils.log.AdminEmailHandler
, прикрепленный к
'django.request'
регистратору. Чтобы поддерживать установленное поведение сообщений об ошибках, 'django.request'
регистратор вызывался только тогда, когда
DEBUG
был False
.
Чтобы повысить гибкость ведения журнала ошибок для запросов,
'django.request'
регистратор теперь вызывается независимо от значения
DEBUG
, а файл настроек по умолчанию для новых проектов теперь включает отдельный фильтр, прикрепленный к, django.utils.log.AdminEmailHandler
чтобы предотвратить электронные сообщения об ошибках администратора в DEBUG
режиме:
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
Если ваш проект был создан до этого изменения, ваши LOGGING
настройки не будут включать этот новый фильтр. Чтобы поддерживать обратную совместимость, Django обнаружит, что ваша 'mail_admins'
конфигурация обработчика не содержит 'filters'
раздела, и автоматически добавит этот фильтр для вас и выдаст предупреждение об отложении поддержки. Это станет предупреждением об устаревании в Django 1.5, а в Django 1.6 прокладка обратной совместимости будет полностью удалена.
Наличие любого 'filters'
ключа в 'mail_admins'
обработчике отключит эту прокладку обратной совместимости и предупреждение об устаревании.
django.conf.urls.defaults
¶
До Django 1.3, include()
, patterns()
, и url()
функции, а также handler404
и handler500
были расположены в django.conf.urls.defaults
модуле.
В Django 1.4 они живут в django.conf.urls
.
django.contrib.databrowse
¶
Databrowse какое-то время не претерпевал активного развития, и это не показывает никаких признаков изменений. Было предложение для проекта GSOC интегрировать функцию просмотра данных в админку, но прогресса не было. Хотя Databrowse устарел, расширение,
django.contrib.admin
предоставляющее аналогичный набор функций, все еще возможно.
Код, на котором работает Databrowse, лицензируется на тех же условиях, что и сам Django, поэтому он доступен для принятия отдельным лицом или группой в качестве стороннего проекта.
django.core.management.setup_environ
¶
Эта функция временно изменена sys.path
, чтобы сделать родительский каталог «проект» доступным для импорта в старом плоском startproject
макете. Эта функция теперь устарела, так как обходные пути ее пути больше не нужны с новым manage.py
макетом проекта по умолчанию.
Эта функция никогда не была документирована и не была частью общедоступного API, но ее широко рекомендовали для использования при настройке «среды Django» для пользовательского скрипта. Эти варианты использования следует заменить установкойDJANGO_SETTINGS_MODULE
переменная окружения или использование django.conf.settings.configure()
.
django.core.management.execute_manager
¶
Эта функция ранее использовалась manage.py
для выполнения команды управления. Он идентичен
django.core.management.execute_from_command_line
, за исключением того, что он сначала вызывает setup_environ
, что теперь не рекомендуется. Таким образом, execute_manager
также устарел; execute_from_command_line
можно использовать вместо этого. Ни одна из этих функций не задокументирована как часть общедоступного API, но необходим путь устаревания из-за использования в существующих manage.py
файлах.
is_safe
и needs_autoescape
атрибуты шаблонных фильтров ¶
Два флага is_safe
и needs_autoescape
определяют, как каждый фильтр шаблона взаимодействует с поведением автоматического экранирования Django. Раньше они были атрибутами функции фильтра:
@register.filter
def noop(value):
return value
noop.is_safe = True
Однако этот прием вызвал некоторые проблемы, особенно в сочетании с декораторами @stringfilter
. Теперь флаги являются ключевыми аргументами @register.filter
:
@register.filter(is_safe=True)
def noop(value):
return value
См. Фильтры и автоматическое экранирование для получения дополнительной информации.
Wildcard расширение имен приложений в INSTALLED_APPS
¶
До Django 1.3 INSTALLED_APPS
допускались подстановочные знаки в именах приложений, например django.contrib.*
. Расширение было выполнено реализацией файловой системы . К сожалению, надежно это сделать нельзя.from <package> import *
Это поведение никогда не было задокументировано. Поскольку он не является питонным, он был удален в Django 1.4. Если вы полагались на него, вы должны отредактировать файл настроек, чтобы явно перечислить все ваши приложения.
HttpRequest.raw_post_data
переименован в HttpRequest.body
¶
Название этого атрибута было сбивающим с толку HttpRequest.raw_post_data
, но на самом деле он представлял собой тело HTTP-запроса. Он был переименован в
HttpRequest.body
и больше HttpRequest.raw_post_data
не поддерживается.
django.contrib.sitemaps
исправление ошибки с потенциальными последствиями для производительности ¶
В предыдущих версиях Paginator
объекты, используемые в классах карты сайта, кэшировались, что могло привести к устареванию карт сайта. Мы удалили кеширование, поэтому каждый запрос к карте сайта теперь создает новый объект Paginator и вызывает
items()
метод
Sitemap
подкласса. В зависимости от того, что делает ваш
items()
метод, это может отрицательно сказаться на производительности. Чтобы уменьшить влияние на производительность, рассмотрите возможность использования инфраструктуры кэширования в своем Sitemap
подклассе.
Версии Python-Markdown до 2.1 ¶
Версии Python-Markdown до 2.1 не поддерживают возможность отключения атрибутов. В целях безопасности более ранние версии этой библиотеки не будут поддерживаться приложением разметки contrib в версии 1.5 в соответствии с ускоренным графиком прекращения поддержки.