Системные настройки

Последнее обновление Nov 28th, 2019 | История страницы | Улучшить эту страницу | Сообщить о проблеме

Support the team building MODX with a monthly donation.

The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.

Backers

Budget

$301 per month—let's make that $500!

Learn more

MODX поставляется с гибким набором системных настроек. Они находятся в Система -> Системные настройки и могут быть легко отредактированы и изменены. Все системные настройки доступны в ваших шаблонах с помощью обозначения [[++placeholder]]. Посмотрите Теги шаблона для дополнительной информации.

Переопределение настроек (Наследование)¶

В то время как в этом документе в основном говорится о Системных настройках, MODX поставляется с очень мощной системой наследования, которая позволяет переопределять настройки в контексте, пользовательской группе или пользовательской настройке.

По сути, когда параметр запрашивается в сеансе определенного пользователя, параметры проверяются в следующем порядке:

Настройка пользователя
Настройка группы пользователей
Настройка контекста (обратите внимание, что в менеджере контекст обычно называется mgr)
Настройка системы

Создание новых системных настроек (через графический интерфейс)¶

Чтобы создать новый параметр системы, нажмите ссылку «Создать новые параметры» в разделе «Система» -> «Параметры системы».

Параметры¶

Ключ: в конечном итоге это уникальное имя вашего [[++placeholder]]
Имя: эта метка отображается в столбце «Имя» при просмотре всех настроек системы. Это значение может быть локализовано (см. Ниже).
Тип поля: в настоящее время поддерживаются 3 типа ввода: TextField, TextArea, Yes/No
Пространство имен: как с Пользовательские страницы менеджера, пространство имен определяет папку внутри core/components/.
Area Lexicon Entry: это значение влияет на группировку системных настроек; создайте несколько системных настроек, которые совместно используют «Область ввода лексики», и они будут сгруппированы вместе.
Значение: значение по умолчанию.
Описание: это значение может быть локализовано (см. Ниже).

Локализация¶

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

Имя: setting_ + Key
Описание: setting_ + Key + _desc

Например, если мы посмотрим на Quip's [[++quip.emailsFrom]] настройки, мы видим, что он использует пространство имен quip. Ожидаемая структура папок состоит в том, чтобы искать файлы локализации в папке пространства имен, затем в папке «лексикона», затем в папках, разделенных по языковым кодам, и затем в default.inc.php файле, для примера core/components/quip/lexicon/en/default.inc.php

В нашем примере Quip мы видим имя setting_quip.emailsFrom и описание setting_quip.emailsFrom_desc. Эти два значения соответствуют ключам в $_lang массив внутри default.inc.php:

$_lang['setting_quip.emailsFrom'] = 'From Email';
$_lang['setting_quip.emailsFrom_desc'] = 'The email address to send system emails from.';

Мы рекомендуем вам щелкнуть правой кнопкой мыши существующий системный параметр и выбрать «Обновить системный параметр», чтобы получить представление о том, как это работает.

Получение настроек системы (программно)¶

Чтобы получить значение настройки из сниппета, плагина или другого PHP-кода, вы используете getOption функции и передачи ей уникальный ключ для опции, например:

$siteStartId = $modx->getOption('site_start');

В WordPress сопоставимая функция API get_option().

Эта функция извлекает значение из кэша настроек.

Сохранение настроек системы (программно)¶

Здесь все становится немного сложнее: когда мы получаем значение, используя getOption, мы получаем объект из кэша настроек. Это имеет явное преимущество в скорости, но это означает, что у нас по существу есть копия значения настройки, доступная только для чтения.

Пока есть метод setOption; это только обновляет кэш настроек в памяти.

Это по архитектурным причинам: системные настройки должны быть определены как configurations, NOT runtime dynamic values. Они обычно устанавливаются во время установки, а затем не часто обновляются. Однако могут быть законные времена, когда вам нужно обновить системные настройки программно, например, возможно, вы написали Пользовательская страница менеджера которая предлагает настраиваемую форму для ваших пользователей для своих системных настроек.

Если мы хотим обновить настройки системы, мы используем мощный xPDO getObject функция. Итак, давайте вернемся к нашему поиску простой настройки сайта и сравним ее рядом с более подробным (и более гибким) аналогом xPDO:

echo $modx->getOption('site_name');
// prints the same thing as this:
$setting = $modx->getObject('modSystemSetting', 'site_name');
if ($setting) {
    echo $setting->get('value');
}

Разница в том, что использование getObject извлекает объект из базы данных без кэширования, и мы можем делать с объектом гораздо больше вещей, включая сохранение этого объекта. Итак, вот как мы должны получить и сохранить настройки системы:

$setting = $modx->getObject('modSystemSetting', 'site_name');
$setting->set('value', 'My New Site Name');
$setting->save();

Однако обратите внимание, что это не очищает кэш настроек, поэтому любые последующие вызовы getOption по-прежнему будут возвращать более старую кешированную версию настройки.

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

$cacheRefreshOptions =  [
    'system_settings' => [],
    'resource' => [],
];
$modx->cacheManager->refresh($cacheRefreshOptions);

В WordPress сопоставимая функция API update_option().

Получение метаданных настроек¶

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

$Setting = $modx->getObject('modSystemSetting', 'site_name');
print_r( $Setting->toArray() );
/*
prints out something like this:
Array (
    [key] => site_name
    [value] => My Skiphop Site
    [xtype] => textfield
    [namespace] => core
    [area] => site
    [editedon] => 2010-10-24 21:53:55
)
*/

Как только вы поймете, как манипулировать объектами с помощью MODX и xPDO, вы сможете извлекать и изменять практически все внутри MODX, потому что практически все является объектом.

Получение списка связанных настроек¶

Если вы заметили в графическом интерфейсе выше, MODX позволяет несколько логично сгруппировать настройки системы. Самые полезные группировки - это area и префикс key. Использование xPDO getCollection Метод, мы можем легко предоставить некоторые критерии поиска, чтобы получить настройки, которые мы хотим.

Вот как мы можем получить все настройки из области «Почта»:

$relatedSettings = $modx->getCollection('modSystemSetting', array('area'=>'Mail'));
foreach ( $relatedSettings as $Setting ) {
        print $Setting->get('value');
}

Это естественным образом приводит нас к одной из других особенностей xPDO: xPDOQuery объект. Мы можем использовать его для передачи более сложных критериев нашему вызову getCollection. Вот как мы можем получить все настройки, которые используют префикс «quip»:

$query = $modx->newQuery('modSystemSetting');
$query->where(array('key:LIKE' => 'quip.%') );
$relatedSettings = $modx->getCollection('modSystemSetting', $query);
foreach ( $relatedSettings as $Setting ) {
    print $Setting->get('value');
}

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

Создание системной настройки программно¶

Возможно, вы захотите создать Системные настройки программно, чтобы предоставить вашим пользователям более чистый UX / UI. В своем коде вы можете поместить что-то вроде следующего:

$MySetting = $modx->newObject('modSystemSetting');
$MySetting->set('key', 'mykey');
$MySetting->set('value', 'my_value');
$MySetting->set('xtype', 'textfield');
$MySetting->set('namespace', 'my_namespace');
$MySetting->set('area', 'MyArea');
$MySetting->save();
// Clear the cache:
$cacheRefreshOptions =  array( 'system_settings' => array() );
$modx->cacheManager->refresh($cacheRefreshOptions);

Обратите внимание, что вы должны создать записи лексики, которые соответствуют вашему имени ключа (см. Раздел «Локализация» выше):

Имя: setting_ + Key
Описание: setting_ + Key + _desc

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

$_lang['setting_mykey'] = 'Имя моей настройки';
$_lang['setting_mykey_desc'] = 'Описание моего ключа';

MODX заполняет значения для имени и описания на основе этих записей лексики.

Может оказаться полезным ссылаться на ваши локализованные языковые строки внутри ваших шаблонов или CMP. Это можно сделать с помощью тега лексикона, но вы должны указать тему «setting», например,

[[!%setting_emailsender? &topic=`setting` &namespace=`core` &language=`en`]]

Типы системных настроек¶

Атрибут xtype определяет, какой тип поля GUI будет использовать при рендеринге интерфейса для этого поля:

combo-boolean : сохраненные значения 1 и 0. Будет отображать «Да» и «Нет»
textfield : стандартное текстовое поле
textarea : стандартная текстовая область
text-password : стандартное поле пароля (ввод маскируется)
numberfield : используется для ввода цифр
modx-combo-language : позволяет пользователю выбрать язык
modx-combo-source :
modx-combo-template : позволяет пользователю выбрать шаблон
modx-combo-content-type : позволяет пользователю выбрать тип контента
modx-combo-charset : позволяет пользователю выбрать набор символов
modx-combo-rte : как текстовая область, но с элементами управления форматированием
modx-combo-context : позволяет пользователю выбрать контекст
modx-combo-manager-theme : позволяет пользователю выбрать тему оформления интерфейса менеджера MODX

Список настроек¶

Описание каждого параметра следующее: