Конфигурация¶
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¶
- по умолчанию
Путь к корню медиафайлов cms.
CMS_MEDIA_URL¶
- по умолчанию
Расположение медиафайлов, которые находятся в 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
.