Предложение нового механизма closure и слушателей событий в bootstrap неймспейсов MODX с приоритетами и именами

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

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

В процессе пришла идея «а зачем создавать плагины в пакете, если сейчас MODX 3 подключает bootstrap.php файл расширения, и по сути мы в этом бутстрапе можем зарегистрировать слушателей событий без плагинов вовсе».

Для этого так кстати есть метод

$modx->addEventListener

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

Даже если мы пойдем дальше и в бутстрапе попробуем обхитрить MODX, заранее создав карту:

if ($modx->eventMap === null) {
    $modx->eventMap = $modx->getEventMap('web');
}
$modx->addEventListener('OnWebPagePrerender', 33);

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

Собственно немного там поковыряв, получилось такое решение — пулл-реквест на гитхабе.

• Возможность добавлять runtime-события через addEventListener(), которые живут в отдельном свойстве $modx и не затираются при инициализации eventMap() из БД.
• 🔥 Новый метод addEventListenerClosure(...) — чтобы навешивать слушатели-замыканя (closures) с указанием приоритета и имени.
• Универсальный метод удаления removeEventListenerClosure(...), который позволяет удалять слушателей по событию, приоритету или имени, либо глобально.
• Всё сделано с сохранением обратной совместимости, чтобы плагины и существующие события продолжали работать как раньше.

Такой подход даст возможность в в bootstrap’е пакета (да и в целом в любом месте) повесить нужные event listener — например, чтобы модифицировать вывод страницы, добавить логирование, вставить JS и т.п. При этом введение closure-слушателей с именами и приоритетом делает код чище, облегчает написание расширений без создания плагинов в админке.

Пример тестирования достаточно подробно описан в пулл-реквесте, меняется там только modX файл — предлагается просто закинуть его в проект-черновик и потестить.

Хотелось бы обратную связь сообщества:

• Насколько вы считаете эту идею полезной?
• Есть ли юз-кейсы, которые не покрываются предлагаемой схемой?
• Какие риски или неудобства видите? (например, производительность, совместимость, сложность).
• Есть ли предложения, как сделать API ещё удобнее?
• ...