Хуки и доработки ядра DLE: чек-лист перед продакшеном

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

Сначала определите, что именно вы меняете

У одной задачи в DLE может быть несколько реализаций. Добавить блок в шаблон, перехватить событие через хук и изменить файл ядра — не одно и то же. Чем глубже вмешательство, тем дороже каждое обновление и тем сложнее доказать, что ошибка появилась именно из-за доработки.

Если после обновления вы не можете за несколько минут ответить, какие файлы были изменены и как вернуть предыдущую версию, доработку рано отправлять в продакшен.

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

Чек-лист перед выпуском

1. Зафиксируйте версию и состав изменений

Запишите точную версию DLE, PHP, СУБД, активной темы и установленных дополнений. Для этой проверки используйте проект на DLE 17.3; если у вас другой релиз, не переносите названия хуков и структуру файлов автоматически.

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

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

2. Проверьте источник каждого хука

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

1. Запишите имя точки расширения и файл, где она объявлена или вызывается.
2. Проверьте, какие данные доступны обработчику: объект пользователя, идентификатор новости, запрос, данные формы.
3. Сверьте порядок вызова с тем, что делает ваша функция: до сохранения, после сохранения или только при выводе страницы.
4. Проверьте поведение при пустом значении, ошибке базы и отсутствии авторизации.

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

3. Уберите прямые правки ядра, где это возможно

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

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

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

4. Проверьте входные данные и права

Хук не делает данные безопасными автоматически. Значения из GET, POST, cookie, URL и административных форм нужно проверять по назначению: тип, длину, допустимый набор значений и право текущего пользователя выполнить операцию.

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

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

5. Проверьте кеш, шаблон и режим отладки

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

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

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

6. Прогоните сценарии обновления

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

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

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

Что проверить под нагрузкой

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

Снимите базовые показатели до и после изменения в одинаковых условиях: число одновременных запросов, время ответа, количество SQL-запросов, ошибки PHP, загрузку CPU и памяти. Если измерений нет, не называйте доработку безопасной для нагрузки — сначала соберите их на копии с обезличенными данными.

Отдельно проверьте:

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

Где подход ломается

Хук вызывается не там, где вы ожидали

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

Обновление изменило структуру файла

Прямая вставка после конкретной строки часто исчезает или начинает выполняться дважды после обновления. Храните патч отдельно, сравнивайте файл с чистой версией и после каждого обновления проходите список зависимостей.

Ошибка спрятана кешем

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

Доработка работает только при включённом отладочном режиме

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

Когда что выбирать

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

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

Что делать дальше

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