С 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>
На сегодня всё. Если кому-либо будут интересны подобные заметки, готов с радостью их продолжить. Благодарю за внимание.
Автор: Benjaminabel
