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>


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

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 12

    –2
    Да. Интересны.
      0
      1. Очень рекомендую установить AjaxManager.

      2. Не нужно использовать echo, лучше делать return.

      3. В MODX Revolution давно есть статичные элементы, для которых можно указать файл. Естественно, в таких сниппетах сразу доступна переменная $modx и ничего подключать не нужно.

      Честно говоря, и при обычном include из нестатичного сниппета modX тоже не нужно инициализировать — он уже будет в вызывающем сниппете.

      4. Можно переключать контекст не только по домену, но и по base_url — вот готовые плагины для обоих способов.
        –3
        1. С AjaxManager, лично я, испытывал достаточно неприятные проблемы. Ресурс сохранялся с другим ID. Точнее, с ID предыдущего редактированного ресурса.

        3. То есть, выводить сниппет как Is Static? Благодарю за наводку, пригодится.
          +2
          1. Недавно вышла новая версия и с тех пор всё достаточно хорошо. Во всяком случае, я использую на всех своих сайтах и проблем нет.

          3. Нужно просто указать файл для сниппета и вызывать как обычно — MODX делает всю работу самостоятельно.


          Так можно делать и с чанками, плагинами, шаблонами и даже ТВ параметрами. В общем, с любыми наследниками modElement.
          0
          С АяксМенеджером при редактировании статичных ресурсов баг — контент заменяется кодом из других чанком/шаблонов.
          Ну а с выходом 2.3 версии багов поприбавилось
            0
            Очень обрадовался, когда прочитал про AjaxManager. Сразу установил и сразу же наткнулся на баг — он просто ломает админку: подгружает через AJAX страницы, но не выводит их, оставляя висеть лоадер.
              0
              1. Желательно использовать последние версии и дополнения, и MODX.
              2. Обязательно нужно почистить кэш сайта (желательно удалением /core/cache/) и браузера.

              Компонент проверен много раз — он полностью рабочий. Косячки небольшие есть, но админку точно не ломает.
                0
                Вроде все правильно делаю:
                MODX Revolution 2.3.3-pl (traditional)
                AjaxManager 1.2.0-pl
                Каталог кеша удалял, в админке перелогинивался, кеш браузера чистил. Тестировал в FireFox и Chrome.

                Вот тут описание проблемы и решение modx.pro/help/4778/
                  0
                  Проверил на своём любимом хостинге — нет проблем.

                  Данные для логина на сайт кинул в личку. Никакие настройки не менял, только установил AjaxManager. Видимо, автоматическре включение компрессии скриптов как-то зависит от хостинга.
                    0
                    Я так понял, что значение compress_js зависит от типа установки. В случае использования Git deployments он падает в No, при том, что по умолчанию должен быть включен. Т.к. вы разворачиваете через консоль, то скорей всего используете именно Git deployments — поэтому у вас AjaxManager и работает. А вот я MODX ручками ставил, поэтому без дополнительных настроек не завелось.
                      0
                      Нет, у нас используется только релизные архивы с официального сайта, никаких Git deployments.

                      Не знаю, когда после установки compress_js становится true или false, но это явно зависит от сервера. Например, нашел вот это в скрипте установки.
            0
            Хе-хе, пост зла)

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

            Самое читаемое