• en
  • Language: ru
  • 3.7.x
  • Documentation version: 3.9

Конфигурация

django CMS имеет ряд настроек для конфигурирования своего поведения. Они должны быть доступны в вашем файле settings.py.

Настройка INSTALLED_APPS

Порядок элементов в INSTALLED_APPS имеет значение. Записи для приложений с плагинами должны идти после cms.

Настройка MIDDLEWARE

cms.middleware.utils.ApphookReloadMiddleware

Добавление ApphookReloadMiddleware к кортежу MIDDLEWARE позволит автоматически перезапускать сервер при изменении конфигурации apphook. Его следует разместить как можно ближе к вершине классов.

Примечание

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

Пользовательские требования

При использовании пользовательской модели пользователя (т.е. настройки Django AUTH_USER_MODEL) необходимо соблюдать несколько требований.

django CMS ожидает модель пользователя как минимум со следующими полями: email, password, is_active, is_staff и is_superuser. Кроме того, она должна наследоваться от AbstractBaseUser и PermissionsMixin (или AbstractUser), и должна определять одно поле как USERNAME_FIELD (см. документацию Django для более подробной информации) и определять метод get_full_name().

Модели также должны быть доступны для редактирования через админку Django и иметь зарегистрированный класс администратора.

Кроме того, приложение, в котором определена модель, **должно быть загружено до cms в INSTALLED_APPS.

Примечание

В большинстве случаев лучше создать модель UserProfile с отношением один к одному к auth.User, чем создавать пользовательскую модель пользователя. Пользовательские модели пользователей необходимы только в том случае, если вы собираетесь изменить поведение модели User по умолчанию, а не просто расширить ее.

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

Необходимые настройки

CMS_TEMPLATES

по умолчанию

() (Недействительная настройка!)

Список шаблонов, которые можно выбрать для страницы.

Пример:

CMS_TEMPLATES = (
    ('base.html', gettext('default')),
    ('2col.html', gettext('2 Column')),
    ('3col.html', gettext('3 Column')),
    ('extra.html', gettext('Some extra fancy template')),
)

Примечание

Все шаблоны, определенные в CMS_TEMPLATES должны содержать как минимум пространства имен js и css sekizai. Для примера смотрите Шаблоны.

Примечание

Также вы можете использовать CMS_TEMPLATES_DIR, чтобы определить каталог, содержащий шаблоны для django CMS.

Предупреждение

django CMS требует некоторых специальных шаблонов для правильного функционирования. Они предоставляются в каталоге cms/templates/cms. Вам настоятельно рекомендуется не использовать cms в качестве имени каталога для собственных шаблонов проекта.

Базовая настройка

CMS_TEMPLATE_INHERITANCE

по умолчанию

True

Включает наследование шаблонов от родительских страниц.

При включении опции Template страницы будут включать новое значение по умолчанию: Наследовать от родительской страницы (если только страница не является корневой).

CMS_TEMPLATES_DIR

по умолчанию

None

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

CMS_TEMPLATES_DIR может быть установлен на (абсолютный) путь к директории шаблонов, или установлен на словарь с элементами SITE_ID: template path:

CMS_TEMPLATES_DIR: {
    1: '/absolute/path/for/site/1/',
    2: '/absolute/path/for/site/2/',
}

Предоставленная директория сканируется и все шаблоны в ней загружаются как шаблоны для django CMS.

Загрузка шаблонов и их имена могут быть настроены с помощью каталога templates dir как модуля python, путем создания __init__.py файла в каталоге templates. Файл содержит один TEMPLATES словарь со списком шаблонов в качестве ключей и именами шаблонов в качестве значений::::

from django.utils.translation import gettext_lazy as _
TEMPLATES = {
    'col_two.html': _('Two columns'),
    'col_three.html': _('Three columns'),
}

Будучи обычным файлом python, метки шаблонов могут быть переданы через gettext для перевода.

Примечание

Поскольку шаблоны по-прежнему загружаются загрузчиком шаблонов Django, указанный каталог должен быть доступен системе загрузки шаблонов. В настоящее время протестированы и поддерживаются схемы загрузчика filesystem и app_directory.

CMS_PLACEHOLDER_CONF

по умолчанию

{}

Используется для настройки плагинов. Если не задано, все плагины будут доступны во всех разместителях.

Пример:

CMS_PLACEHOLDER_CONF = {
    None: {
        "plugins": ['TextPlugin'],
        'excluded_plugins': ['InheritPlugin'],
    },
    'content': {
        'plugins': ['TextPlugin', 'PicturePlugin'],
        'text_only_plugins': ['LinkPlugin'],
        'extra_context': {"width":640},
        'name': gettext("Content"),
        'language_fallback': True,
        'default_plugins': [
            {
                'plugin_type': 'TextPlugin',
                'values': {
                    'body':'<p>Lorem ipsum dolor sit amet...</p>',
                },
            },
        ],
        'child_classes': {
            'TextPlugin': ['PicturePlugin', 'LinkPlugin'],
        },
        'parent_classes': {
            'LinkPlugin': ['TextPlugin'],
        },
    },
    'right-column': {
        "plugins": ['TeaserPlugin', 'LinkPlugin'],
        "extra_context": {"width": 280},
        'name': gettext("Right Column"),
        'limits': {
            'global': 2,
            'TeaserPlugin': 1,
            'LinkPlugin': 1,
        },
        'plugin_modules': {
            'LinkPlugin': 'Extra',
        },
        'plugin_labels': {
            'LinkPlugin': 'Add a link',
        },
    },
    'base.html content': {
        "plugins": ['TextPlugin', 'PicturePlugin', 'TeaserPlugin'],
        'inherit': 'content',
    },
}

Вы можете комбинировать имена шаблонов и имена заполнителей, чтобы определить плагины более детально, как показано выше с base.html content.

Конфигурация извлекается в следующем порядке:

  • CMS_PLACEHOLDER_CONF[„template placeholder“]

  • CMS_PLACEHOLDER_CONF[„placeholder“]

  • CMS_PLACEHOLDER_CONF[„template“]

  • CMS_PLACEHOLDER_CONF[None]

Используется первый ключ CMS_PLACEHOLDER_CONF, который соответствует требуемому атрибуту конфигурации.

Например: в приведенном примере, если конфигурация plugins извлекается для content местодержателя на странице с использованием шаблона base.html, значение ['TextPlugin', 'PicturePlugin', 'TeaserPlugin'] будет возвращено в качестве 'base.html content' соответствия; если та же конфигурация извлекается для content местодержателя на странице с использованием шаблона fullwidth.html, возвращаемое значение будет ['TextPlugin', 'PicturePlugin']. Если конфигурация plugins найдена для sidebar_left местодержателя, то будет возвращено ['TextPlugin'] из CMS_PLACEHOLDER_CONF ключа None.

plugins

Список плагинов, которые могут быть добавлены к данному плагину. Если не задан, могут быть выбраны все плагины.

text_only_plugins

Список дополнительных плагинов, доступных только в TextPlugin, эти плагины не могут быть добавлены непосредственно в этот плейсхолдер.

excluded_plugins

Список плагинов, которые не будут добавлены в данный placeholder; этот список имеет приоритет над конфигурацией plugins: если плагин присутствует в обоих списках, он будет **не доступен в placeholder. По сути, это способ **черного списка плагина: даже если он зарегистрирован, он не будет доступен в данном местодержателе. Если установлен на ключ None (по умолчанию), плагины не будут доступны ни в одном placeholder (за исключением конфигурации excluded_plugins, которая переопределяется более конкретной конфигурацией CMS_PLACEHOLDER_KEYS.

extra_context

Дополнительный контекст, который получают плагины в этом placeholder.

name

Имя, отображаемое в админке Django. С помощью заглушки gettext имя может быть интернационализировано.

limits

Ограничивает количество плагинов, которые могут быть размещены внутри этого плейсхолдера. Ключи словаря - это имена плагинов, а значения - соответствующие им ограничения. Особый случай: global - ограничение абсолютного количества плагинов в этом заполнителе независимо от типа (имеет приоритет над ограничениями, относящимися к конкретному типу).

language_fallback

Если True, то если у заполнителя нет плагина для текущего языка, то он возвращается к запасным языкам, как указано в CMS_LANGUAGES. По умолчанию True, начиная с версии 3.1.

default_plugins

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

plugin_type

Тип плагина, который нужно добавить к заполнителю Пример : TextPlugin

values

Словарь для использования при создании плагина. Он зависит от параметра plugin_type. Смотрите документацию каждого типа плагина, чтобы узнать, какие параметры требуются и доступны. Пример для текстового плагина: {'body':'<p>Lorem ipsum</p>'} Пример для плагина ссылок: {'name':'Django-CMS','url':'https://www.django-cms.org'}

children

Это список словарей для настройки плагинов по умолчанию для добавления в качестве дочерних для текущего плагина (он должен принимать дочерние словари). Каждый словарь принимает те же args, что и словари default_plugins : plugin_type, values, children (да, это рекурсивно).

Полный пример использования default_plugins:

CMS_PLACEHOLDER_CONF = {
    'content': {
        'name' : _('Content'),
        'plugins': ['TextPlugin', 'LinkPlugin'],
        'default_plugins':[
            {
                'plugin_type':'TextPlugin',
                'values':{
                    'body':'<p>Great websites : %(_tag_child_1)s and %(_tag_child_2)s</p>'
                },
                'children':[
                    {
                        'plugin_type':'LinkPlugin',
                        'values':{
                            'name':'django',
                            'url':'https://www.djangoproject.com/'
                        },
                    },
                    {
                        'plugin_type':'LinkPlugin',
                        'values':{
                            'name':'django-cms',
                            'url':'https://www.django-cms.org'
                        },
                        # If using LinkPlugin from djangocms-link which
                        # accepts children, you could add some grandchildren :
                        # 'children' : [
                        #     ...
                        # ]
                    },
                ]
            },
        ]
    }
}
plugin_modules

Словарь имен плагинов и пользовательских модулей для группировки плагинов в пользовательском интерфейсе панели инструментов.

plugin_labels

Словарь плагинов и пользовательских меток для отображения в пользовательском интерфейсе панели инструментов.

child_classes

Словарь имен плагинов со списками, описывающими, какие плагины могут быть размещены внутри каждого плагина. Если не задан, могут быть выбраны все плагины.

parent_classes

Словарь имен плагинов со списками, описывающими, какие плагины может содержать каждый плагин. Если не задан, могут быть выбраны все плагины.

require_parent

Булево значение, указывающее, требует ли этот плагин другой плагин в качестве родительского или нет.

inherit

Имя заполнителя или имя шаблона + имя заполнителя, который наследуется. В примере, конфигурация для base.html content наследуется от content и просто перезаписывает настройку plugins, чтобы разрешить TeaserPlugin, таким образом, вам не нужно дублировать конфигурацию content.

CMS_PLUGIN_CONTEXT_PROCESSORS

по умолчанию

[]

Список контекстных процессоров плагинов. Контекстные процессоры плагинов - это вызываемые модули, которые изменяют контекст всех плагинов перед рендерингом. Для получения дополнительной информации смотрите Как создавать плагины.

CMS_PLUGIN_PROCESSORS

по умолчанию

[]

Список процессоров плагинов. Процессоры плагинов - это вызываемые переменные, которые изменяют вывод всех плагинов после рендеринга. Для получения дополнительной информации смотрите Как создавать плагины.

CMS_APPHOOKS

по умолчанию:

()

Список путей импорта для cms.app_base.CMSApp подклассов.

По умолчанию, apphooks автоматически обнаруживаются в приложениях, перечисленных во всех INSTALLED_APPS, при попытке импортировать их модуль cms_app.

Если установлено значение CMS_APPHOOKS, автоматическое обнаружение отключено.

Пример:

CMS_APPHOOKS = (
    'myapp.cms_app.MyApp',
    'otherapp.cms_app.MyFancyApp',
    'sampleapp.cms_app.SampleApp',
)

Интернационализация и локализация (I18N и L10N)

CMS_LANGUAGES

по умолчанию

Значение LANGUAGES преобразуется в данный формат

Определяет языки, доступные в django CMS.

Пример:

CMS_LANGUAGES = {
    1: [
        {
            'code': 'en',
            'name': gettext('English'),
            'fallbacks': ['de', 'fr'],
            'public': True,
            'hide_untranslated': True,
            'redirect_on_fallback': False,
        },
        {
            'code': 'de',
            'name': gettext('Deutsch'),
            'fallbacks': ['en', 'fr'],
            'public': True,
        },
        {
            'code': 'fr',
            'name': gettext('French'),
            'public': False,
        },
    ],
    2: [
        {
            'code': 'nl',
            'name': gettext('Dutch'),
            'public': True,
            'fallbacks': ['en'],
        },
    ],
    'default': {
        'fallbacks': ['en', 'de', 'fr'],
        'redirect_on_fallback': True,
        'public': True,
        'hide_untranslated': False,
    }
}

Примечание

Убедитесь, что вы определяете только те языки, которые также находятся в LANGUAGES.

Предупреждение

Убедитесь, что вы используете коды языков (en-us), а не имена локалей (en_US) здесь и в LANGUAGES. Используйте check command для проверки правильности синтаксиса.

CMS_LANGUAGES имеет различные опции, где вы можете определить, как ведут себя различные языки, с детальным контролем.

На первом уровне можно задать значения для каждого SITE_ID. В приведенном выше примере мы определяем два сайта. Первый сайт имеет 3 языка (английский, немецкий и французский), а второй - только голландский.

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

Каждый узел языка нуждается, по крайней мере, в свойствах code и name. code - это код ISO 2 для языка, а name - это устное название языка.

Примечание

С помощью лямбда-функции gettext() вы можете сделать названия языков переводимыми. Чтобы включить эту функцию, добавьте gettext = lambda s: s в начало файла настроек.

Какими свойствами может обладать языковой узел?

код

Строка. RFC5646 код языка.

пример

"en".

Примечание

Требуется для каждого языка.

имя

Строка. Устное название языка.

Примечание

Требуется для каждого языка.

публичный

Определяет, доступен ли этот язык во фронтенде. Например, вы можете захотеть сохранить язык в тайне до тех пор, пока ваш контент не будет полностью переведен.

тип

Булево

по умолчанию

True

запасные варианты

Список альтернативных языков, в порядке предпочтения, которые будут использоваться, если страница еще не переведена…

пример

['de', 'fr']

по умолчанию

[]

скрыть_непереведённое

Скрывает непереведенные страницы в меню.

При применении к директиве default, если False, все страницы в меню будут перечислены на всех языках, включая те, которые еще не имеют содержимого на данном языке. Если True, то непереведенные страницы будут скрыты.

При применении к определенному языку скрывает страницы этого языка в меню до тех пор, пока для них не появятся переводы.

тип

Булево

по умолчанию

True

redirect_on_fallback

Определяет поведение, когда предпочтительный язык недоступен. Если True, произойдет перенаправление на URL той же страницы на запасном языке. Если False, то содержимое будет отображаться на запасном языке, но перенаправления не будет.

Обратите внимание, что это относится к поведению страниц. Начиная с версии 3.1 заместители будут работать по умолчанию. Если вы не хотите, чтобы заполнитель следовал поведению страницы, вы должны установить его language_fallback на False в CMS_PLACEHOLDER_CONF, выше.

тип

Булево

по умолчанию

True

Поддержка Unicode для автоматических слизней

Если на вашем сайте есть языки, использующие наборы символов, отличные от ASCII, CMS_UNIHANDECODE_HOST и CMS_UNIHANDECODE_VERSION позволят автоматизировать генерацию slug и для этих языков.

Поддержка этого обеспечивается проектом unihandecode.js.

CMS_UNIHANDECODE_HOST

по умолчанию

None

Должен быть установлен на URL, где вы размещаете свои файлы unihandecode.js. По лицензионным причинам django CMS не включает unihandecode.js.

Если установлено значение None, по умолчанию, unihandecode.js не используется.

Примечание

Unihandecode.js - довольно большая библиотека, особенно при загрузке поддержки японского языка. Поэтому очень важно, чтобы вы обслуживали ее с сервера, поддерживающего сжатие gzip. Кроме того, убедитесь, что эти файлы могут кэшироваться браузером в течение очень долгого времени.

CMS_UNIHANDECODE_VERSION

по умолчанию

None

Должен быть установлен на номер версии (например, '1.0.0'), которую вы хотите использовать. Вместе с CMS_UNIHANDECODE_HOST этот параметр используется для построения полных URL для файлов javascript. URL строятся следующим образом: <CMS_UNIHANDECODE_HOST>-<CMS_UNIHANDECODE_VERSION>.<DECODER>.min.js.

CMS_UNIHANDECODE_DECODERS

по умолчанию

['ja', 'zh', 'vn', 'kr', 'diacritic']

Если вы добавите дополнительные декодеры к вашему CMS_UNIHANDECODE_HOST, вы можете добавить их к этой настройке.

CMS_UNIHANDECODE_DEFAULT_DECODER

по умолчанию

'diacritic'

Декодер по умолчанию, который будет использоваться, если поддержка unihandecode.js включена, но текущий язык не предоставляет конкретного декодера в CMS_UNIHANDECODE_DECODERS. Если установить значение None, то при невозможности найти конкретный декодер unihandecode.js для этого языка будет отключен.

Пример

Добавьте эти параметры в настройки вашего проекта:

CMS_UNIHANDECODE_HOST = '/static/unihandecode/'
CMS_UNIHANDECODE_VERSION = '1.0.0'
CMS_UNIHANDECODE_DECODERS = ['ja', 'zh', 'vn', 'kr', 'diacritic']

Добавьте файлы библиотек из GitHub ojii/unihandecode.js tree/dist в папку static:

project/
    static/
        unihandecode/
            unihandecode-1.0.0.core.min.js
            unihandecode-1.0.0.diacritic.min.js
            unihandecode-1.0.0.ja.min.js
            unihandecode-1.0.0.kr.min.js
            unihandecode-1.0.0.vn.min.js
            unihandecode-1.0.0.zh.min.js

Дополнительная документация доступна на сайте unihandecode.js“ Read the Docs.

Настройки мультимедиа

CMS_MEDIA_PATH

по умолчанию

cms/

Путь от MEDIA_ROOT к медиафайлам, расположенным в cms/media/

CMS_MEDIA_ROOT

по умолчанию

MEDIA_ROOT + CMS_MEDIA_PATH

Путь к корню медиафайлов cms.

CMS_MEDIA_URL

по умолчанию

MEDIA_URL + CMS_MEDIA_PATH

Расположение медиафайлов, которые находятся в cms/media/cms/.

CMS_PAGE_MEDIA_PATH

по умолчанию

'cms_page_media/'

По умолчанию django CMS создает папку под названием cms_page_media в вашей папке static files, где хранятся все загруженные медиафайлы. Медиафайлы хранятся во вложенных папках, пронумерованных id страницы.

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

Расширенные настройки

CMS_INTERNAL_IPS

по умолчанию

[]

По умолчанию CMS_INTERNAL_IPS является пустым списком ([]).

Если оставить пустой список, этот параметр не добавляет никаких ограничений для панели инструментов. Однако, если он установлен, панель инструментов будет отображаться только для IP-адресов клиентов, которые находятся в этом списке.

Этот параметр также может быть установлен в IpRangeList из внешнего пакета iptools. Этот пакет позволяет использовать удобный синтаксис для определения сложных диапазонов IP-адресов.

IP-адрес клиента получается через CMS_REQUEST_IP_RESOLVER в промежуточной программе cms.middleware.toolbar.ToolbarMiddleware.

CMS_REQUEST_IP_RESOLVER

по умолчанию

cms.utils.request_ip_resolvers.default_request_ip_resolver

Этот параметр используется во всей системе, чтобы обеспечить последовательное и легко подключаемое средство извлечения IP-адреса клиента из HTTP-запроса. Реализация по умолчанию должна работать для большинства архитектур проектов, но если это не так, администратор может предоставить свой собственный метод для обработки конкретных обстоятельств проекта.

Данный метод должен принимать единственный аргумент request и возвращать строку IP-адресов.

CMS_PERMISSION

по умолчанию

False

При включении этой функции в Admin предоставляются 3 новые модели:

  • Глобальные разрешения страниц

  • Группы пользователей - стр.

  • Пользователи - стр.

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

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

CMS_RAW_ID_USERS

по умолчанию

False

Эта настройка применяется только в том случае, если CMS_PERMISSION равно True.

Строки view restrictions и page permissions на форме изменения администратора cms.models.Page могут вызывать проблемы с производительностью, когда многие тысячи пользователей помещаются в простые поля выбора. Если этот параметр установлен в целое положительное число, он заставляет инлайны на этой странице использовать стандартные виджеты Django admin raw ID, а не поля выбора, если число пользователей в системе больше этого числа, что значительно повышает производительность.

Примечание

Использование необработанных полей ID в сочетании с limit_choices_to приводит к ошибкам из-за слишком длинных URL, если у вас много тысяч пользователей (все PK включаются в URL всплывающего окна). По этой причине мы применяем это ограничение только в том случае, если количество пользователей относительно невелико (менее 500). Если количество пользователей, которых нам нужно ограничить, больше, мы используем обычное поле ввода, если только пользователь не является суперпользователем CMS, в этом случае мы обходим ограничение. К сожалению, это означает, что не-суперпользователи не увидят никакой пользы от этой настройки.

Изменено в версии 3.2.1:: CMS_RAW_ID_USERS также применяется к GlobalPagePermission admin.

CMS_PUBLIC_FOR

по умолчанию

all

Определяет, являются ли страницы без ограничений на просмотр публичными по умолчанию или только для сотрудников. Возможные значения: all и staff.

CMS_CACHE_DURATIONS

Этот словарь содержит различные настройки длительности кэша.

'content'

по умолчанию

60

Срок действия кэша (в секундах) для тегов шаблонов show_placeholder, page_url, placeholder и static_placeholder.

Примечание

Эта настройка ранее называлась CMS_CONTENT_CACHE_DURATION.

'permissions'

по умолчанию

3600

Срок действия кэша (в секундах) для просмотра и других разрешений.

CMS_CACHE_PREFIX

по умолчанию

cms-

CMS будет добавлять значение, связанное с этим ключом, к каждому обращению к кэшу (set и get). Это полезно, когда у вас есть несколько инсталляций django CMS, и вы не хотите, чтобы они совместно использовали объекты кэша.

Пример:

CMS_CACHE_PREFIX = 'mysite-live'

Примечание

В Django 1.3 введен префикс ключа кэша для всего сайта. Смотрите собственную документацию Django по cache key prefixing.

CMS_PAGE_CACHE

по умолчанию

True

Следует ли кэшировать вывод страниц? Учитывает язык и часовой пояс. Страницы для пользователей, вошедших в систему, не кэшируются. Если панель инструментов видна, страница также не кэшируется.

CMS_PLACEHOLDER_CACHE

по умолчанию

True

Следует ли кэшировать вывод различных тегов шаблона placeholder? Учитывает текущий язык и часовой пояс. Если панель инструментов находится в режиме редактирования или присутствует плагин с cache=False, то шаблоны не будут кэшироваться.

CMS_PLUGIN_CACHE

по умолчанию

True

Значение по умолчанию атрибута cache плагинов. Должны ли плагины кэшироваться по умолчанию, если они не заданы явно?

Предупреждение

Если вы отключили кэш плагина, обязательно перезапустите сервер и очистите кэш после этого.

CMS_TOOLBARS

по умолчанию

None

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

Пример:

CMS_TOOLBARS = [
    # CMS Toolbars
    'cms.cms_toolbars.PlaceholderToolbar',
    'cms.cms_toolbars.BasicToolbar',
    'cms.cms_toolbars.PageToolbar',

    # third-party Toolbar
    'aldryn_blog.cms_toolbars.BlogToolbar',
]

CMS_TOOLBAR_ANONYMOUS_ON

по умолчанию

True

Этот параметр определяет, могут ли анонимные пользователи видеть панель инструментов CMS с формой входа, когда к URL добавляется ?edit. Поведение по умолчанию - показывать панель инструментов анонимным пользователям.

CMS_TOOLBAR_HIDE

по умолчанию

False

По умолчанию панель инструментов django CMS отображается для вошедших в систему пользователей-администраторов на всех страницах, использующих тег шаблона {% cms_toolbar %}. Ее отображение может быть опционально ограничено только страницами django CMS (технически, страницами, которые отображаются представлением django CMS).

Когда это значение установлено в True, все остальные страницы больше не будут отображать панель инструментов. Это касается и страниц с примененными к ним apphooks, так как они обрабатываются представлениями другого приложения, а не django CMS.

Изменено в версии 3.2.1:: CMS_APP_NAME было удалено, поскольку оно больше не требуется.

CMS_DEFAULT_X_FRAME_OPTIONS

по умолчанию

constants.X_FRAME_OPTIONS_INHERIT

Этот параметр является значением по умолчанию для параметра X Frame Options страницы. Это должно быть целое число, предпочтительно взятое из cms.constants, например.

  • X_FRAME_OPTIONS_INHERIT

  • X_FRAME_OPTIONS_ALLOW

  • X_FRAME_OPTIONS_SAMEORIGIN

  • X_FRAME_OPTIONS_DENY

CMS_TOOLBAR_SIMPLE_STRUCTURE_MODE

по умолчанию:

True

Новая структурная плата по умолчанию работает в «простом» режиме. Старый режим использовал абсолютное позиционирование. Установка этого атрибута в значение False позволит использовать абсолютное позиционирование, которое использовалось в версиях до 3.2. Эта настройка будет удалена в версии 3.3.

Пример:

CMS_TOOLBAR_SIMPLE_STRUCTURE_MODE = False

CMS_PAGE_WIZARD_DEFAULT_TEMPLATE

по умолчанию

TEMPLATE_INHERITANCE_MAGIC

Это путь к шаблону, используемому для создания страниц в мастере. Это должен быть один из шаблонов в CMS_TEMPLATES.

CMS_PAGE_WIZARD_CONTENT_PLACEHOLDER

по умолчанию

Нет

Если установлено значение редактируемого нестатического заполнителя, доступного в шаблоне страницы, мастера страниц CMS будут ориентироваться на указанный заполнитель при добавлении любого содержимого, введенного в поле «Содержание» мастера. Если этот параметр не установлен, то содержимое будет нацелено на первое подходящее место-держатель, найденное в шаблоне страницы.

CMS_PAGE_WIZARD_CONTENT_PLUGIN

по умолчанию

TextPlugin

Это имя плагина, создаваемого в мастере страниц при заполнении поля «Содержание». Нет необходимости изменять его, если только вы **не используете djangocms-text-ckeditor в своем проекте.

CMS_PAGE_WIZARD_CONTENT_PLUGIN_BODY

по умолчанию

body

Это имя поля body в плагине, создаваемом в мастере страниц при заполнении поля «Content». Нет необходимости изменять его, если только вы не используете ``djangocms-text-ckeditor`` в своем проекте **и ваш пользовательский плагин, определенный в CMS_PAGE_WIZARD_CONTENT_PLUGIN, имеет поле тела отличное от body.