Общая информация о принципе действия Joomla 6. Жизненный цикл Приложений Joomla.

Как работает ядро Joomla 6 на уровне Приложения (Application)? Сколько видов Приложений на самом деле есть в Joomla и в чём между ними разница? Какой жизненный цикл каждого Приложения Joomla, включая маршрутизацию, диспетчеризацию и события плагинов? На эти и другие вопросы попытается дать ответ эта статья, опирающаяся на кодовую базу Joomla 6.1.0.

Joomla 6 строит запрос вокруг объекта приложения, которое инициализирует окружение, разбирает запрос, передаёт управление компоненту, собирает документ и затем отправляет ответ. Плагины вмешиваются в работу в строго определённых точках этого цикла.

Для Joomla 3 хочу упомянуть статью Дмитрия Рекуна "Общая информация о принципе действия Joomla", которая довольно подробно описывает как Joomla работала раньше.

Что происходит в Joomla при создании HTML-страницы?

Обычный запрос HTML в Joomla начинается в index.php в корне сайта (если речь идёт о пользовательской части).

Сначала входной файл:

1. проверяет минимальную версию PHP;
2. определяет _JEXEC, чтобы внутренние файлы Joomla нельзя было выполнять напрямую;
3. подключает defines.php из корня сайта (если он существует): его используют для предварительного определения или переопределения констант с путями при нестандартной структуре каталогов (Joomla находится за пределами web root);
4. подключает includes/defines.php, где задаются основные JPATH_*-константы;
5. передаёт управление в includes/app.php.

В includes/app.php Joomla сохраняет время старта и память, ещё раз поднимает определения путей, проверяет наличие обязательных зависимостей и подключает includes/framework.php. Во framework.php загружается libraries/bootstrap.php, проверяется состояние установки, читается configuration.php, настраиваются ошибки, JDEBUG и базовые параметры окружения.

После этого начинается уже загрузка Приложения Joomla 6:

1. берётся DI-контейнер через Factory::getContainer();
2. для сайта настраиваются алиасы веб-сессии;
3. из контейнера создаётся SiteApplication;
4. приложение записывается в Factory::$application;
5. вызывается $app->execute().

Дальше управление переходит к CMSApplication::execute(): проверяются опасные системные переменные, настраивается журнал, строится карта пространств имён расширений (которая потом кэшируется в autoload_psr4.php), загружаются плагины behaviour и system, вызывается onBeforeExecute, затем приложение выполняет свой основной цикл.

Для HTML-страницы сайта этот цикл кратко выглядит следующим образом:

index.php
  -> includes/defines.php
  -> includes/app.php
  -> includes/framework.php
  -> DI-контейнер
  -> SiteApplication
  -> CMSApplication::execute()
  -> onBeforeExecute
  -> initialiseApp()
  -> onAfterInitialise
  -> route()
  -> onAfterRoute
  -> dispatch()
  -> onAfterInitialiseDocument
  -> компонент
  -> onAfterDispatch
  -> render()
  -> onBeforeRender
  -> сборка HTML-документа и шаблона
  -> onAfterRender
  -> compress() [если включён gzip]
  -> onAfterCompress [если включён gzip]
  -> onBeforeRespond
  -> respond()
  -> onAfterRespond

Для каждого типа приложений Joomla используется своя точка входа. А REST API свой рендер - JSON, вместо HTML - и свой роутинг. У CLI - вывод в консоль. Ниже эти различия разобраны подробнее.

Типы приложений

В Joomla 6 есть несколько типов Приложений, каждое из которых создано для определённого круга задач.

Приложение административной части

Класс: Joomla\CMS\Application\AdministratorApplication.

Отвечает за /administrator, вход администратора, меню панели управления, формы редактирования и внутренние сервисы панели управления.

Приложение публичной части сайта

Класс: Joomla\CMS\Application\SiteApplication.

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

API-приложение

Класс: Joomla\CMS\Application\ApiApplication.

Joomla REST API с точкой входа в /api. Тут согласуется формат ответа, роуты, проверяются права доступа к API.

Консольное приложение

Класс: Joomla\CMS\Application\ConsoleApplication.

CLI интерфейс Joomla, точка входа: cli/joomla.php. Здесь нет HTML, применяется обычно для "тяжёлых задач" и для "тру админов".

Демон

Класс: Joomla\CMS\Application\DaemonApplication.

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

Daemon приложение Joomla наследуется от CliApplication, а не от CMSApplication, поэтому у него свой жизненный цикл. В ядре Joomla готовых примеров самого DaemonApplication нет. Но это хороший повод для экспериментов. CliApplication - устаревший класс, в дальнейшем Daemon скорее всего будет наследоваться от нового ConsoleApplication.

Иерархия классов Application Joomla

• Joomla\Application\AbstractApplication
  • Joomla\Application\AbstractWebApplication
    • Joomla\CMS\Application\WebApplication
      • Joomla\CMS\Application\CMSApplication
        • Joomla\CMS\Application\SiteApplication
        • Joomla\CMS\Application\AdministratorApplication
        • Joomla\CMS\Application\ApiApplication
        • Joomla\CMS\Installation\Application\InstallationApplication
  • Joomla\Console\Application
    • Joomla\CMS\Application\ConsoleApplication
    • Joomla\CMS\Installation\Application\CliInstallationApplication
  • Joomla\CMS\Application\CliApplication
    • Joomla\CMS\Application\DaemonApplication

Контракты приложений Joomla

• Joomla\CMS\Application\CMSApplicationInterface
  • Joomla\CMS\Application\CMSApplication
  • Joomla\CMS\Application\ConsoleApplication
  • Joomla\CMS\Application\CliApplication
  • Joomla\CMS\Installation\Application\CliInstallationApplication
• Joomla\CMS\Application\CMSWebApplicationInterface
  • Joomla\CMS\Application\CMSApplication
    • Joomla\CMS\Application\SiteApplication
    • Joomla\CMS\Application\AdministratorApplication
    • Joomla\CMS\Application\ApiApplication
    • Joomla\CMS\Installation\Application\InstallationApplication

Обычные веб-клиенты Joomla, то есть site, administrator и api, наследуются через цепочку WebApplication → CMSApplication.

ConsoleApplication реализует CMS-контракт, но не является веб-приложением.

DaemonApplication не наследуется от CMSApplication; он идёт через CliApplication, поэтому у него отдельный жизненный цикл.

Пример порядка выполнения веб-приложения

Ниже описан общий цикл для SiteApplication и AdministratorApplication. Для API он почти такой же, но со своим роутингом.

Подготовка к выполнению приложения

Точка входа (index.php, administrator/index.php или api/index.php) выполняет базовую загрузку:

1. определяет константы путей;
2. поднимает автозагрузку;
3. создаёт DI-контейнер (подключение зависимостей);
4. через сервис-провайдеры собирает объект приложения и внедряет в него диспетчер событий, логгер, сессию и другие сервисы;
5. вызывает $app->execute().

С этого момента жизненным циклом управляет уже само приложение.

Общий цикл CMSApplication::execute()

Базовая логика живёт в libraries/src/Application/CMSApplication.php::execute().

Порядок работы такой:

1. Проверка опасных системных переменных.
2. Настройка журнала.
3. Построение карты пространств имён (неймспейсов) расширений.
4. Загрузка плагинов группы behaviour (в ядре Joomla это: плагин обратной совместимости, версионность и поддержка тегов com_tags).
5. Загрузка плагинов группы system.
6. Вызов onBeforeExecute.
7. Выполнение прикладной части через doExecute().
8. Если создан документ, вызов render().
9. При включённом GZIP-сжатии в конфиге Joomla - вызов compress() и затем onAfterCompress.
10. Вызов onBeforeRespond.
11. Отправка ответа через respond().
12. Вызов onAfterRespond.

Итого:

• onBeforeExecute — самая ранняя общая точка для системных плагинов;
• onBeforeRespond — последняя точка до отправки заголовков и тела ответа;
• onAfterRespond — заключительный этап после отдачи заголовков и тела ответа браузеру: журналирование, отладка, побочные действия.

Отдельно важно: в WebApplication существует ещё onAfterExecute, но в обычном запросе Joomla CMS он не вызывается, потому что CMSApplication переопределяет execute() своим циклом.

Инициализация

Инициализация проходит внутри CMSApplication::initialiseApp(), а у SiteApplication и AdministratorApplication есть свои дополнения.

На этом этапе Joomla:

1. в приложениях сайта и административной части уточняет язык и, при необходимости, группы доступа пользователя;
2. создаёт объект языка и загружает его в приложение;
3. подключает файлы локализации (ini-файлы языков);
4. выбирает редактор для текущего пользователя;
5. вызывает onAfterInitialise.

Важно не смешивать этот этап с более ранней сборкой приложения. Объекты сессии, диспетчера событий, журнала и другие сервисы внедряются ещё при создании приложения в сервис-провайдере libraries/src/Service/Provider/Application.php. Текущий пользователь подтягивается из сессии через WebApplication::afterSessionStart(), а не создаётся внутри initialiseApp().

Именно после onAfterInitialise можно считать, что у приложения уже есть в рабочем состоянии:

• сессия;
• язык;
• пользователь;
• конфигурация;
• диспетчер событий.

Это хороший момент для ранней настройки среды: язык уже выбран, редактор известен, базовые сервисы доступны, но к рендеру компонента Joomla ещё не приступила, поэтому логика, зависящая от url, здесь ещё преждевременна.

Маршрутизация и проверка доступа

Публичная часть

В SiteApplication::route():

1. создаётся или берётся текущий Uri;
2. роутер разбирает адрес;
3. найденные переменные записываются во входные данные приложения;
4. вызывается onAfterRoute;
5. выполняется проверка доступа к текущему Itemid (id пункта меню) через authorise().

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

Административная часть

В AdministratorApplication::route() логика проще:

1. при необходимости выполняется перевод на HTTPS;
2. проверяется состояние страниц многофакторной проверки;
3. вызывается onAfterRoute.

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

API

В ApiApplication::route() порядок другой:

1. загружаются плагины группы webservices;
2. вызывается onBeforeApiRoute;
3. маршрутизатор API подбирает маршрут;
4. Joomla согласует формат ответа по заголовку Accept;
5. переменные маршрута записываются во входные данные;
6. вызывается onAfterApiRoute;
7. при необходимости выполняется вход пользователя для закрытых маршрутов.

Для API важен именно onBeforeApiRoute: через него можно добавить или поправить роуты REST API Joomla до собственно роутинга.

Отдельно: как работает DaemonApplication

На демон-процессы обычно вешают задачи, которые должны жить долго, работать в фоне и не зависеть от HTTP-запроса или разового запуска CLI-команды.

Типичные задачи:

• постоянная обработка очереди: email, SMS, webhooks, экспорт/импорт, генерация файлов;
• воркеры фоновых заданий, где нужно быстро подхватывать новые задачи без запуска PHP с нуля каждый раз;
• слушатели внешних событий: сокеты, очереди сообщений, брокеры, long polling, системные события;
• периодическая фоновая работа с собственным циклом: очистка, синхронизация, пересчёт агрегатов, мониторинг;
• процессы, которым нужно держать состояние в памяти: кэш подключений, открытые соединения, подготовленные ресурсы;
• интеграции с внешними сервисами, где нужно постоянно принимать или отправлять события;
• сервисные процессы, где важны PID-файл, сигналы SIGTERM/SIGHUP, мягкая остановка и перезапуск.

Для Joomla-практики чаще всего это были бы не обычные задачи расширений, а инфраструктурные вещи: воркер очереди, постоянный импорт, синхронизация с CRM/маркетплейсом, обработчик вебхуков из очереди, индексация, массовая рассылка, мониторинг состояния. Если задача может спокойно запускаться раз в минуту по cron и завершаться, демон обычно не нужен. Демон оправдан, когда процесс должен быть постоянно запущен, быстро реагировать, держать ресурсы открытыми или управляться через сигналы и PID.

Поэтому DaemonApplication живёт по другому сценарию, нежели сайт, админка или API. Это не разовый запрос-ответ, а долгоживущий процесс, который:

1. стартует из CLI;
2. при необходимости уходит в фон;
3. пишет PID-файл;
4. подключает обработчики Unix-сигналов;
5. бесконечно гоняет doExecute() в цикле.

Требования к окружению для демона на базе Joomla

Конструктор DaemonApplication проверяет наличие расширения PCNTL и наличие функций POSIX. Если их нет, приложение падает ещё в __construct().

Какие параметры он готовит?

Метод loadConfiguration() нормализует и подготавливает служебные параметры демона:

• author_name
• author_email
• application_name
• application_description
• application_executable
• application_directory
• application_pid_file
• application_uid
• application_gid
• application_require_identity
• max_execution_time
• max_memory_limit

По умолчанию DaemonApplication строит PID-файл в абсолютном системном Unix-каталоге /tmp, по шаблону /tmp/<application_name>/<application_name>.pid. Это не временная папка конкретной Joomla-установки. Если очень нужно, путь можно переопределить через конфигурационный параметр application_pid_file.

Как выглядит жизненный цикл демона на Joomla?

Порядок в DaemonApplication::execute() такой:

1. onBeforeExecute
2. включение сборки мусора gc_enable()
3. попытка перейти в режим демона через daemonize()
4. если переход удался:
   1. включение declare(ticks=1) для мониторинга сигналов
   2. бесконечный цикл:
      1. gc()
      2. usleep(1000)
      3. doExecute()
5. onAfterExecute вызывается только если запуск не удался или если выполнение вообще вышло из цикла

На заметку:

для DaemonApplication событие onAfterExecute существует реально, но при нормальной бесконечной работе демона до него обычно не доходят.

Это важное отличие Joomla Daemon от веб-цикла Joomla:

• у демона нет onAfterInitialise, onAfterRoute, onAfterDispatch, onBeforeRender, onAfterRender, onBeforeRespond, onAfterRespond;
• у него есть только ранний onBeforeExecute, поздний onAfterExecute и специфические onFork и onReceiveSignal.

Что делает daemonize()

Метод daemonize() последовательно:

1. проверяет через isActive(), не запущен ли уже такой демон;
2. сбрасывает внутренние флаги процесса;
3. если не передан флаг -f, вызывает detach() и уходит в фон;
4. если -f передан, остаётся на переднем плане;
5. пишет PID-файл через writeProcessIdFile();
6. пытается сменить пользователя и группу через changeIdentity();
7. подключает обработчики сигналов через setupSignalHandlers();
8. меняет рабочую директорию на application_directory.

Что значит флаг -f

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

Как работает fork

Уход в фон делается в detach(), а само разделение процесса — в fork().

Ключевая деталь ядра:

1. вызывается pcntl_fork();
2. и в родительском, и в дочернем процессе вызывается postFork();
3. postFork() отправляет событие onFork.

То есть:

onFork срабатывает после разделения процесса и проходит в обоих потоках выполнения, родительском и дочернем.

Это хорошая точка для post-fork инициализации:

• переподключить сокеты;
• заново открыть файловые дескрипторы;
• переинициализировать соединения, которые нельзя безопасно делить после fork.

Как работает onReceiveSignal

Статический обработчик DaemonApplication::signal($signal):

1. пишет сигнал в журнал;
2. берёт текущий экземпляр приложения из static::$instance;
3. отправляет событие onReceiveSignal;
4. только потом выполняет встроенную реакцию ядра.

Это значит, что обработчик плагина получает сигнал до штатной реакции класса.

Какие сигналы обрабатываются встроенно

Ядро по умолчанию вешает обработчик на длинный список POSIX-сигналов из static::$signals.

Практически важные встроенные ветки такие:

• SIGINT, SIGTERM — мягкое завершение через shutdown();
• SIGHUP — завершение с последующим перезапуском через shutdown(true);
• SIGCHLD, SIGCLD — уборка завершившихся дочерних процессов через pcntlWait().

Для остальных сигналов ядро только отправляет onReceiveSignal, а специального встроенного поведения не добавляет.

Как он определяет, что демон уже работает?

Метод isActive():

1. читает PID-файл;
2. проверяет, что PID корректен;
3. делает posix_kill($pid, 0) как проверку живого процесса;
4. если процесс не отвечает, удаляет устаревший PID-файл.

То есть здесь используется именно проверка существования процесса, а не простое наличие файла.

Что делает shutdown()

shutdown():

1. ставит флаг завершения;
2. если демон ещё не был полностью поднят, просто завершает текущий процесс;
3. если это главный процесс, читает PID из файла;
4. удаляет PID-файл;
5. при restart=true перезапускает ту же команду;
6. иначе завершает процесс.

Отдельная хронология для DaemonApplication

Если собрать всё вместе, жизненный цикл выглядит так:

Запуск CLI
  -> new DaemonApplication(...)
  -> проверка PCNTL и POSIX
  -> loadConfiguration()
  -> execute()
  -> onBeforeExecute
  -> daemonize()
  -> isActive()
  -> detach() / foreground mode
  -> fork()
  -> onFork
  -> writeProcessIdFile()
  -> changeIdentity()
  -> setupSignalHandlers()
  -> declare(ticks=1)
  -> while (true)
       -> gc()
       -> usleep(1000)
       -> doExecute()
  -> при поступлении сигнала
       -> onReceiveSignal
       -> shutdown()/restart()/reap children
  -> onAfterExecute

Важные детали

Для демона Joomla ядро даёт всего четыре действительно системных точки:

• onBeforeExecute
• onAfterExecute
• onFork
• onReceiveSignal

Но именно для фоновых процессов это и есть главные точки расширения.

При этом Daemon приложение Joomla само не импортирует какие-либо группы плагинов по умолчанию (на данный момент -Joomla 6.1). Поскольку это в любом случае довольно специфичный сценарий - вы импортируете нужные группы плагинов самостоятельно. Также помните, что вы можете здесь использовать и классы фреймворка Joomla и библиотек, входящих в состав ядра Joomla.

Диспетчеризация

После маршрутизации приложение передаёт управление компоненту.

Публичная и административная часть

В SiteApplication::dispatch() и AdministratorApplication::dispatch() порядок такой:

1. создаётся документ;
2. настраиваются метаданные, шаблон и реестры ресурсов;
3. вызывается onAfterInitialiseDocument;
4. компонент отрисовывается через ComponentHelper::renderComponent();
5. результат кладётся в буфер документа;
6. вызывается onAfterDispatch.

onAfterInitialiseDocument — это точка до выполнения компонента: документ уже существует, но компонент ещё не отработал. Здесь удобно править тип документа, метаданные, реестры стилей и сценариев. Помните, что это событие появилось только в Joomla 5.0.0.

onAfterDispatch — это точка после выполнения компонента. Здесь уже можно работать с буферами документа и итогом работы компонента.

API

В ApiApplication::dispatch() смысл тот же:

1. создаётся документ;
2. вызывается onAfterInitialiseDocument;
3. вызывается диспетчер компонента веб-служб.
4. вызывается onAfterDispatch.

Сборка документа

Для фронтенда (SiteApplication) и админки это обычно HTML. Хотя нужно упомянуть, что внутри компонента за формат рендера отвечает View и View может отдавать и txt, и json, и XML - что угодно, не только HTML. Но рассмотрим стандартный путь, когда сборка ответа в HTML делает CMSApplication::render().

Порядок такой:

1. заполняются параметры шаблона;
2. выполняется $this->document->parse(...);
3. вызывается onBeforeRender;
4. документ формирует итоговую строку ответа;
5. строка записывается в тело ответа через setBody();
6. вызывается onAfterRender.

Здесь есть важная деталь: во время сборки HTML-заголовка libraries/src/Document/Renderer/Html/MetasRenderer.php вызывает onBeforeCompileHead.

То есть:

• onBeforeRender — общий поздний этап перед окончательной сборкой страницы;
• onBeforeCompileHead — специальная точка именно для <head>;
• onAfterRender — этап, когда вся HTML-строка уже собрана и её можно переписать целиком.

Вывод ответа

После сборки документа CMSApplication::execute() завершает запрос:

1. при включённом сжатии вызывает onAfterCompress;
2. вызывает onBeforeRespond;
3. отправляет заголовки и тело;
4. вызывает onAfterRespond.

onAfterCompress важно понимать буквально. В CMSApplication::execute() он вызывается только после $this->compress() и только если включён параметр gzip, при этом PHP не использует zlib.output_compression и текущий output_handler не равен ob_gzhandler. Это событие относится к CMS-циклу SiteApplication, AdministratorApplication и ApiApplication; у базового WebApplication::execute() сжатие тоже есть, но события onAfterCompress после него нет.

На практике:

• onBeforeRespond — последняя безопасная точка для заголовков и тела ответа;
• onAfterRespond — не место для изменения ответа, а место для побочных действий после того, как HTML отдан в браузер.

Схема цикла выполнения

Публичная часть

index.php
  -> SiteApplication::execute()
  -> onBeforeExecute
  -> initialiseApp()
  -> onAfterInitialise
  -> route()
  -> onAfterRoute
  -> dispatch()
  -> onAfterInitialiseDocument
  -> renderComponent()
  -> onAfterDispatch
  -> render()
  -> onBeforeRender
  -> onBeforeCompileHead
  -> onAfterRender
  -> compress() [если включён gzip]
  -> onAfterCompress [если включён gzip]
  -> onBeforeRespond
  -> respond()
  -> onAfterRespond

Админка Joomla

administrator/index.php
  -> AdministratorApplication::execute()
  -> onBeforeExecute
  -> initialiseApp()
  -> onAfterInitialise
  -> route()
  -> onAfterRoute
  -> dispatch()
  -> onAfterInitialiseDocument
  -> renderComponent()
  -> onAfterDispatch
  -> render()
  -> onBeforeRender
  -> onBeforeCompileHead
  -> onAfterRender
  -> compress() [если включён gzip]
  -> onAfterCompress [если включён gzip]
  -> onBeforeRespond
  -> respond()
  -> onAfterRespond

REST API Joomla

api/index.php
  -> ApiApplication::execute()
  -> onBeforeExecute
  -> initialiseApp()
  -> onAfterInitialise
  -> route()
  -> onBeforeApiRoute
  -> parseApiRoute()
  -> onAfterApiRoute
  -> dispatch()
  -> onAfterInitialiseDocument
  -> component dispatcher
  -> onAfterDispatch
  -> render()
  -> compress() [если включён gzip]
  -> onAfterCompress [если включён gzip]
  -> onBeforeRespond
  -> respond()
  -> onAfterRespond

Полная хронологическая карта триггеров Joomla во время запроса

Ниже уже не укрупнённая схема, а именно хронология. Важно помнить две вещи:

1. не все ветви выполняются в каждом запросе;
2. часть событий внутри формирования HTML зависит от конкретного шаблона и от того, в каком месте шаблон вызывает jdoc:include.

Самый первый триггер в жизненном цикле Joomla

Ещё до onBeforeExecute ядро успевает загрузить группы behaviour и system.

Для каждого плагина, который загружается через PluginHelper::importPlugin(), перед созданием экземпляра и сразу после него проходят:

1. onBeforeExtensionBoot
2. onAfterExtensionBoot

Это касается:

• плагинов behaviour и system в начале запроса;
• плагинов webservices в API;
• плагинов content, user, installer, extension, finder, privacy, quickicon, sampledata и других в более поздних ветках;
• компонентов и модулей, когда они загружаются через bootComponent() и bootModule().

Поэтому onBeforeExtensionBoot и onAfterExtensionBoot — самые ранние реально доступные точки вмешательства в жизненный цикл расширения.

Полный порядок для обычной HTML-страницы сайта

Ниже порядок для типового запроса фронтенда с HTML-документом.

Базовая последовательность

1. Для каждого загружаемого плагина группы behaviour: onBeforeExtensionBoot -> onAfterExtensionBoot
2. Для каждого загружаемого плагина группы system: onBeforeExtensionBoot -> onAfterExtensionBoot
3. onBeforeExecute
4. onAfterInitialise
5. onAfterRoute
6. onAfterInitialiseDocument
7. Для загружаемого компонента: onBeforeExtensionBoot -> onAfterExtensionBoot
8. Внутренняя логика компонента
9. onAfterDispatch
10. onBeforeRender
11. Внутренняя сборка документа и шаблона
12. onAfterRender
13. При включённом gzip и совместимых настройках PHP: compress() -> onAfterCompress
14. onBeforeRespond
15. onAfterRespond

Что может произойти внутри пункта «внутренняя логика компонента»

Если компонент использует HTML-представление на базе Joomla\CMS\MVC\View\HtmlView, то внутри его display() дополнительно идут:

1. onBeforeDisplay
2. загрузка шаблона представления
3. onAfterDisplay

Но и это ещё не всё. Многие компоненты вызывают свои события до parent::display().

Например, у com_content в представлении статьи порядок такой:

1. для каждого плагина группы content: onBeforeExtensionBoot -> onAfterExtensionBoot
2. onContentPrepare
3. onContentAfterTitle
4. onContentBeforeDisplay
5. onContentAfterDisplay
6. onBeforeDisplay
7. onAfterDisplay

У категорий и тегов логика похожая, но события onContentPrepare, onContentAfterTitle, onContentBeforeDisplay, onContentAfterDisplay могут вызываться по каждому элементу списка, а не один раз на страницу.

Что может произойти внутри пункта «внутренняя сборка документа и шаблона»

Вот здесь порядок уже зависит от шаблона.

Если шаблон первым делом выводит <head>, то раньше всего сработает onBeforeCompileHead. Если шаблон затем выводит позиции модулей, то для первой же позиции Joomla запустит такую ветку:

1. onPrepareModuleList
2. onAfterModuleList
3. onAfterCleanModuleList
4. для каждого загружаемого модуля: onBeforeExtensionBoot -> onAfterExtensionBoot
5. для каждого модуля: onRenderModule
6. внутренняя логика модуля
7. для каждого модуля: onAfterRenderModule
8. после завершения всей позиции: onAfterRenderModules

При этом внутренняя логика конкретного модуля тоже может загрузить свои плагины и вызвать свои события. Пример из ядра: mod_articles_news внутри вывода модуля вызывает:

1. onContentPrepare
2. onContentAfterTitle
3. onContentBeforeDisplay
4. onContentAfterDisplay

То есть в одной HTML-странице события content могут сработать:

• в компоненте;
• в одном или нескольких модулях;
• в произвольном порядке относительно позиций модулей, потому что это уже зависит от шаблона.

Полный порядок триггеров плагинов для HTML-страницы в админке Joomla

Базовый порядок почти тот же:

1. для плагинов behaviour: onBeforeExtensionBoot -> onAfterExtensionBoot
2. для плагинов system: onBeforeExtensionBoot -> onAfterExtensionBoot
3. onBeforeExecute
4. onAfterInitialise
5. onAfterRoute
6. onAfterInitialiseDocument
7. для компонента: onBeforeExtensionBoot -> onAfterExtensionBoot
8. внутренняя логика компонента и представления
9. onAfterDispatch
10. onBeforeRender
11. события головы страницы, модулей и меню в зависимости от шаблона
12. onAfterRender
13. при включённом gzip и совместимых настройках PHP: compress() -> onAfterCompress
14. onBeforeRespond
15. onAfterRespond

Но в административной части есть ещё несколько условных точек, которые часто забывают.

Если строится меню для модулей меню в панели администратора Joomla, то во время обработки узлов меню могут вызываться onPreprocessMenuItems. Причём это событие может пройти несколько раз, по уровням дерева. Контексты в ядре com_menus.administrator.module и administrator.module.mod_submenu.

Если открыт список пунктов меню в com_menus, Перед выводом представления Items вызывается onBeforeRenderMenuItems. Если модель собирает типы меню дополнительно может вызваться onAfterGetMenuTypeOptions. То есть для административной части полная хронология часто содержит не только системные и модульные события, но и отдельные меню-события внутри конкретных экранов.

Полный порядок для API-запроса

У API жизненный цикл другой, и это важно.

Базовая последовательность

1. Для плагинов behaviour: onBeforeExtensionBoot -> onAfterExtensionBoot
2. Для плагинов system: onBeforeExtensionBoot -> onAfterExtensionBoot
3. onBeforeExecute
4. onAfterInitialise
5. Для плагинов webservices: onBeforeExtensionBoot -> onAfterExtensionBoot
6. onBeforeApiRoute
7. разбор маршрута API
8. onAfterApiRoute
9. onAfterInitialiseDocument
10. Для компонента API: onBeforeExtensionBoot -> onAfterExtensionBoot
11. логика контроллера, модели и представления API
12. onAfterDispatch
13. render() через переопределённый ApiApplication::render()
14. при включённом gzip и совместимых настройках PHP: compress() -> onAfterCompress
15. onBeforeRespond
16. onAfterRespond

Чего здесь обычно нет

В обычном API-запросе через ApiApplication нет общего HTML-цикла:

• нет onBeforeRender из CMSApplication::render();
• нет onAfterRender;
• нет onBeforeCompileHead;
• нет модульных событий формирования вывода.

Причина простая: ApiApplication переопределяет render() и не использует HTML-сборку документа.

Какие API-события добавляются внутри представления и сериализации

Если ответ строится через JsonApiView и сериализатор Joomla, дополнительно могут идти:

1. onApiGetFields
2. onGetApiAttributes
3. onGetApiRelation

Это уже не системная часть жизненного цикла приложения, а события слоя сериализации API.

Хронология при открытии и отправке формы Joomla

Открытие формы редактирования

Типовой порядок:

1. общий цикл приложения до onAfterRoute
2. загрузка компонента
3. onContentPrepareData
4. onContentPrepareForm
5. onBeforeDisplay
6. onAfterDisplay
7. onAfterDispatch
8. дальше общая HTML-сборка страницы

Отправка формы и сохранение записи

Типовой порядок:

1. общий цикл приложения до маршрута и диспетчеризации
2. onContentNormaliseRequestData
3. onContentBeforeValidateData
4. onTableBeforeLoad и onTableAfterLoad, если запись не новая
5. onTableBeforeBind
6. onTableAfterBind
7. onTableCheck
8. onContentBeforeSave
9. onTableBeforeStore
10. onTableAfterStore
11. onContentCleanCache
12. onContentAfterSave
13. обычное завершение запроса через onBeforeRespond и onAfterRespond

Если это удаление:

1. onTableBeforeLoad
2. onTableAfterLoad
3. onContentBeforeDelete
4. onTableBeforeDelete
5. onTableAfterDelete
6. onContentAfterDelete
7. onContentCleanCache

Если это смена состояния (опубликовано, не опубликовано, в архиве, в корзине):

1. onContentBeforeChangeState
2. onTableBeforePublish
3. onTableAfterPublish
4. onContentChangeState
5. onContentCleanCache

Хронология триггеров плагинов Joomla для входа, выхода и восстановления доступа пользователя

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

Вход пользователя

1. для плагинов user: onBeforeExtensionBoot -> onAfterExtensionBoot
2. onUserAuthenticate
3. onUserAuthorisation
4. при отказе: onUserAuthorisationFailure
5. при продолжении входа: onUserLogin
6. при успехе: onUserAfterLogin
7. при неудаче: onUserLoginFailure

Выход пользователя

1. для плагинов user: onBeforeExtensionBoot -> onAfterExtensionBoot
2. onUserLogout
3. при успехе: onUserAfterLogout
4. при неудаче: onUserLogoutFailure

Напоминание логина пользователя

onUserAfterRemind - Вызывается при отправке формы "забыли логин" в com_users Joomla.

Запрос на сброс пароля

События вызываются при отправке формы "забыли пароль" в com_users Joomla:

1. onUserBeforeResetRequest
2. сохранение пользователя (там свои события onUserAfterSave и т.д.)
3. onUserAfterResetRequest

Завершение сброса пароля

1. onUserBeforeResetComplete
2. сохранение пользователя
3. onUserAfterResetComplete

Хронология установки расширения Joomla через штатный установщик

Если запрос идёт через стандартный установщик Joomla, то внутри него порядок событий такой:

1. для плагинов группы installer: onBeforeExtensionBoot -> onAfterExtensionBoot
2. onInstallerBeforeInstallation
3. при скачивании пакета по url адресу с сайта разработчика: onInstallerBeforePackageDownload
4. onInstallerBeforeInstaller
5. для плагинов extension: onBeforeExtensionBoot -> onAfterExtensionBoot
6. onExtensionBeforeInstall
7. установка расширения
8. onExtensionAfterInstall
9. onInstallerAfterInstaller

Для обновления:

1. onInstallerBeforePackageDownload, если пакет нужно скачать
2. onExtensionBeforeUpdate
3. обновление
4. onExtensionAfterUpdate

Для удаления:

1. onExtensionBeforeUninstall
2. удаление
3. onExtensionAfterUninstall

Карта уровней событий Joomla

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

Технически часть этих событий вызывается из трейтов или базовых классов, но для выбора точки вмешательства полезнее мыслить уровнем жизненного цикла. Например, onBeforeExtensionBoot относится к загрузке расширения, onTableBeforeStore — к уровню таблицы, а onContentBeforeSave — к уровню модели и бизнес-правил компонента.

Аварийная ветка

Если в основном цикле до отправки ответа вылетает исключение, CMSApplication::execute() вызывает onError. После этого управление передаётся обработчику исключений. Это не штатная ветка, но это тоже часть хронологии запроса.

Как в Joomla 6 устроены триггеры плагинов

Как плагины загружаются

Базовый механизм находится в libraries/src/Plugin/PluginHelper.php.

Когда ядро вызывает PluginHelper::importPlugin('system') или PluginHelper::importPlugin('content'), происходит следующее:

1. из таблицы #__extensions выбираются только включённые плагины;
2. выборка сортируется по полю ordering;
3. плагин загружается и создаётся;
4. его обработчики регистрируются в диспетчере событий.

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

если приоритет слушателей не задан явно, раньше будет вызван тот плагин, который раньше загружен, а загружается он по ordering.

Как задаётся порядок вызова

В Joomla 6 работают сразу два слоя порядка.

Порядок загрузки плагинов группы

Он определяется ordering в таблице расширений.

Приоритет слушателя

Если плагин реализует SubscriberInterface, он может вернуть карту событий из getSubscribedEvents() и указать приоритет:

<?php

namespace Acme\Plugin\System\Example\Extension;

use Joomla\Event\Priority;
use Joomla\Event\SubscriberInterface;

final class Example implements SubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            'onAfterRoute'  => ['onAfterRoute', Priority::HIGH],
            'onAfterRender' => ['onAfterRender', Priority::LOW],
        ];
    }
}

Что это значит для разработчика:

• Priority::HIGH — выполнить раньше большинства;
• Priority::NORMAL — обычный порядок;
• Priority::LOW — выполнить ближе к концу.

Если у нескольких обработчиков одинаковый приоритет, сохранится порядок их регистрации, то есть учитывается обычно снова ordering.

Какой объект приходит в обработчик

В Joomla 6 ядро почти везде передаёт не россыпь позиционных аргументов, а объект события $event.

Пример:

<?php

namespace Acme\Plugin\System\Example\Extension;

use Joomla\CMS\Event\Application\AfterRouteEvent;

final class Example
{
    public function onAfterRoute(AfterRouteEvent $event): void
    {
        $app = $event->getApplication();
    }
}

Старый стиль с методами вроде onContentPrepare($context, &$item, &$params, $page = 0) ещё поддерживается через прослойку совместимости, но это уже устаревающий путь. Поэтому разработчикам рекомендуется провести рефакторинг своих плагинов и поднимать им потихоньку системные требования.

Что в аргументах можно менять

Это самая важная часть для разработчика плагинов.

1. Можно менять переданный объект

Если событие несёт объект, Joomla потом использует этот же объект дальше по цепочке.

Чаще всего это:

• приложение;
• документ;
• форма;
• таблица;
• роутер;
• объект материала / контакта / товара и т.д.;
• объект ответа аутентификации.

Именно поэтому формально неизменяемое событие всё равно позволяет менять поведение ядра: вы меняете не сам контейнер события, а состояние объекта внутри него.

2. Для массивов и строк ищите update*()

Во многих типизированных событиях есть специальные методы:

• updateData();
• updateAttributes();
• updateContent();
• updateModules();
• updateUrl();
• updateHeaders().

Если они есть, пользоваться нужно именно ими.

3. Для собираемого результата используется result

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

Типичные случаи:

• onContentAfterTitle, onContentBeforeDisplay, onContentAfterDisplay собирают строки;
• onContentBeforeSave, onUserLogin, onUserLogout собирают логические значения;
• наличие хотя бы одного false часто останавливает дальнейшее действие ядра.

4. Не рассчитывайте на произвольный setArgument()

Большая часть событий ядра наследуется от AbstractImmutableEvent. Это значит:

• произвольная замена аргументов запрещена;
• менять нужно объект внутри аргумента или использовать предусмотренный update*();
• старые трюки с прямой подменой аргументов надо считать устаревшими.

Быстрое правило выбора точки вмешательства

Если нужно:

Основные группы событий и реальные точки вызова

Системные события приложения

События вывода материала

Главная точка для статьи: components/com_content/src/View/Article/HtmlView.php::display().

Порядок там такой:

1. onContentPrepare
2. onContentAfterTitle
3. onContentBeforeDisplay
4. вывод основного содержимого материала
5. onContentAfterDisplay

Общий набор аргументов:

• context — строка вида com_content.article;
• subject — объект материала;
• params — параметры;
• page — номер страницы или смещение.

Например, если вам нужно:

• изменить сам текст статьи, используйте onContentPrepare;
• добавить отдельный HTML-блок до или после текста, используйте result-события;
• трогать поля записи, категории, изображения и другие свойства материала, меняйте объект subject.

События подготовки формы и данных

Эта группа отвечает не за показ страницы как таковой, а за подготовку формы редактирования и начальных данных.

Важно понимать, что при открытии формы обычно сначала компонент вызывает onContentPrepareData, потом строит XML-форму и вызывает onContentPrepareForm. А при отправке формы в FormController::save() порядок такой:

1. строится объект формы;
2. вызывается onContentNormaliseRequestData;
3. вызывается onContentBeforeValidateData;
4. форма фильтрует и проверяет данные;
5. затем уже вызывается сохранение модели.

Это очень полезное разделение:

• onContentNormaliseRequestData — для приведения сырых данных к нужному виду;
• onContentBeforeValidateData — для правки данных прямо перед правилами формы;
• onContentPrepareForm — для изменения самой формы, а не значений.

События сохранения и удаления на уровне модели

Основная логика находится в libraries/src/MVC/Model/AdminModel.php.

Порядок при сохранении записи

Если запись уже существует, типовой путь такой:

1. onTableBeforeLoad
2. Table::load()
3. onTableAfterLoad
4. onTableBeforeBind
5. Table::bind()
6. onTableAfterBind
7. prepareTable()
8. Table::check(), внутри базовой реализации — onTableCheck
9. onContentBeforeSave
10. Table::store(), внутри него — onTableBeforeStore и onTableAfterStore
11. onContentCleanCache
12. onContentAfterSave

Ключевой нюанс:

к моменту onContentBeforeSave объект Table уже связан с входными данными и уже прошёл check().

То есть:

• для работы с ещё не связанными данными лучше перехватывать форму и валидацию;
• для работы с итоговой строкой записи лучше брать onContentBeforeSave или onTableBeforeStore.

Порядок при удалении записи

В AdminModel::delete():

1. onTableBeforeLoad
2. Table::load()
3. onTableAfterLoad
4. onContentBeforeDelete
5. onTableBeforeDelete
6. Table::delete()
7. onTableAfterDelete
8. onContentAfterDelete
9. onContentCleanCache

Порядок при смене состояния

В AdminModel::publish():

1. onContentBeforeChangeState
2. onTableBeforePublish
3. Table::publish()
4. onTableAfterPublish
5. onContentChangeState
6. onContentCleanCache

Основные события модели, наследующей AdminModel

События таблиц (классы Table) Joomla

Классы Table нужны для работы с базой данных. Классы Table в Joomla описывают строку / запись в базы данных как объект: загружают запись, связывают входные данные с полями, проверяют, сохраняют, удаляют и меняют состояние. Они нужны как низкоуровневый слой работы с БД под моделями, чтобы компоненты не писали однотипный SQL для CRUD-операций вручную. Самый низкий уровень находится в libraries/src/Table/Table.php и libraries/src/Table/Nested.php.

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

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

При работе с событиями Joomla Table:

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

События модулей

Эта группа событий для плагинов живёт в libraries/src/Helper/ModuleHelper.php и libraries/src/Document/Renderer/Html/ModulesRenderer.php.

Порядок на уровне списка модулей:

1. onPrepareModuleList
2. если событие не дало свой список, Joomla строит список сама
3. onAfterModuleList
4. Joomla чистит список от дублей и недопустимых элементов
5. onAfterCleanModuleList

Порядок на уровне отдельного модуля:

1. onRenderModule
2. отрисовка модуля
3. onAfterRenderModule

Порядок на уровне позиции:

1. все модули позиции отрисованы
2. onAfterRenderModules

События пользователей и аутентификации

Логика раскидана по:

• libraries/src/Authentication/Authentication.php;
• libraries/src/Application/CMSApplication.php;
• libraries/src/User/User.php.

Порядок при входе пользователя

1. onUserAuthenticate
2. onUserAuthorisation
3. при отказе onUserAuthorisationFailure
4. onUserLogin
5. при успехе onUserAfterLogin
6. при неудаче onUserLoginFailure

Порядок при выходе

1. onUserLogout
2. при успехе onUserAfterLogout
3. при неудаче onUserLogoutFailure

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

В User::save():

1. onUserBeforeSave
2. запись в таблицу пользователя
3. onUserAfterSave

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

В User::delete():

1. onUserBeforeDelete
2. удаление из таблицы
3. onUserAfterDelete

Здесь есть принципиальное отличие от событий контента:

onUserAuthenticate и onUserAuthorisation работают с объектом AuthenticationResponse, то есть меняют не HTML и не таблицу, а состояние решения о входе.

События установки и обновления расширений

Эта группа особенно важна для систем сопровождения, зеркал, внутренних каталогов расширений и нестандартной доставки пакетов расширений Joomla.

Вместо заключения

В Joomla 6+ система плагинов стала строже и понятнее, чем в старых Joomla 2.5 / Joomla 3:

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

Именно поэтому хорошая разработка под Joomla начинается не с вопроса «какой есть триггер», а с вопроса «на какой стадии жизненного цикла приложения Joomla мне действительно нужно вмешаться».