3.1 примечания к выпуску¶
django CMS 3.1 был запланирован в основном как консолидирующий релиз, чтобы развить прогресс, достигнутый в 3.0, и создать безопасную, прочную базу для более амбициозной работы в будущем.
В этом выпуске мы постарались сохранить максимальную обратную совместимость, особенно для приложений сторонних разработчиков, и постарались выявить и устранить недостатки в системе, где это возможно.
Предупреждение
Обновление с предыдущих версий
В 3.1 внесены некоторые изменения, которые требуют действий, если вы переходите с предыдущей версии. Пожалуйста, прочитайте Обновление django CMS 3.0 до 3.1 для получения пошагового руководства по процессу обновления с 3.0 до 3.1.
Что нового в версии 3.1¶
Переход от MPTT к MP¶
Начиная с django CMS 2.0 мы полагаемся на MPTT (Modified Pre-order Tree Traversal) для эффективной работы с древовидными структурами в базе данных.
В версии 3.1 Django MPTT было заменено на django-treebeard для повышения производительности и надежности.
За годы работы MPTT оказался недостаточно быстрым для больших операций с деревом (>1000 страниц); повреждение дерева из-за транзакционных ошибок также было проблемой.
django-treebeard использует MP (Materialised Path). MP более эффективен и обладает большей устойчивостью к ошибкам, чем MPTT. Это должно улучшить работу и использование django CMS - быстрее и надежнее.
В остальном конечные пользователи не должны заметить никаких изменений.
Примечание
Требуется обратная связь с пользователями
Нам требуется как можно больше отзывов о работе django-treebeard в этом релизе. Пожалуйста, сообщите нам о своем опыте работы с ним, особенно если вы столкнулись с какими-либо проблемами.
Примечание
Обратное несовместимое изменение
Хотя большинство низкоуровневых интерфейсов очень похожи между django-mptt и django-treebeard, они не совсем одинаковы. Если пользовательский код должен использовать низкоуровневые интерфейсы страницы или дерева плагинов, пожалуйста, обратитесь к django-treebeard documentation за информацией о том, как использовать эквивалентные вызовы в django-treebeard.
Примечание
Обработка миграции данных плагина
Пожалуйста, обратитесь к Миграция данных плагина за информацией о том, как создавать миграции, совместимые с django CMS 3.0 и 3.1
Необходимые действия¶
Выполните manage.py cms fix-mptt перед обновлением.
Разработчикам, использующим django CMS, необходимо выполнить миграцию схем и данных, которая входит в этот релиз. Разработчикам сторонних приложений, которые полагались на Django MPTT, поставляемый с django CMS, рекомендуется обновить свои приложения так, чтобы они устанавливали его независимо.
Прекращена поддержка Django 1.4 и 1.5¶
Начиная с версии 3.1, django CMS работает на Django 1.6 (в частности, 1.6.9 и более поздние версии) и 1.7.
Предупреждение
Поддержка безопасности Django
Поддержка Django 1.6 предоставляется только в качестве временной меры. В соответствии с Django Project’s security policies, 1.6 больше не получает обновлений безопасности от команды проекта Django. Проекты, работающие на Django 1.6, имеют известные уязвимости, поэтому вам рекомендуется обновить вашу установку до 1.7 или 1.8 как можно скорее.
Необходимые действия¶
Если вы все еще используете более раннюю версию, вам необходимо установить более новую, а также убедиться, что ваши сторонние приложения также обновлены до нее, прежде чем пытаться обновить django CMS.
Юг теперь является необязательной зависимостью¶
Поскольку Django South теперь требуется только для Django 1.6, он помечен как необязательная зависимость.
Необходимые действия¶
Для установки South вместе с django CMS используйте pip install django-cms[south].
Изменения в PlaceholderAdmin.add_plugin¶
Исторически, когда плагин добавлялся в django CMS, POST запрос делался к конечной точке PlaceholderAdmin.add_plugin (а если вернуться к очень древней истории до появления PlaceholderAdmin, то к PageAdmin.add_plugin). Это создавало экземпляр CMSPlugin, но не экземпляр самой модели плагина. Затем агент пользователя может отредактировать созданный плагин, который при сохранении вернет базу данных в согласованное состояние, с экземпляром плагина, связанным с пустым и бессмысленным CMSPlugin.
В некоторых случаях создаются «плагины-призраки», если процесс создания экземпляра плагина не удался или был прерван, например, из-за закрытия окна браузера.
В результате в базе данных останутся бесхозные экземпляры CMSPlugin без каких-либо данных. Это может привести к тому, что страницы вообще не будут работать из-за возникающих несоответствий в базе данных.
Эта проблема теперь решена. Вызов CMSPluginBase.add_plugin с GET-запросом теперь служит формой для создания нового экземпляра плагина. После отправки этой формы через POST плагин создается полностью, обеспечивая согласованность базы данных и прекращение существования плагинов-призраков.
Однако для решения этой проблемы пришлось внести некоторые обратно несовместимые изменения в недокументированные API, которые могли использовать разработчики.
Крючки разрешения CMSPluginBase¶
До сих пор CMSPluginBase.has_delete_permission, CMSPluginBase.has_change_permission и CMSPluginBase.has_add_permission обрабатывались одним методом, который использовал недокументированное и ненадежное свойство экземпляров CMSPluginBase (или их подклассов) для управления разрешениями.
В версии 3.1 CMSPluginBase.has_add_permission является собственным методом, который реализует надлежащую проверку прав доступа для добавления плагинов.
Если вы хотите работать с этими API, смотрите Django documentation для получения дополнительной информации о методах разрешения.
CMSPluginBase.get_form¶
До версии 3.1 этот метод вызывался только при наличии реального экземпляра.
Начиная с версии 3.1, этот метод будет вызываться без экземпляра (аргумент obj будет None), если форма используется для добавления плагина, а не для его редактирования. Опять же, это соответствует тому, как работает ModelAdmin в Django.
Если вам нужен доступ к объекту Placeholder, к которому будет добавлен плагин, то объект request гарантированно имеет ключ placeholder_id в request.GET, который является первичным ключом объекта Placeholder, к которому будет добавлен плагин. Аналогично, plugin_language в request.GET хранит код языка добавляемого плагина.
CMSPlugin.add_view¶
Раньше этот метод никогда не вызывался, но начиная с версии 3.1 он будет вызываться. Если вам понадобится подключиться к этому методу, вы можете использовать метод CMSPluginBase.add_view_check_request для проверки того, что запрос, сделанный к этому представлению, является действительным. Этот метод будет выполнять проверку целостности и разрешения для GET-параметров запроса.
Миграции перенесены¶
Каталоги миграций были переименованы в соответствии с новой стандартной схемой:
Миграции Django 1.7: в каталогах по умолчанию
cms/migrationsиmenus/migrationsЮжные миграции: в каталогах
cms/south_migrationsиmenus/south_migrations
Необходимые действия¶
Для корректной работы с новым макетом требуется версия South 1.0.2 или новее, поэтому убедитесь, что она у вас установлена.
Если вы переходите с django CMS 3.0.x, работающей на Django 1.7, вам необходимо удалить старый путь миграции из настроек MIGRATION_MODULES.
Миграция плагинов процесс перемещения¶
Основные плагины изменяются, чтобы следовать новому соглашению для модулей миграции, начиная с djangocms_text_ckeditor 2.5, выпущенного вместе с django CMS 3.1.
Необходимые действия¶
Проверьте файл readme каждого плагина при обновлении, чтобы узнать о необходимых действиях.
Структура режима разрешений¶
Был добавлен новый Can use Structure mode* permission.
Без этого разрешения не-суперпользователь не будет иметь доступа к режиму структуры. Это делает возможным более строгий рабочий процесс, в котором определенные пользователи могут редактировать содержимое, но не структуру.
Это изменение включает миграцию данных, которая добавляет новое разрешение любому пользователю или группе сотрудников с разрешением cms.change_page.
Необходимые действия¶
Вам может понадобиться настроить эти разрешения после завершения переноса базы данных.
Обратите внимание, что если у вас есть существующие пользователи в вашей базе данных, но вы впервые устанавливаете django CMS и запускаете его миграции, вам нужно будет предоставить им эти права - они не получат их автоматически.
Расширение API панели инструментов¶
API панели инструментов был расширен, чтобы позволить более мощное ее использование в будущих разработках, включая использование элементов «типа буфера обмена».
Конфигурация apphook для каждого пространства имен¶
django CMS предоставляет новый API для определения конфигураций с разграничением имен Apphook.
Aldryn Apphooks Config был создан и выпущен в качестве стандартной реализации для использования этого преимущества, но могут быть разработаны и другие реализации.
Улучшения в пользовательском интерфейсе панели инструментов¶
Некоторые незначительные изменения были внесены для улучшения пользовательского интерфейса панели инструментов. Старый переключатель Draft/Live был заменен для более четкого разграничения состояний страницы, а кнопки Edit и Save as draft теперь доступны на панели инструментов для управления рабочим процессом редактирования страницы.
Значение по умолчанию True¶
language_fallback в CMS_PLACEHOLDER_CONF по умолчанию является True.
Новые теги шаблонов¶
render_model_add_block¶
Семейство тегов шаблонов render_model, позволяющих разработчикам Django сделать любую модель Django редактируемой во фронтенде, пополнилось тегами render_model_add_block, которые могут предлагать произвольную разметку в качестве иконки Редактировать (а не просто изображение, как раньше).
render_plugin_block¶
В некоторых пользовательских интерфейсах некоторые плагины скрыты от отображения в режиме редактирования/просмотра. render_plugin_block предоставляет способ открыть их для редактирования, а также в более общем случае предоставляет альтернативный способ запуска формы изменения плагина.
Обновление django CMS 3.0 до 3.1¶
Предварительные шаги¶
Перед обновлением, пожалуйста, убедитесь, что ваша текущая база данных согласована и находится в здоровом состоянии.
Чтобы убедиться в этом, выполните две команды:
python manage.py cms delete_orphaned_pluginspython manage.py cms fix-mptt
Сделайте копию базы данных перед дальнейшими действиями..
Обновление настроек¶
Измените
cms.context_processors.mediaнаcms.context_processors.cms_settingsвTEMPLATE_CONTEXT_PROCESSORS.Добавьте
treebeardкINSTALLED_APPS, и удалитеmptt, если это не требуется другими приложениями.Если вы используете Django 1.7, удалите
cmsиmenusизMIGRATION_MODULESдля поддержки новой схемы миграции.При миграции с Django 1.6 и ниже на Django 1.7 удалите
southизinstalled_apps.В конце концов, установите
language_fallbackвFalseвCMS_PLACEHOLDER_CONF, если вы не хотите, чтобы языковое поведение для заполнителей падало.
Обновление базы данных¶
Переименуйте имена таблиц плагинов, чтобы они соответствовали новой схеме именования (см. выше). Предупреждаем, что не все сторонние приложения плагинов могут предоставлять такие миграции - в этом случае вам придется переименовать таблицу вручную. После обновления django CMS будет искать таблицы для этих плагинов под их новым именем и сообщит, что они не существуют, если не сможет их найти.
Миграция для MPTT на
django-treebeardобрабатывается миграциями django CMS, поэтому примените миграции для обновления вашей базы данных:python manage.py migrate