Архитектура MODX: как связаны xPDO, процессоры и менеджер

В MODX Revolution 3.x одна операция в панели управления проходит через несколько уровней: менеджер принимает действие пользователя, процессор проверяет входные данные и права, а xPDO загружает или меняет объекты в базе. Если смешать эти роли, код начинает зависеть от интерфейса, запросы обходят проверки, а обновление MODX превращается в риск. Ниже — разбор связей между xPDO, процессорами и менеджером без привязки к конкретному пакету или теме оформления.

Три слоя, которые нельзя путать

Архитектуру MODX удобно рассматривать не как набор отдельных файлов, а как цепочку ответственности. Каждый слой отвечает на свой вопрос:

• Менеджер — как администратор запускает операцию: через страницу, форму, дерево ресурсов или запрос из интерфейса.
• Процессор — что именно разрешено сделать, какие данные принять и какой результат вернуть.
• xPDO — как представить сущности MODX в виде объектов и выполнить работу с хранилищем.

Менеджер не должен быть местом, где вручную собираются SQL-запросы. Процессор не должен превращаться в шаблон HTML. xPDO не знает, какую кнопку нажал пользователь и зачем ему понадобился ресурс.

Главное правило расширения MODX: интерфейс инициирует действие, процессор принимает решение, xPDO работает с данными.

Объектная модель — описание таблиц и связей базы через классы, поля и отношения. В MODX эту роль выполняют модели xPDO: они позволяют обращаться к сущностям вроде ресурсов, пользователей и элементов системы не только как к строкам таблиц.

Что делает xPDO

xPDO — слой объектно-реляционного доступа, на котором построена работа MODX с базой данных. Он связывает PHP-классы объектов с таблицами и знает, как загрузить объект, сохранить его, удалить или получить связанные записи.

Модель вместо ручной сборки таблиц

Ресурс MODX — это не просто запись в таблице. У него есть поля, состояние публикации, родитель, шаблон, права доступа и связи с другими объектами. Когда код работает через модель, эти отношения остаются частью архитектуры приложения. При ручном SQL разработчик сам отвечает за имена таблиц, префикс базы, типы данных и согласованность связанных записей.

Это не означает, что xPDO автоматически делает любую операцию безопасной или правильной. Неверный фильтр, отсутствие проверки прав и слишком широкая выборка остаются ошибками прикладного кода. Слой доступа к данным не заменяет авторизацию.

Где проходит граница xPDO

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

Процессоры: точка входа для операций

Процессор в MODX — серверный обработчик действия. В менеджере процессоры используются для операций с ресурсами, пользователями, элементами и объектами компонентов. Название конкретного процессора, его поля и структура ответа зависят от версии MODX и расширения, поэтому переносить внутренний путь из одного проекта в другой без проверки нельзя.

Типичный жизненный цикл

1. Менеджер формирует запрос. В него попадают идентификатор объекта, поля формы и служебные параметры. Клиентский интерфейс не считается доверенным источником данных.
2. Процессор получает запрос. Он проверяет, существует ли объект, может ли текущий пользователь выполнить действие и достаточно ли входных данных.
3. Процессор обращается к модели. Для чтения и изменения сущностей используется xPDO-модель, а не копия логики из интерфейса.
4. Операция завершается ответом. Менеджер получает результат и показывает сообщение, обновляет список или возвращает ошибку.

На каждом шаге есть своя проверка. После запроса менеджера должен быть понятен набор переданных полей. После проверки процессора — причина отказа или право продолжить. После работы с xPDO — сохранённый объект, количество изменённых записей или контролируемая ошибка. Если эти состояния не различать, интерфейс может показать «успешно» после частично выполненной операции.

Почему процессор лучше прямого обработчика

Самописный обработчик в сниппете или отдельном PHP-файле кажется быстрее: принять POST, найти запись, обновить базу. Цена такого решения проявляется позже. В нём часто нет единой проверки разрешений, журналирования, нормальной обработки ошибок и совместимости с менеджером.

Процессор не делает код автоматически качественным, но помещает операцию в ожидаемую для MODX точку расширения. Это упрощает поиск логики, повторное использование действия и замену интерфейса без переписывания всей операции.

Менеджер — не «админская база», а клиент архитектуры

Менеджер MODX — административное приложение. Пользователь видит дерево ресурсов, списки, формы и системные настройки, но эти элементы не должны считаться источником истины. Они вызывают серверные операции и отображают их результат.

Отсюда следуют три практических вывода:

• скрытая кнопка не является защитой: право нужно проверять на сервере;
• проверка поля только в форме не заменяет проверку в процессоре;
• изменение менеджера не должно быть единственным способом выполнить важную операцию.

Последний пункт особенно важен для интеграций. Если импорт или внешний сервис повторяет действие менеджера, ему нужен серверный сценарий с теми же правилами, а не автоматизация кликов по административному интерфейсу.

Как проходит изменение ресурса

Рассмотрим не конкретный API-вызов, а границы ответственности. Пользователь открывает ресурс в менеджере и нажимает сохранение.

1. Форма отправляет идентификатор ресурса и изменённые поля.
2. Процессор проверяет сессию, разрешение пользователя и корректность данных.
3. Через xPDO загружается модель ресурса. Если объект не найден, операция прекращается с ошибкой, а не создаёт новую запись случайно.
4. Изменяются только поля, разрешённые сценарием. Значения, пришедшие от клиента, нельзя считать безопасными по умолчанию.
5. Изменения сохраняются, после чего менеджеру возвращается результат.
6. Интерфейс обновляет состояние формы и показывает ошибку либо успех.

В этой цепочке можно отдельно проверять четыре класса проблем: неверный идентификатор, отсутствие права, невалидное значение и сбой сохранения. Смешать их в один ответ «что-то пошло не так» удобно для разработчика, но плохо для диагностики и поддержки.

Где архитектура ломается

Прямой SQL из менеджерского кода

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

Логика в JavaScript

Клиентский код удобен для подсказок и предварительной проверки формы. Он не должен быть единственным местом, где решается, можно ли изменить ресурс или выполнить массовую операцию. Запрос можно отправить вручную, минуя интерфейс.

Универсальный процессор на всё

Процессор, который принимает десятки типов действий через параметр «mode», постепенно превращается в скрытый монолит. У него трудно определить права, проверить входные данные и понять, какая часть операции упала. Лучше разделять независимые сценарии и выносить общую работу с объектами в отдельные сервисы или методы компонента.

Зависимость от внутренних файлов менеджера

Копирование файла ядра с небольшим изменением создаёт форк внутренней реализации. При обновлении MODX такой файл не получает исправления и может перестать совпадать с новым менеджером. Для расширения используйте публично документированные механизмы и структуру компонента, а точные имена классов и методов сверяйте с документацией версии.

Что проверять на ревью

Для MODX полезно ревьюировать не только стиль PHP, но и путь операции целиком:

• Где находится серверная точка входа и какой процессор её обслуживает?
• Проверяются ли права на сервере, а не только видимость кнопки?
• Какие поля разрешено менять и что произойдёт при лишнем поле?
• Что случится, если объект удалён между загрузкой формы и сохранением?
• Используется ли модель xPDO там, где важны связи, события и единая работа с сущностью?
• Можно ли безопасно повторить запрос после тайм-аута, или операция выполнится дважды?
• Понятно ли по ответу, что именно сломалось: доступ, валидация, поиск объекта или сохранение?

Формулировка замечания должна быть конкретной: «проверка права есть только в JavaScript, запрос к процессору можно отправить напрямую» полезнее, чем «усильте безопасность». Так же точнее написать: «здесь обходится модель ресурса и теряется проверка связанной сущности», а не «используйте MODX правильно».

Что делать дальше

Возьмите одну реальную операцию вашего компонента — например, сохранение записи или массовое изменение ресурсов — и нарисуйте цепочку «менеджер → процессор → xPDO → ответ». Отдельно отметьте проверку прав, валидацию, загрузку объекта и сохранение. Затем проверьте операцию без интерфейса: запрос должен получить отказ без нужного разрешения и понятную ошибку при неверном идентификаторе.

После этого сравните реализацию с документацией MODX Revolution 3.x и версией xPDO, установленной в проекте. На проде наблюдайте не только HTTP-ошибки, но и повторные операции, длительность запросов к базе и долю отказов по правам. Инвалидация кеша и устройство конкретного менеджерского UI — отдельные темы; здесь важна граница между интерфейсом, процессором и моделью данных.