Управление настройками сайта

Продолжаем ковырять ядро MODX. И сегодня мы поговорим о настройках сайта. Я почти уверен, что немногие из вас смогут ответить на вопрос — сколько уровней настроек существует в MODX и какая у них иерархия. Данные знания помогут вам эффективнее управлять настройками сайта и не тратить время на велосипедостроение.

Наверняка вы знаете или хотя бы один раз видели в коде, что настройки сайта можно получить специальным методом getOption(). Давайте разберёмся откуда он их получает.

Информация!

Вообще этот метод используется не только для получения настроек. Он предназначен для работы с ассоциативными массивами. Ключ передаётся в первом агрументе. Сам массив во втором. Для случая, когда указанного ключа в массиве не существует, можно вернуть значение по-умолчанию. Ну и червёртым аргументом вы можете указать, чтобы пустое значение найденного элемента массива также перезаписалось дефолтным. Например, в видео про шаблонизатор я показывал, какие проблемы возникают из-за отсутствия четвертого параметра при определении класса парсера — когда у вас есть такая системная настройка и она пустая. Так вот, этот метод задуман так, что если вторым агрументом ничего не передавать, или передать null, пустую строку или пустой массив, то указанный ключ будет искаться в массиве настроек сайта, которые хранятся в специальном свойстве config класса xPDO.

class xPDO {
    ...
    /**
     * @var array Configuration options for the xPDO instance.
     */
    public $config= null;
    ...
}

Хотя, если даже передать массив, и в нём не будет указанного ключа, то MODX не сразу вернёт дефолтное значение, указанное в третьем агрументе. Он полезет проверять массив настроек. И если и там не найдёт указанный элемент, то только тогда вернёт значение по умолчанию.

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

К слову сказать, разработчики MODX по какой-то причине решили отказаться от одного их основных принципов ООП, называемым инкапсуляцией, и все свойства практически во всех классах сделали открытыми. Это соответственно несёт ряд проблем. Сейчас на курсах или в книгах учат создавать свойства или приватными или защищенными. Крайне редко советуют создавать открытые свойства. Например, если в каких-нибудь DTO-шках. Отметьте себе этот факт и пошли дальше.

Уровни настроек

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

В MODX настройки сайта формируются из настроек четырех объектов (перечислю их в порядке от общего к частному)

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

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

Использование

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

Тут я остановлюсь, чтобы разобраться в деталях. В своих видео про кэширование я показывал, что MODX кэширует и системные настройки и настройки контекстов. А вот настройки групп пользователей и самих пользователей мы в кэше не найдём. Разработчики MODX решили хранить их в сессии пользователя. В связи с чем, кстати, возникают проблемы инвалидации этих настроек, о чем мы поговорим ниже. Моё мнение — было бы правильнее настройки групп вынести в общий кэш. Ведь они от пользователя не зависят. А для настроек пользователя добавить возможность отключать их кэширование. Хотя тут тема сложнее, в сессию сохраняются не только настройки, но и другая информация. В частности, группы пользователя и права. По хорошему, это нужно переделывать. Почему? Дело в том, что изменения настроек или прав пользователей и групп нельзя сохранить в сессии пользователей. И для того, чтобы изменения вступили в силу, необходимо перелогиниться. Т.е. после того, как вы что-то поправили у группы пользователей или добавили пользователя в какую-то группу или наоборот удалили, нужно всех пользователей разлогинить принудительно.

Информация!

В MODX из коробки есть две группы пользователей — "(аноним)" и «Administrator». Первая группа используется для настройки прав доступа только для гостей, т.е. неаутентифицированных пользователей. И в отличие от второй группы является виртуальной. А это значит, что в неё нельзя добавить пользователей и настройки, хотя у неё присутствуют эти вкладки. Вы просто будете получать ошибки. Тогда зачем эта группа нужна, спросите вы? Только для настройки прав доступа гостей, так как в MODX права определяются только для групп пользователей.

Ну и напоследок. В классе modX есть два свойства (они тоже публичные, хотя начинаются с нижнего подчёркивания) — _systemConfig, которое содержит консолидированные настройки системы и контекста, т.е. первые 2 уровня, и _userConfig, которое содержит настройки группы и самого пользователя, т.е. последние 2 уровня. А config — это всего лишь объединение этих двух настроек.

Теперь вы знаете о настройках практически всё. Используйте эти знания по максимуму.

Комментарии ()

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