Выполнение действий после фиксации транзакции¶

Новый хук on_commit() позволяет выполнять действия после успешной фиксации транзакции базы данных. Это полезно для таких задач, как отправка уведомлений по электронной почте, создание задач в очереди или аннулирование кешей.

Эта функциональность из пакета django-transaction-hooks была интегрирована в Django.

Проверка пароля¶

Django теперь предлагает проверку пароля, чтобы предотвратить использование пользователями слабых паролей. Проверка интегрирована в прилагаемые формы смены и сброса пароля и ее легко интегрировать в любой другой код. Проверка выполняется одним или несколькими валидаторами, настроенными в новом параметре AUTH_PASSWORD_VALIDATORS.

В Django включены четыре валидатора, которые могут обеспечить минимальную длину, сравнить пароль с атрибутами пользователя, такими как его имя, убедиться, что пароли не полностью числовые, или сверить их с включенным списком общих паролей. Вы можете объединить несколько валидаторов, а некоторые валидаторы имеют собственные параметры конфигурации. Например, вы можете предоставить собственный список общих паролей. Каждый валидатор предоставляет текст справки, объясняющий пользователю его требования.

По умолчанию проверка не выполняется и принимаются все пароли, поэтому, если вы не установите AUTH_PASSWORD_VALIDATORS, вы не увидите никаких изменений. В новых проектах, созданных с использованием шаблона startproject по умолчанию, включен простой набор валидаторов. Чтобы включить базовую проверку во включенных формах аутентификации вашего проекта, вы можете установить, например:

AUTH_PASSWORD_VALIDATORS = [
    {
        "NAME": "django.contrib.auth.password_validation.UserAttributeSimilarityValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.MinimumLengthValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.CommonPasswordValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.NumericPasswordValidator",
    },
]

Дополнительную информацию см. в разделе проверка пароля.

Миксины разрешений для представлений на основе классов¶

Django теперь поставляется с миксинами AccessMixin, LoginRequiredMixin, PermissionRequiredMixin, и UserPassesTestMixin, чтобы обеспечить функциональность django.contrib.auth.decorators для представлений на основе классов. Эти миксины были взяты из проекта django-braces или, по крайней мере, вдохновлены им.

Однако между реализацией Django и ``django-braces`' есть несколько различий:

• Атрибут raise_Exception может иметь только значение True или False. Пользовательские исключения или вызываемые объекты не поддерживаются.

• Метод handle_no_permission() не принимает аргумент request. Текущий запрос доступен в self.request.

• Пользовательская test_func() UserPassesTestMixin` не принимает аргумент user. Текущий пользователь доступен в self.request.user.

• Атрибут permission_required поддерживает строку (определяющую одно разрешение) или список/кортеж строк (определяющий несколько разрешений), которые необходимо выполнить для предоставления доступа.

• Новый атрибут permission_denied_message позволяет передавать сообщение в исключение PermissionDenied.

Новый стиль для contrib.admin¶

Администратор имеет современный плоский дизайн с новыми значками SVG, которые идеально смотрятся на экранах HiDPI. Он по-прежнему обеспечивает полнофункциональную работу с браузерами «А-класса YUI». В более старых браузерах могут наблюдаться различные уровни постепенного снижения производительности.

Параллельное выполнение тестов¶

Команда test теперь поддерживает опцию --parallel для параллельного запуска тестов проекта в нескольких процессах.

Каждый процесс получает свою собственную базу данных. Вы должны гарантировать, что разные тестовые примеры не будут иметь доступ к одним и тем же ресурсам. Например, тестовые примеры, затрагивающие файловую систему, должны создать временный каталог для собственного использования.

Эта опция включена по умолчанию для собственного набора тестов Django:

• ОС поддерживает это (все, кроме Windows)

• серверная часть базы данных поддерживает это (все встроенные серверные части, кроме Oracle)

Минорные изменения¶

Серверный API базы данных¶

• Несколько новых тестов полагаются на способность серверной части анализировать значения столбцов по умолчанию (возвращая результат как «Field.default»). Вы можете установить для функции базы данных can_introspect_default значение False, если ваш сервер не реализует это. Возможно, вы захотите просмотреть реализацию на бэкэндах, которые Django включает для справки (#24245).

• Регистрация глобального адаптера или преобразователя на уровне модуля DB-API для обработки информации о часовом поясе значений datetime, передаваемых как параметры запроса или возвращаемых как результаты запроса в базах данных, которые не поддерживают часовые пояса, не рекомендуется. Он может конфликтовать с другими библиотеками.

  Рекомендуемый способ добавить часовой пояс к значениям datetime, полученным из базы данных, — это зарегистрировать преобразователь для DateTimeField в DatabaseOperations.get_db_converters().

  Функция базы данных Needs_datetime_string_cast была удалена. Серверные части базы данных, которые его устанавливают, должны вместо этого зарегистрировать преобразователь, как описано выше.

• Методы DatabaseOperations.value_to_db_<type>() были переименованы в adapt_<type>field_value(), чтобы отразить методы convert_<type>field_value().

• Чтобы использовать новый поиск по дате, сторонним базам данных может потребоваться реализация метода DatabaseOperations.datetime_cast_date_sql().

• Был добавлен метод DatabaseOperations.time_extract_sql(). Он вызывает существующий метод date_extract_sql(). Этот метод переопределяется серверной частью SQLite для добавления поиска времени (час, минута, секунда) в TimeField и может потребоваться сторонним базам данных.

• Метод DatabaseOperations.datetime_cast_sql() (не путать с упомянутым выше DatabaseOperations.datetime_cast_date_sql()) был удален. Этот метод служил для форматирования дат в Oracle задолго до версии 1.0, но уже много лет не переопределялся ни одним основным сервером и не вызывался нигде в коде или тестах Django.

• Чтобы поддерживать распараллеливание тестов, вы должны реализовать метод DatabaseCreation._clone_test_db() и установить DatabaseFeatures.can_clone_databases = True. Возможно, вам придется изменить DatabaseCreation.get_test_db_clone_settings().

Настройки по умолчанию, которые были кортежами, теперь представляют собой списки.¶

Настройки по умолчанию в django.conf.global_settings представляли собой комбинацию списков и кортежей. Все настройки, которые раньше были кортежами, теперь представляют собой списки.

Атрибут is_usable в загрузчиках шаблонов удален.¶

Загрузчики шаблонов Django ранее требовали определения атрибута is_usable. Если в настройках шаблона был настроен загрузчик и этот атрибут имел значение «False», то загрузчик будет молча игнорироваться. На практике это использовалось загрузчиком яиц только для определения того, установлены ли setuptools. Атрибут is_usable теперь удален, и вместо этого загрузчик яиц не работает во время выполнения, если setuptools не установлен.

Связанный набор прямого присвоения¶

Прямое назначение связанных объектов в ORM, используемое для выполнения clear() с последующим вызовом add(). Это вызывало неоправданно большие изменения данных и не позволяло использовать сигнал m2m_changed для отслеживания отдельных изменений в отношениях «многие ко многим».

Прямое назначение теперь основано на новом методе set() для связанных менеджеров, который по умолчанию обрабатывает только изменения между существующим связанным набором и вновь назначенным. Предыдущее поведение можно восстановить, заменив прямое присвоение вызовом set() с аргументом ключевого слова clear=True.

ModelForm и, следовательно, ModelAdmin внутренне полагаются на прямое присвоение для отношений «многие ко многим» и, как следствие, теперь используют новое поведение.

Загрузчики шаблонов на основе файловой системы улавливают более конкретные исключения.¶

При использовании загрузчиков шаблонов filesystem.Loader или app_directories.Loader в более ранних версиях Django выдавалась ошибка TemplateDoesNotExist, если источник шаблона существовал, но был нечитаемым. Это могло произойти при многих обстоятельствах, например, если у Django не было разрешений на открытие файла или если источником шаблона был каталог. Теперь Django отключает исключение только в том случае, если источник шаблона не существует. Все остальные ситуации приводят к возникновению исходной ошибки IOError.

HTTP-перенаправления больше не требуют абсолютных URI.¶

Относительные перенаправления больше не преобразуются в абсолютные URI. RFC 2616 требовал, чтобы заголовок Location в ответах на перенаправление был абсолютным URI, но он был заменен RFC 7231, который допускает относительные URI в Location, признавая реальную практику пользовательских агентов, почти все из которых их поддерживают.

Следовательно, ожидаемые URL-адреса, передаваемые в assertRedirects, как правило, больше не должны включать схему и доменную часть URL-адресов. Например, self.assertRedirects(response, 'http://testserver/some-url/') следует заменить на self.assertRedirects(response, '/some-url/') (если только перенаправление не содержало абсолютный URL-адрес).

В том редком случае, когда вам нужно старое поведение (обнаруженное в древней версии Apache с mod_scgi, которая интерпретирует относительное перенаправление как «внутреннее перенаправление»), вы можете восстановить его, написав собственное промежуточное программное обеспечение:

class LocationHeaderFix(object):
    def process_response(self, request, response):
        if "Location" in response:
            response["Location"] = request.build_absolute_uri(response["Location"])
        return response

Прекращена поддержка PostgreSQL 9.0.¶

Поддержка исходной версии PostgreSQL 9.0 закончилась в сентябре 2015 года. Как следствие, Django 1.9 устанавливает 9.1 в качестве минимальной версии PostgreSQL, которую он официально поддерживает.

Прекращена поддержка Oracle 11.1.¶

Восходящая поддержка Oracle 11.1 закончилась в августе 2015 года. Как следствие, Django 1.9 устанавливает 11.2 в качестве минимальной версии Oracle, которую он официально поддерживает.

Массовое поведение метода add() связанных менеджеров¶

Для повышения производительности методы add() связанных менеджеров, созданных с помощью ForeignKey и GenericForeignKey, были изменены с серии вызовов Model.save() на один вызов QuerySet.update(). Это изменение означает, что сигналы pre_save и post_save больше не отправляются. Вы можете использовать аргумент ключевого слова Bulk=False, чтобы вернуться к предыдущему поведению.

Шаблоны LoaderOrigin и StringOrigin удалены.¶

В предыдущих версиях Django, когда механизм шаблонов инициализировался с отладкой как True, экземпляр django.template.loader.LoaderOrigin или django.template.base.StringOrigin устанавливался в качестве атрибута origin объекта шаблона. Эти классы были объединены в Origin и теперь всегда устанавливаются независимо от настроек отладки движка. Для минимального уровня обратной совместимости имена старых классов будут сохраняться как псевдонимы нового класса Origin до Django 2.0.

Изменения в конфигурации ведения журнала по умолчанию¶

Чтобы упростить написание пользовательских конфигураций журналирования, конфигурация журналирования Django по умолчанию больше не определяет логгеры django.request и django.security. Вместо этого он определяет один регистратор django, фильтруемый на уровне INFO, с двумя обработчиками:

• console: фильтруется на уровне INFO и активен только в том случае, если DEBUG=True.

• mail_admins: фильтруется на уровне ERROR и активен только в том случае, если DEBUG=False.

Если вы не отменяете стандартное ведение журнала Django, вы должны увидеть минимальные изменения в поведении, но вы можете увидеть некоторые новые журналы, например, на консоли runserver.

Если вы переопределяете ведение журнала Django по умолчанию, вам следует проверить, как ваша конфигурация объединяется с новыми настройками по умолчанию.

Детали HttpRequest в отчете об ошибках¶

Было лишним отображать полную информацию о HttpRequest каждый раз, когда он появлялся как переменная фрейма стека в HTML-версии страницы отладки и в электронном письме об ошибке. Таким образом, HTTP-запрос теперь будет отображать то же стандартное представление, что и другие переменные («repr(request)»). В результате метод ExceptionReporterFilter.get_request_repr() и недокументированная функция django.http.build_request_repr() были удалены.

Содержимое текстовой версии электронного письма было изменено, чтобы обеспечить обратную трассировку той же структуры, что и в случае запросов AJAX. Детали трассировки отображаются с помощью метода ExceptionReporter.get_traceback_text().

Удаление глобальных адаптеров и преобразователей даты и времени с учетом часового пояса.¶

Django больше не регистрирует глобальные адаптеры и конвертеры для управления информацией о часовом поясе для значений datetime, отправляемых в базу данных в качестве параметров запроса или считываемых из базы данных в результатах запроса. Это изменение затрагивает проекты, отвечающие всем следующим условиям:

• Параметр USE_TZ имеет значение True.

• База данных — SQLite, MySQL, Oracle или сторонняя база данных, не поддерживающая часовые пояса. Если есть сомнения, вы можете проверить значение connection.features.supports_timezones.

• Код запрашивает базу данных за пределами ORM, обычно с помощью «cursor.execute(sql, params)».

Если вы передаете в такие запросы параметры datetime, вам следует преобразовать их в простые значения даты и времени в формате UTC:

from django.utils import timezone

param = timezone.make_naive(param, timezone.utc)

Если вы этого не сделаете, преобразование будет выполнено, как и в более ранних версиях (с предупреждением об устаревании), вплоть до Django 1.11. Django 2.0 не выполняет никаких преобразований, что может привести к повреждению данных.

Если вы читаете значения datetime из результатов, они будут наивными, а не осознанными. Вы можете компенсировать следующим образом:

from django.utils import timezone

value = timezone.make_aware(value, timezone.utc)

Вам не нужно ничего из этого, если вы запрашиваете базу данных через ORM, даже если вы используете запросы raw(). ORM заботится об управлении информацией о часовом поясе.

Модули тегов шаблонов импортируются при настройке шаблонов.¶

Серверная часть DjangoTemplates теперь выполняет обнаружение установленных модулей тегов шаблона при создании экземпляра. Это обновление позволяет явно предоставлять библиотеки через ключ 'libraries' OPTIONS при определении DjangoTemplates бэкенда. Ошибки импорта или синтаксиса в модулях тегов шаблонов теперь завершаются ошибкой на ранних стадиях создания экземпляра, а не при первой компиляции шаблона с тегом {% load %}.

django.template.base.add_to_builtins() удален.¶

Хотя это был частный API, в проектах обычно использовался add_to_builtins(), чтобы сделать теги и фильтры шаблона доступными без использования тега {% load %}. Этот API формализован. Проекты теперь должны определять встроенные библиотеки с помощью ключа 'builtins' OPTIONS при определении DjangoTemplates бэкенда.

simple_tag теперь оборачивает вывод тега в conditional_escape¶

В общем, теги шаблонов не экранируют свое содержимое автоматически, и это поведение документировано. Для таких тегов, как inclusion_tag, это не проблема, поскольку включенный шаблон будет выполнять автоматическое экранирование. Для assignment_tag() вывод будет экранирован, когда он используется в качестве переменной в шаблоне.

Однако в предполагаемых случаях использования simple_tag очень легко получить неверный HTML и, возможно, XSS-эксплойт. Например:

@register.simple_tag(takes_context=True)
def greeting(context):
    return "Hello {0}!".format(context["request"].user.first_name)

В более старых версиях Django это будет проблемой XSS, поскольку user.first_name не экранируется.

В Django 1.9 это исправлено: если в контексте шаблона установлено autoescape=True (по умолчанию), то simple_tag обернет вывод функции тега с помощью conditional_escape().

Чтобы исправить ваши simple_tag, лучше всего применить следующие методы:

• Любой код, генерирующий HTML, должен использовать либо систему шаблонов, либо format_html().

• Если вывод simple_tag нуждается в экранировании, используйте escape() или conditional_escape().

• Если вы абсолютно уверены, что выводите HTML из надежного источника (например, поля CMS, в котором хранится HTML, введенный администраторами), вы можете пометить его как таковой с помощью mark_safe().

Теги, соответствующие этим правилам, будут корректными и безопасными независимо от того, запускаются ли они в Django 1.9+ или более ранней версии.

Paginator.page_range¶

Paginator.page_range теперь является итератором, а не списком.

В версиях Django до 1.8 Paginator.page_range возвращал список в Python 2 и диапазон в Python 3. Django 1.8 постоянно возвращал список, но итератор более эффективен.

Существующий код, который зависит от конкретных функций списка, таких как индексирование, можно портировать путем преобразования итератора в список с помощью list().

Неявный поиск QuerySet __in удален.¶

В более ранних версиях такие запросы, как:

Model.objects.filter(related_id=RelatedModel.objects.all())

неявно преобразуется в:

Model.objects.filter(related_id__in=RelatedModel.objects.all())

в результате получается SQL типа "related_id IN (SELECT id FROM ...)".

Этого неявного __in больше не происходит, поэтому SQL-код «IN» теперь равен «=», и если подзапрос возвращает несколько результатов, по крайней мере некоторые базы данных выдадут ошибку.

contrib.admin поддержка браузера¶

Администратор больше не поддерживает Internet Explorer 8 и более ранние версии, поскольку срок службы этих браузеров истек.

CSS и изображения для поддержки Internet Explorer 6 и 7 были удалены. Значки PNG и GIF заменены значками SVG, которые не поддерживаются Internet Explorer 8 и более ранними версиями.

Библиотека jQuery, встроенная в админку, обновлена ​​с версии 1.11.2 до 2.1.4. jQuery 2.x имеет тот же API, что и jQuery 1.x, но не поддерживает Internet Explorer 6, 7 или 8, что обеспечивает лучшую производительность и меньший размер файла. Если вам нужна поддержка IE8 и вы также должны использовать последнюю версию Django, вы можете переопределить копию jQuery администратора своей собственной, создав приложение Django со следующей структурой:

app/static/admin/js/vendor/
    jquery.js
    jquery.min.js

SyntaxError при установке Django setuptools 5.5.x¶

При установке Django 1.9 или 1.9.1 с помощью setuptools 5.5.x вы увидите:

Compiling django/conf/app_template/apps.py ...
  File "django/conf/app_template/apps.py", line 4
    class {{ camel_case_app_name }}Config(AppConfig):
          ^
SyntaxError: invalid syntax

Compiling django/conf/app_template/models.py ...
  File "django/conf/app_template/models.py", line 1
    {{ unicode_literals }}from django.db import models
                             ^
SyntaxError: invalid syntax

Эти ошибки можно безопасно игнорировать (Django все равно установится нормально), но вы можете избежать их, обновив setuptools до более поздней версии. Если вы используете pip, вы можете обновить pip с помощью python -m pip install -U pip, который также обновит setuptools. Эта проблема решена в более поздних версиях Django, как описано в Примечания к выпуску Django 1.9.2.

Разнообразный¶

• Статические файлы jQuery в contrib.admin были перемещены в подкаталог vendor/jquery.

• Текст, отображаемый для пустых столбцов в ячейках списка изменений администратора list_display, изменился с (None) (или его переведенного эквивалента) на - (тире).

• django.http.responses.REASON_PHRASES и django.core.handlers.wsgi.STATUS_CODE_TEXT были удалены. Вместо этого используйте стандартную библиотеку Python: http.client.responses для Python 3 и httplib.responses для Python 2.

• ValuesQuerySet и ValuesListQuerySet были удалены.

• Шаблон admin/base.html больше не устанавливает window.__admin_media_prefix__ или window.__admin_utc_offset__. Ссылки на изображения в JavaScript, которые использовали это значение для создания абсолютных URL-адресов, были перенесены в CSS для упрощения настройки. Смещение UTC хранится в атрибуте данных тега <body>.

• Проверка CommaSeparatedIntegerField была усовершенствована и теперь запрещает такие значения, как ',', ',1' и '1,,2'.

• Инициализация формы была перенесена из метода ProcessFormView.get() в новый метод FormMixin.get_context_data(). Это может быть обратно несовместимо, если вы переопределили метод get_context_data() без вызова super().

• Поддержка PostGIS 1.5 прекращена.

• Поле django.contrib.sites.models.Site.domain было изменено на unique.

• Чтобы обеспечить изоляцию тестов, запросы к базе данных больше не разрешены по умолчанию в тестах SimpleTestCase. Вы можете отключить это поведение, установив для атрибута классаallow_database_queries значение True в вашем тестовом классе.

• ResolverMatch.app_name был изменен и теперь содержит полный путь к пространству имен в случае вложенных пространств имен. Для согласованности с ResolverMatch.namespace пустое значение теперь является пустой строкой вместо None.

• Для усиления безопасности сеансовые ключи должны содержать не менее 8 символов.

• Закрытая функция django.utils.functional.total_ordering() удалена. Он содержал обходной путь для ошибки functools.total_ordering() в версиях Python старше 2.7.3.

• Сериализация XML (либо через dumpdata, либо через структуру синдикации), используемая для вывода любых полученных символов. Теперь, если сериализуемый контент содержит какие-либо управляющие символы, не разрешенные стандартом XML 1.0, сериализация завершится с ошибкой ValueError.

• CharField теперь по умолчанию удаляет вводимые начальные и конечные пробелы. Это можно отключить, установив для нового аргумента strip значение False.

• Текст шаблона, переведенный и использующий два или более последовательных знака процента, например "%%", может иметь новый msgid после запуска makemessages (скорее всего, перевод будет помечен как нечеткий). Новый msgid будет помечен "#, python-format".

• Если ни request.current_app, ни Context.current_app не установлены, тег шаблона url теперь будет использовать пространство имен текущего запроса. Установите для request.current_app значение None, если вы не хотите использовать подсказку пространства имен.

• Параметр SILENCED_SYSTEM_CHECKS теперь отключает сообщения всех уровней. Раньше сообщения уровня «ERROR» или выше выводились на консоль.

• Поле FlatPage.enable_comments удалено из FlatPageAdmin, поскольку оно не используется приложением. Если ваш проект или стороннее приложение использует его, создайте собственный ModelAdmin, чтобы добавить его обратно.

• Возвращаемое значение setup_databases() и первый аргумент teardown_databases() изменились. Раньше это были кортежи (old_names, Mirrors). Теперь это только первый элемент, old_names.

• По умолчанию LiveServerTestCase пытается найти доступный порт в диапазоне 8081-8179 вместо того, чтобы просто пробовать порт 8081.

• Система проверяет ModelAdmin теперь проверяет экземпляры, а не классы.

• Частный API для применения смешанных планов миграции был удален из соображений производительности. Смешанные планы состоят из списка миграций, некоторые из которых применяются, а другие не применяются.

• Классы дескрипторов связанных объектов модели в django.db.models.fields.related (частный API) перемещены из модуля `` linked`` в `` linked_descriptors`` и переименованы следующим образом:

  • ReverseSingleRelatedObjectDescriptor — это ForwardManyToOneDescriptor

  • SingleRelatedObjectDescriptor — это ReverseOneToOneDescriptor

  • ForeignRelatedObjectsDescriptor — это ReverseManyToOneDescriptor

  • ManyRelatedObjectsDescriptor — это ManyToManyDescriptor

• Если вы реализуете собственное представление handler404, оно должно вернуть ответ с кодом состояния HTTP 404. Используйте HttpResponseNotFound или передайте status=404 в HttpResponse. В противном случае APPEND_SLASH не будет работать корректно с DEBUG=False.

assignment_tag()¶

В Django 1.4 добавлен помощник assignment_tag, упрощающий создание тегов шаблона, которые сохраняют результаты в переменной шаблона. Помощник simple_tag() получил ту же самую возможность, что сделало assignment_tag устаревшим. Теги, использующие assignment_tag, должны быть обновлены для использования simple_tag.

{% цикл %} синтаксис с аргументами, разделенными запятыми¶

Тег cycle поддерживает устаревший старый синтаксис из предыдущих версий Django:

{% cycle row1,row2,row3 %}

Его анализ вызвал ошибки в текущем синтаксисе, поэтому поддержка старого синтаксиса будет удалена в Django 1.10 после ускоренного прекращения поддержки.

Аргумент ForeignKey и OneToOneField on_delete¶

Чтобы повысить осведомленность о каскадном удалении модели, в Django 2.0 потребуется аргумент on_delete для ForeignKey и OneToOneField.

Обновите модели и существующие миграции, чтобы явно задать аргумент. Поскольку по умолчанию используется models.CASCADE, добавьте on_delete=models.CASCADE ко всем ForeignKey и OneToOneFields, которые не используют другую опцию. Вы также можете передать его в качестве второго позиционного аргумента, если вас не волнует совместимость со старыми версиями Django.

Изменения Field.rel¶

Field.rel, его методы и атрибуты были изменены в соответствии с API связанных полей. Атрибут «Field.rel» переименован в «remote_field», и многие его методы и атрибуты либо изменены, либо переименованы.

Целью этих изменений является предоставление документированного API для полей отношений.

Пользовательские методы GeoManager и GeoQuerySet¶

Все пользовательские методы GeoQuerySet (area(), distance(), gml(), …) были заменены эквивалентными географическими выражениями в аннотациях (см. новые функции). Следовательно, необходимость установки специального GeoManager для моделей с поддержкой ГИС теперь устарела. Как только ваш код не вызывает ни один из устаревших методов, вы можете просто удалить строки objects = GeoManager() из ваших моделей.

API-интерфейсы загрузчика шаблонов изменились.¶

Загрузчики шаблонов Django были обновлены, чтобы обеспечить возможность рекурсивного расширения шаблонов. Это изменение потребовало нового API-интерфейса загрузчика шаблонов. Старые методы load_template() и load_template_sources() теперь устарели. Подробности о новом API можно найти в документации по загрузчику шаблонов.

Передача кортежа из трех или app_name в include()¶

Часть пространства имен экземпляра при передаче кортежа в качестве аргумента для include() была заменена передачей аргумента namespace в include(). Например:

polls_patterns = [
    url(...),
]

urlpatterns = [
    url(r"^polls/", include((polls_patterns, "polls", "author-polls"))),
]

становится:

polls_patterns = (
    [
        url(...),
    ],
    "polls",
)  # 'polls' is the app_name

urlpatterns = [
    url(r"^polls/", include(polls_patterns, namespace="author-polls")),
]

Аргумент app_name для include() был заменен передачей двухкортежа (как указано выше) или передачей объекта или модуля с атрибутом app_name (как показано ниже). Если app_name установлено таким новым способом, аргумент namespace больше не требуется. По умолчанию будет установлено значение app_name. Например, шаблоны URL-адресов в руководстве изменены с:

urlpatterns = [url(r"^polls/", include("polls.urls", namespace="polls")), ...]

к:

urlpatterns = [
    url(r"^polls/", include("polls.urls")),  # 'namespace="polls"' removed
    ...,
]

app_name = "polls"  # added
urlpatterns = [...]

Это изменение также означает, что старый способ включения экземпляра AdminSite устарел. Вместо этого передайте admin.site.urls непосредственно в django.conf.urls.url():

from django.conf.urls import url
from django.contrib import admin

urlpatterns = [
    url(r"^admin/", admin.site.urls),
]

Пространство имен приложения URL требуется при настройке пространства имен экземпляра.¶

Раньше пространство имен экземпляра без пространства имен приложения служило той же цели, что и пространство имен приложения, но было невозможно изменить шаблоны на противоположные, если существовало пространство имен приложения с тем же именем. Включения, указывающие пространство имен экземпляра, требуют, чтобы включенный URLconf задавал пространство имен приложения.

Параметр current_app для представлений contrib.auth¶

Все представления в django.contrib.auth.views имеют следующую структуру:

def view(request, ..., current_app=None, ...):

    ...

    if current_app is not None:
        request.current_app = current_app

    return TemplateResponse(request, template_name, context)

Начиная с Django 1.8, current_app устанавливается в объекте request. Для согласованности эти представления потребуют, чтобы вызывающая сторона установила current_app в запросе вместо того, чтобы передавать его в отдельном аргументе.

django.contrib.gis.geoip¶

Модуль django.contrib.gis.geoip2 заменяет django.contrib.gis.geoip. Новый модуль предоставляет аналогичный API, за исключением того, что он не предоставляет устаревшие методы совместимости API GeoIP-Python.

Разнообразный¶

• Аргумент weak для django.dispatch.signals.Signal.disconnect() устарел, поскольку он не имеет никакого эффекта.

• Метод check_aggregate_support() в django.db.backends.base.BaseDatabaseOperations устарел и будет удален в Django 2.0. Вместо этого следует использовать более общий метод check_expression_support().

• django.forms.extras устарел. Вместо этого вы можете найти SelectDateWidget в django.forms.widgets (или просто django.forms).

• Частный API django.db.models.fields.add_lazy_relation() устарел.

• Декоратор django.contrib.auth.tests.utils.skipIfCustomUser() устарел. С изменениями в обнаружении тестов в Django 1.6 тесты для приложений django.contrib больше не запускаются как часть пользовательского проекта. Таким образом, декоратор @skipIfCustomUser больше не нужен для оформления тестов в django.contrib.auth.

• Если вы настроили некоторые обработчики ошибок, подписи представлений только с одним параметром запроса считаются устаревшими. Представления теперь также должны принимать второй позиционный параметр «исключение».

• Атрибуты django.utils.feedgenerator.Atom1Feed.mime_type и django.utils.feedgenerator.RssFeed.mime_type устарели в пользу content_type.

• Signer теперь выдает предупреждение, если используется недопустимый разделитель. Это станет исключением в Django 1.10.

• django.db.models.Field._get_val_from_obj() устарел в пользу Field.value_from_object().

• django.template.loaders.eggs.Loader устарел, поскольку распространение приложений, поскольку яйца не рекомендуется.

• Аргумент ключевого слова callable_obj для SimpleTestCase.assertRaisesMessage() устарел. Вместо этого передайте вызываемый объект в качестве позиционного аргумента.

• Атрибутallow_tags в методах ModelAdmin устарел. Вместо этого используйте format_html(), format_html_join() или mark_safe() при построении возвращаемого значения метода.

• Аргумент ключевого слова enclosure для SyndictionFeed.add_item() устарел. Используйте новый аргумент Enclosures, который принимает список объектов Enclosure вместо одного.

• Псевдонимы django.template.loader.LoaderOrigin и django.template.base.StringOrigin для django.template.base.Origin устарели.