8 двухколёсных советов по MODX Revolution

С MODX Revolution я работаю не так уж давно, но, тем не менее, на данный момент, для меня это CMS-жемчужина. Гибкость, расширяемость и интуитивность (Если на минутку забыть о злополучном MODX Manager), привлекают в ней всё так же, как и в самом начале.
Ниже представлены заметки, которые я делал по ходу работы с MODX Revolution на протяжении прошлого года. Эти несложные приёмы, знай я о них раньше, помогли бы мне сэкономить неимоверное количество времени. Целевая аудитория этих заметок — новички, лишь недавно разобравшиеся в том, что же такое MODX. Откровенные «велосипеды», из уважения к вам, в заметки включать не стал.

1. Упрощение работы с MODX Manager

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

Ещё одна вещь, которая имеет весьма неблагоприятное влияние на производительность — RSS-фиды на главной странице менеджера, сообщающие о новых версиях и фиксах безопасности. Отключаются следующим образом: System -> System Settings -> MODX News Feed Enabled/MODX Security Feed Enabled -> No.

2. Передача параметров в сниппет

Предположим, у вас есть сниппет по имени Monkeys, выводящий на страницу самую обычную строку:

echo $howMany. ' ' .'Monkeys';

Этот спиппет вам необходимо выводить на нескольких страницах с разным значением переменной $howMany. Делается это весьма просто:

[[Monkeys?&howMany=`12`]]

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

3. Вызов MODX в статичном PHP файле

В случает, если сниппет вы используете лишь для include/require_once статичного файла, предыдущий приём всё равно сработает как положено. Но, что если необходимо использовать сам $modx объект? К примеру, забрать pagetitle определённого ресурса? Всё тоже весьма элементарно:

require_once '/var/www/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');

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

$resource = $modx->getObject('modResource', $modx->resourceIdentifier);
$pagetitle = $resource->get('pagetitle');

3. Switch контекста в зависимости от домена

В вышеописанном приёме промелькнула такая строчка:

$modx->initialize('web');

Это — инициализация default контекста, в котором, собственно, всё вышеописанное и отработает. Но, что если контекстов несколько, и каждый должен отображаться со своего определённого домена? Легко!

switch ($_SERVER['HTTP_HOST']) {

    case 'domainOne.com':
    $modx->initialize('web');
    break;

    case 'domainTwo':
    $modx->initialize('two');
    break;

    case 'domainThree':
    $modx->initialize('three');
    break;

    default:
    $modx->initialize('web');
    break;

}

Данный свитч необходимо запускать либо в плагине, на событии OnHandleRequest, либо немного «раньше», в конце index.php, чего вам, пожалуй, никто из ныне живущих не посоветует.

4. Switch по контексту

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

if($modx->context->get('key') != "mgr"){

    switch ($modx->context->get('key')) {

        case 'web':
        $howMany = 3;
        break;

        case 'two':
        $howMany = 8;
        break;

        case 'three':
        $howMany = 12;
        break;

        default:
        $howMany = 12;
        break;

    }
}

echo $howMany. ' ' .'Monkeys';

Условие if($modx->context->get('key') != «mgr»), как вы уже догадались, предотвращает запуск кода прямо в менеджере.

5. Настройки контекста

Ещё один способ варьировать контент на имеющихся контекстах — индивидуальные настройки. Откройте нужный вам контекст и перейдите во кладку Context Settings. По нажатии Create New, укажите Key, и, соответственно, Value. Созданный вами ключ, вызывается в документе/чанке следующим образом:

[[!++Key]]

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

Предыдущий метод, разумеется, хорош, но что если нам нужны всего лишь разные чанки в зависимости от контекста? Весьма полезен в этом плане ключ [[*context_key]], возвращающий имя текущего контекста. К примеру, создадим два чанка: Footer_Web и Footer_One, где Web и One — имена контекстов. Теперь, вызовем их на странице / в template:

[[$Footer_[[*context_key]]]]

7. modMail

modMail — класс, расширяемый modPHPMailer. По дефолту встроен в MODX и используется следующим образом:

$message = $modx->getChunk('myEmailTemplate');
 
$modx->getService('mail', 'mail.modPHPMailer');
$modx->mail->set(modMail::MAIL_BODY,$message);
$modx->mail->set(modMail::MAIL_FROM,'me@example.org');
$modx->mail->set(modMail::MAIL_FROM_NAME,'Johnny Tester');
$modx->mail->set(modMail::MAIL_SUBJECT,'Check out my new email template!');
$modx->mail->address('to','user@example.com');
$modx->mail->address('reply-to','me@xexample.org');
$modx->mail->setHTML(true);

if (!$modx->mail->send()) {
	$modx->log(modX::LOG_LEVEL_ERROR,'An error occurred while trying to send the email: '.$modx->mail->mailer->ErrorInfo);
}

$modx->mail->reset();

*Выдержка из официальной документации.

8. Из сниппета в чанк

Вышеописанный пример берёт чанк myEmailTemplate в качестве template для нашего письма. Если в письме необходимо отобразить, к примеру Username, полученный из формы, мы делает следующее:

$Username = $_POST['Username'];

$message = $modx->getChunk('myEmailTemplate', array(
   'username' => $Username,
));

Таким образом, мы передаём Username в наш чанк myEmailTemplate. Получаем его в чанке, таким вот способом:

<p>Username: [[+username]]</p>

На сегодня всё. Если кому-либо будут интересны подобные заметки, готов с радостью их продолжить. Благодарю за внимание.