Как работет MODx: через какие этапы проходит обработка запроса до выдачи контента клиенту.

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

Автор материала

Артем Зернов. Веб-разработчик, создатель проекта Лектория, эксперт MODX Revolution, директор веб-студии OpenColour. Youtube-канал OpenModx.

154
8 минут на прочтение
Теги по этой теме:

Как ведет себя обычное приложение на MODx Revolution

Любой сайт на MODx по-умолчанию имеет несколько различных точек входа. Под точкой входа подразумевается конечный php-скрипт, к которому обращается браузер через веб-сервер (nginx или apache).

CMS/CMF?

MODx не является только лишь системой управления контентом сайта (CMS). MODx представляет из себя также и довольно мощный и гибкий фреймворк для построения веб-приложений.

Прежде, чем приступить к дальнейшему изучению этого материала, для исключения путаницы в терминах, давайте условимся, что фронтэндом (frontend) мы будем называть страницы сайта, не относящиеся к админке, а бэкендом (backend) – страницы админки сайта.

Для тех, кто предпочитает смотреть, у нас есть видео от автора данной статьи.

Точка входа #1: основной файл index.php

Данный файл лежит в корневой папке сайта.

Цель скрипта: принимать на себя запросы, образующиеся при попытке обращения к какой-либо странице сайта (исключая страницы админки, или, как его еще называют, менеджера), обрабатывает запрос, находить нужную страницу в списке ресурсов (modResource и дочерние классы), обрабатывать контент, запускать необходимые плагины, вызывать различные компоненты и в итоге отдать обработанный контент в браузер, параллельно генерируя необходимые HTTP-заголовки.

По-умолчанию путь к этому файлу:

/путь/до/корневой папки/сайта/index.php

Точка входа #2: файл index.php админки

Данный файл очень похож на предыдущий index.php, но отличается тем, что инициализирует другой контекст (mgr) и ряд других классов, предназначенных для работы с админкой. Например, вместо класса modResponse и modRequest инициализируются классы modManagerResponse и modManagerRequest.

Цель данного скрипта схожа с целью предыдущего index.php. Разница в том, что в отличие от Frontend, в админке нам не нужно находить определенную страницу в базе, чтобы выдать ее контент. В админке данный скрипт находит необходимый контроллер (modManagerController) и запускает его, а контроллер, в свою очередь уже выдает в браузер запрашиваемый контент, представляющий из себя набор подключенных javascript-файлов, генерирующих интерфейс на ExtJS.

Путь к даному файлу по-умолчанию:

/путь/до/корневой папки/сайта/manager/index.php

Точка входа #3: файл index.php для коннекторов

Есть еще одна точка входа по-умолчанию – это точка входа для коннекторов.

Коннекторы (connectors) в modx – это скрипты, запускаемые через вышеупомянутую точку входа и принимающие на себя ajax-запросы из различных элементов интерфейса админки. Но при определенных условиях они также могут использоваться и для обработки ajax-запросов из frontend-части сайта.

Цель коннектора: принять запрос, проверить, является ли данный запрос авторизованным, запустить необходимый процессор (modProcessor) и отдать контент клиенту. Как правило, контент отдается в формате JSON.

Путь к даному файлу по-умолчанию:

/путь/до/корневой папки/сайта/connectors/index.php

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

Дальнейшее рассмотрение жизненного цикла приложения MODx мы проведем на примере основного index.php файла, который лежит в корневой папке сайта.

Механизм обработки запроса

Первичная инициализация

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

Это происходит в файле index.php

Инициализация контекста web

Контекст web – это контекст по-умолчанию, в котором хранятся ресурсы (или другими словами, страницы) сайта. Прежде, чем работать с ним, его необходимо проинициализировать.

Инициализация контекста включает в себя:

  • Подключение кэш-менеджера (modCacheManager)
  • Загрузку конфигурации контекста (набор различных системных переменных, переменных контекста и прочих общих настроек, доступных для различных компонентов)
  • Подключение глобальных компонентов (extension packages)
  • Инциализацию механизмов контроля сессий (sessions)
  • Инициализацию механизмов обработки ошибок (modErrorHandler)
  • Инициализацию языковых механизмов
  • Инициализацию механизмов регистра (modRegistry)
  • Установку общедоступных плейсхолдеров
  • Генерацию события OnMODXInit.

Это происходит в файле core/model/modx/modx.class.php

Что такое контекст?

В modx контекст – по-умолчанию это своего рода объединение ресурсов или страниц по смысловому назначению. Например, по принадлежности их к backend или frontend части сайта, по принадлежности их к авторизованным и неавторизованным пользователям и т.д.

Обработка запроса

После инициализации запускается процесс обработки запроса.

Данный процесс можно разделить на 2 основные части:

  1. Анализ самого запроса
  2. Генерация и выдача контента

Это происходит в файле core/model/modx/modx.class.php

API режим

Если вы используете modx как фреймворк и подключаете корневой файл index.php в другом скрипте, то вам необходимо определить константу MODX_API_MODE. Тогда modx не будет выполнять обработку запроса и поиск ресурса.

Анализ запроса и поиск ресурса

Для того, чтобы понять, какой именно ресурс просит от modx клиент, обратившись к конкретному URL, modx запускает метод handleRequest соответствующего класса.

Как было упомянуто выше, в MODx есть по-умолчанию три точки входа. В зависимости от того, какая точка входа используется, для обработки запроса используются три разных класса: modRequest, modConnectorRequest и modManagerRequest.

Для frontend используется метод modRequest::handleRequest. Данный метод анализирует URL, выделяя из него необходимые части, по которым можно однозначно найти ресурс в базе данных, а также обращается к системным настройкам modx для определения метода поиска ресурса.

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

Это происходит в файле core/model/modx/modrequest.class.php

Генерация контента

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

Весь процесс обработки и генерации контента можно поделить на несколько этапов:

  1. Определение типа содержимого страницы
  2. Подготовка содержимого страницы
  3. Подключение внедряемого кода
  4. Вставка специальных тегов modx
  5. Генерация заголовков
  6. Выдача контента клиенту

Это происходит в файле core/model/modx/modresponse.class.php

Как и с классом запроса, в зависимости от используемой точки входа, используются различные классы для ответа: modResponse, modConnectorResponse и modManagerResponse

Подготовка содержимого страницы

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

Содержимое страницы в MODx состоит из кода, который генерируется шестью различными сущностями:

  1. Шаблоном страницы
  2. Полями ресурса (как основными вроде pagetitle, content, так и дополнительными TV-полями)
  3. Плейсхолдерами (например при обращении к системной настройке или настройке контекста)
  4. Вызываемыми сниппетами
  5. Вставляемыми чанками
  6. Плагинами

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

Основная задача данного этапа – это собрать все содержимое страницы таким образом, чтобы все вызовы сниппетов, чанков и ссылок на различные поля были заменены на соответствующие занчения и в итоге у нас остался только html код, в котором нет больше никаких конструкций MODx.

Основная часть процесса подготовки содержимого происходит в файлах core/model/modx/modresponse.class.php и core/model/modx/modresource.class.php

Как вы наверняка догадались, процедура обработки содержимого на объемных страницах может создавать существенную нагрузку на сервер, а также время на такую обработку может быть довольно высоким.

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

Кэш

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

Финальные процессы

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

Мы используем куки на нашем сайте. Продолжая просмотр, вы соглашаетесь с условями пользовательского соглашения Я согласен
Пожалуйста, подождите. Процесс оформления заказа может занимать до 30 секунд.