Олег

так, а в чем проблема во втором абзаце, не очень понял?

$modx->addEventListenerClosure(
    'OnWebPagePrerender',
    function (\MODX\Revolution\modX $modx) {
        (new \Namespace\YourClass($modx))->doSomething();
        // $class = $modx->services->get('yourservice'); $class->doSomething();
        // \Namespace\YourClass::doSomething();
        // my_global_function($modx);
        return null;
    },
    priority: 10,
    name: 'appendTestComment',
    replace: false
);

с обычными плагинами — я пока это не учитывал, но вопрос логичный. НО это не учитывается и в оригинальном методе addEventListener, так что текущая логика по сути не меняется. Оригинал:

public function addEventListener($event, $pluginId, $propertySetName = '') {
        $added = false;
        $pluginId = intval($pluginId);
        if ($event && $pluginId) {
            if (!isset($this->eventMap[$event]) || empty ($this->eventMap[$event])) {
                $this->eventMap[$event]= [];
            }
            $this->eventMap[$event][$pluginId]= $pluginId . (!empty($propertySetName) ? ':' . $propertySetName : '');
            $added = true;
        }
        return $added;
    }

Проблема в том что карта у них строится без какой либо доп информации о плагинах, просто событие->список ID плагинов, уже отсортированных в sql запросе. То есть пересортировать ее без дополнительного запроса к базе не получится (ну или надо сохранять расширенную карту из базы при инициализации и потом при добавлении нового плагина пересобирать итоговую карту). Сейчас реализовано так, что сначала выполняются плагины из бд — и подвязанные к событию в админке, и подвязанные к событию в коде, потом все closure плагины. Вообще это больше не для того чтобы кто-то в админке вручную тыкал, а чтобы например при разработке пакета вы спокойно свой функционал раскидали по нужным событиям и не парились с созданием плагинов и привязкой/отвязкой событий при обновлении например.

Да, но это приоритет выполнения именно Closure слушателей — они выполняются уже после плагинов из бд

Вот да, я тоже из этого исхожу)

Василий, здравствуйте! Очень интересное (и правильное) направление для развития modx экосистемы как мне кажется. В последнее время для разработки больше работаю с Laravel, но в плане управления контентом конечно очень удобен modx3 — файловый менеджер, дерево ресурсов, таблицы коллекций с инлайн редактированием и тд, на сборку удобной админки в ларавел уйдет оч много времени…

Так вот на проекте веб-приложения, который начинал писать давно еще на MODx, стал постепенно внедрять по частям ларавле параллельно с modx — получается modx живет в public и core, а рядом части ларавел в app, config и тд, с кастомным бутстрап файлом. И в modx подключается автолоадер laravel и кастомный конфиг инициализации контейнера с нужными сервисами типа лога, елоквента, кеша, блейда и фасадами.

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

Очень полезно что вы написали про возможность подключения композер файла прямо через основной файл modx — у меня реализовано через отдельный композер файл, подключаемый при инициализации modx. В целом направление интеграции modx и современных инструментов кажется очень перспективным, рад что вы снова тут (хоть и статьи прошлого года))