Василий Столейков

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

В рамках выполнения одной хитрой задачи, потребовалось написать скрипт, который будет запускаться по cron и что-то делать с MODX.

Проблемы, в общем то нет, вопрос изучен, но выплыл интересный глюк.
А именно: не работали процессоры для создания/обновления ресурсов.

То есть, процессор для логина — нормально, контекст mgr — нормально, а при попытке создать ресурс — просто пустая error.
Выложил вопрос на официальном форуме и никто мне не ответил. Пришлось разбираться самостоятельно, глубоко копая исходники.

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

Что же делать?
Все просто — нужно расширить сторонний класс своими методами. По сути, это очень похоже на «классные процессоры», только без процессоров и использовать можно везде — это стандартная возможность ООП.

Регулярно встречаю в сети разные велосипеды про то, как подключиться к MODX снаружи для работы с его Api. Даже на официальном сайте это описано сложновато.

В MODX есть файлы-процессоры, это php скрипты, которые выполняют определенные функции. Загляните в /core/model/modx/processors, и вы увидите, как их много.

Работать с процессорами можно из любого сниппета или плагина при помощи метода runProcessor:

$response = $modx->runProcessor('action/path/to/processor',$arrayOfProperties,$otherOptions);

В ответ мы получаем объект modProcessorResponse, со всеми его методами.

Ajax — это метод асинхронного запроса к серверу. Текущая страница html с помощью скрипта обращается к серверу с определенным вопросом, получает ответ и что-то с ним делает. Обычно — вставляет результат в страницу.