3.3 примечания к выпуску¶
django CMS 3.3 был запланирован в основном как консолидирующий релиз, чтобы развить прогресс, достигнутый в 3.2, и подготовить почву для будущих релизов.
Самым крупным изменением является отказ от поддержки Django 1.6 и 1.7, а также Python 2.6, после чего была проведена серьезная чистка кода для устранения фишек совместимости.
Что нового в версии 3.3¶
Удалена поддержка Django 1.6, 1.7 и python 2.6
Изменено значение по умолчанию CMSPlugin.position на 0 вместо null
Переработано языковое меню для лучшей интеграции со многими языками
Полностью переработаны команды управления для лучшей согласованности
Исправлена ошибка «failed to load resource» для фавикона на экране приветствия
Изменено поведение CSS-классов панели инструментов: Класс
cms-toolbar-expanded
теперь добавляется только при полном раскрытии панели инструментов, а не в начале анимации. Классыcms-toolbar-expanding
иcms-toolbar-collapsing
добавляются в начале соответствующих анимаций.Добавлены модульные тесты для JavaScript-файлов CMS
Добавлены интеграционные тесты фронтенда (написанные с помощью Casper JS)
Удалены интеграционные тесты фронтенда (написанные с помощью Selenium)
Добавлена возможность объявлять периоды истечения срока действия кэша на основе каждого плагина
Улучшенный пользовательский интерфейс дерева страниц
Улучшение пользовательского интерфейса в различных незначительных аспектах
Добавлена новая настройка CMS_INTERNAL_IPS для определения набора IP-адресов, для которых панель инструментов будет отображаться для авторизованных пользователей. Если этот параметр не задан, то сохраняется существующее поведение, при котором панель инструментов разрешена для авторизованных пользователей на любом IP-адресе.
Изменено поведение бокового фрейма; он больше не изменяет размер, открывается на 90% экрана или 100% на маленьких экранах.
Удалены некоторые ненужные перезагрузки после закрытия боковой рамки.
Добавлена возможность заставить действия постраничного дерева работать на выбранном в данный момент языке
Удалена устаревшая настройка CMS_TOOLBAR_SIMPLE_STRUCTURE_MODE
Введен метод
get_cache_expiration
на CMSPluginBase для использования плагинами для объявления срока действия их отрисованного содержимого.Введен метод
get_vary_cache_on
на CMSPluginBase для использования плагинами для объявления заголовковVARY
.Улучшена производительность перемещения плагинов; больше не сохраняет все плагины внутри заполнителя.
Исправлены хлебные крошки недавно перемещенного плагина, отражающие предыдущую позицию в дереве
Переработана логика добавления плагина, чтобы больше не создавать плагин до того, как пользователь отправит форму.
Улучшено поведение кэша заполнителей
Улучшена команда fix-tree для сортировки по позиции и пути при перестройке позиций.
Исправлено несколько регрессий и повреждений деревьев при перемещении страниц.
Добавлен новый метод класса на CMSPlugin
requires_parent_plugin
Исправлено поведение
get_child_classes
; теперь корректно вычисляет дочерние классы, если они не настроены в заполнителе.Удален внутренний тег
ExtraMenuItems
.Удален внутренний тег
PluginChildClasses
.Изменен тег RenderPlugin; больше не рендерит шаблон
content.html
, а просто возвращает результаты.В основной класс
get_cached_template
добавлен методToolbar()
для повторного использования загруженных шаблонов по каждому запросу. Это работает как кэшированный загрузчик шаблонов Django, но на основе запроса.Добавлен новый метод
get_urls()
в классе appbase для получения CMSApp.urls, чтобы можно было передать ему объект страницы.Изменена линтинг JavaScript с JSHint и JSCS на ESLint
Исправлена ошибка, когда плагин можно было перетащить в буфер обмена
Исправлена ошибка, при которой очистка буфера обмена закрывала все открытые модалы
Добавлен параметр CMS_WIZARD_CONTENT_PLACEHOLDER
Переименовали настройки CMS_WIZARD_* в CMS_PAGE_WIZARD_*
Устранены старые настройки, связанные с мастерами.
Дальнейшее совершенствование документации
Улучшена обработка удаленных apphooks
Исправлено размещение панели инструментов при установке фундамента
Исправлена проблема, которая могла привести к появлению apphook без slug
Исправлены многочисленные проблемы с фронтендом
Добавлена документация по политике взносов
Исправлена проблема, при которой кто-то мог видеть и использовать внутренний плагин-заполнитель в структурной доске.
Исправлена ошибка, при которой первая созданная страница не публиковалась автоматически
Исправлены инструкции по использованию команды
delete-orphaned-plugins
Переопубликован django-treebeard до версии >=4.0.1
Обновление до версии 3.3¶
Требуется миграция базы данных, поскольку значение по умолчанию CMSPlugin.position было установлено в 0 вместо null.
Пожалуйста, убедитесь, что ваша текущая база данных согласована и находится в здоровом состоянии, и создайте копию базы данных, прежде чем продолжить работу..
Затем запустите:
python manage.py migrate
python manage.py cms fix-tree
Утрата настроек мастера страниц старого образца¶
В этом выпуске мы вводим новую схему наименования для настроек мастера страниц, которая лучше отражает, что они влияют на мастера страниц CMS, а не на все мастера. Это также позволит в будущем использовать настройки для разных мастеров с меньшей вероятностью путаницы или столкновения названий.
В этом выпуске одновременно отменяется старая схема именования этих настроек. Поддержка старой схемы именования будет прекращена в версии 3.5.0.
Необходимые действия¶
Разработчики, использующие в своих проектах любые из следующих настроек, должны при первой же возможности переименовать их следующим образом.:
CMS_WIZARD_DEFAULT_TEMPLATE => CMS_PAGE_WIZARD_DEFAULT_TEMPLATE
CMS_WIZARD_CONTENT_PLUGIN => CMS_PAGE_WIZARD_CONTENT_PLUGIN
CMS_WIZARD_CONTENT_PLUGIN_BODY => CMS_PAGE_WIZARD_CONTENT_PLUGIN_BODY
CMS_WIZARD_CONTENT_PLACEHOLDER => CMS_PAGE_WIZARD_CONTENT_PLACEHOLDER
CMS будет принимать обе схемы до версии 3.5.0, когда поддержка старой схемы будет прекращена. В течение этого переходного периода CMS предпочитает новый стиль именования, если в настройках проекта используются обе схемы.
Обратные несовместимые изменения¶
Команды управления¶
Команды управления теперь используют argparse, а не optparse, после того, как в Django был изъят API последнего.
Поведение команд осталось неизменным.
Детальные изменения:
команды теперь используют API подкоманды argparse, что приводит к немного другому выводу справки и другим внутренним различиям. Если вы используете команды с помощью функции Django
call_command
, вам придется адаптировать вызов команды, чтобы отразить это.некоторые команды были переименованы с заменой подчеркивания на дефис для единообразия
все аргументы теперь непозиционные. Если вы используете команды с помощью функции Django
call_command
, вам придется адаптировать вызов команды, чтобы отразить это.
Изменения в подписи¶
В сигнатурах методов панели инструментов get_or_create_menu
появился новый kwarg disabled
вставленный (не добавленный). Это было сделано для поддержания согласованности с другими, существующими методами панели инструментов. Теперь сигнатуры выглядят следующим образом:
cms.toolbar.items.Menu.get_or_create_menu(key, verbose_name, disabled=False, side=LEFT, position=None)
cms.toolbar.toolbar.CMSToolbar.get_or_create_menu(key, verbose_name=None, disabled=False, side=LEFT, position=None)
Это должно повлиять только на разработчиков, которые используют kwargs в качестве позиционных аргументов.