Плагины MODX и системные события: чек-лист перед продакшеном

Один плагин MODX, подписанный на событие сохранения ресурса, способен добавить задержку каждому сохранению в менеджере — или вызвать фатальную ошибку, если ожидаемые данные не пришли. Перед выкладкой проверьте не только код обработчика, но и событие, условия запуска, порядок выполнения и поведение при ошибках. Чек-лист ниже — для проектов на MODX Revolution 2.8.x и 3.x; конкретные отличия API сверяйте с документацией своей версии.

Сначала определите, где и когда срабатывает плагин

Плагин в MODX привязан к системным событиям: например, к действиям с ресурсами, пользователями или запросом. Название события — часть контракта, а не удобная метка. Если обработчик должен запускаться после сохранения ресурса, проверьте, что он подписан именно на подходящее событие и видит нужные данные в этот момент.

• Запишите ожидаемый сценарий: действие пользователя или запрос, событие MODX, результат обработчика.
• Проверьте список событий в настройках плагина и сверьте его с документацией для установленной версии.
• Убедитесь, что плагин не подписан на событие «на всякий случай». Лишний запуск увеличивает нагрузку и число мест, где возможна ошибка.
• Проверьте, где выполняется сценарий: в менеджере, на фронтенде, в API или в задаче, запущенной из консоли. Не каждое событие вызывается во всех этих контекстах.

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

Проверьте условия запуска и побочные эффекты

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

1. Проверьте обычный путь. Выполните действие, которое должно запускать плагин, и зафиксируйте ожидаемый результат. Проверка пройдена, если результат совпадает с описанным сценарием.
2. Проверьте исключённый путь. Повторите действие в другом контексте или с другим типом ресурса. Плагин не должен менять данные там, где запуск не предусмотрен.
3. Проверьте повторный запуск. Повторите запрос или сохранение. Обработчик не должен создавать дубликаты, повторно отправлять уведомления или накапливать одно и то же изменение.
4. Проверьте отсутствие необязательных данных. Уберите значение, которое может не прийти в этом сценарии. Плагин должен корректно завершиться или сообщить об ожидаемой ошибке, а не падать с обращением к отсутствующему значению.
5. Проверьте права. Запустите действие от пользователя с минимальными нужными привилегиями. Убедитесь, что плагин не расширяет их незаметно и не меняет чужие данные.

Отдельно посмотрите на побочные эффекты: отправку писем, запросы к внешним сервисам, запись файлов и изменения нескольких ресурсов. Если действие может выполниться повторно, продумайте защиту от дублирования. Если внешняя система временно недоступна, не превращайте её сбой в необъяснимую поломку сохранения в MODX.

Порядок выполнения и стоимость запуска

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

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

Измерения на тестовой копии не гарантируют такую же картину в продакшене: объём данных, кэш и конкурирующие запросы отличаются. Зафиксируйте условия проверки и после выкладки наблюдайте за теми же показателями.

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

Ошибки, журналирование и кэш

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

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

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

Где чек-лист не спасает

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

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

Что сделать перед выкладкой

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

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

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