Свой компонент в MODX: опыт внедрения без хаоса

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

С чего начинать: не с таблицы, а с процесса

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

Для проектирования достаточно зафиксировать четыре вещи:

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

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

Компонент в MODX — это не новая таблица. Это граница ответственности: где хранятся данные, кто ими управляет и какие правила нельзя нарушить.

Когда не стоит писать компонент

Главный критерий — не количество полей, а самостоятельность сущности. Если запись должна жить независимо от ресурса, иметь историю изменений или попадать в обмен с внешней системой, TV обычно превращается в временное решение.

Как устроить компонент в MODX 3.x

Модель данных

В основе пакета находится схема данных: описание сущностей, полей, индексов и связей. Для MODX это обычно модель на базе xPDO. Важно заранее определить имена таблиц, обязательность полей и поведение при удалении связанных записей.

Не храните статус как произвольный текст, если от него зависит процесс. Задайте ограниченный набор значений и один источник правды. Иначе в базе появятся варианты вроде new, новая и Новая заявка, а фильтр начнёт пропускать часть данных.

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

Слой бизнес-правил

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

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

Интерфейс менеджера

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

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

Как проходило внедрение

1. Сначала — прототип данных

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

Проверка: запись создаётся, открывается повторно, фильтруется по ключевым полям и корректно удаляется вместе с зависимыми данными согласно выбранному правилу.

2. Затем — один полный пользовательский сценарий

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

Проверка: сотрудник без административных прав выполняет только разрешённые действия, а запрещённая операция возвращает ошибку и не меняет данные.

3. После этого — упаковка

Компонент нужно устанавливать как транспортный пакет, а не переносить вручную отдельными файлами и SQL-командами. В пакет должны попасть модель, контроллеры, меню, пространства имён, настройки и необходимые системные объекты.

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

4. Только потом — импорт и интеграции

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

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

Что обычно ломается

• Компонент работает только у администратора. Часто забыты права доступа к пространству имён, меню или объектам. Проверяйте сценарий под отдельной группой пользователя.
• Форма открывается, но список пуст. Причина может быть в неверном подключении модели, имени класса или фильтре. Сначала проверьте, что запрос видит таблицу и возвращает записи без условий интерфейса.
• После обновления пропадают настройки. Если изменения вносились вручную в файлы или базу, установщик пакета может их перезаписать. Все обязательные изменения должны быть описаны в версии пакета.
• Удаление оставляет «сироты». Связанные записи не всегда исчезают автоматически. Для каждой связи заранее выберите запрет удаления, каскадное удаление или сохранение истории.
• Фильтр медленно работает на большом объёме. Не начинайте с переписывания интерфейса. Посмотрите фактический запрос, план выполнения и наличие индекса по полю фильтра.

Где подход ломается

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

Есть и эксплуатационная цена. После внедрения нужно поддерживать совместимость с MODX Revolution 3.x, PHP и используемыми дополнениями, проверять установку на копии сайта и хранить резервную копию базы перед обновлением. Для небольшого сайта это может оказаться дороже, чем дисциплинированно настроенный MIGX.

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

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

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

Инвалидация кеша и построение полнотекстового поиска — отдельные темы. В текущем компоненте сначала добейтесь корректной модели и предсказуемых прав, а уже затем оптимизируйте выдачу.

Сноска. Транспортный пакет — архив и набор описаний, через которые MODX устанавливает и обновляет элементы дополнения: модели, настройки, меню и связанные объекты.