Хуки и доработки ядра DLE без проблем после обновления

Почему правка ядра DLE становится проблемой

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

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

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

Сначала определите границу изменения

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

Хук — заранее предусмотренная точка, в которой DLE передаёт управление вашему коду или позволяет изменить результат. Это не универсальный вызов: название, аргументы и момент выполнения зависят от конкретной версии движка.

Четыре вопроса до первой строки кода

• Что именно меняется: HTML, входные данные, запрос к базе, права пользователя или бизнес-правило.
• На каком этапе это должно происходить: до проверки, после проверки, до записи или после вывода.
• Можно ли решить задачу настройкой, шаблоном или штатным плагином.
• Как изменение будет отключаться, обновляться и откатываться без доступа к редактору файлов.

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

Как выбирать между шаблоном, хуком и правкой ядра

Шаблон: когда PHP не нужен

Изменение заголовка, карточки новости, списка полей, кнопки или визуального состояния обычно относится к шаблону. Храните копию рабочего шаблона отдельно от файлов движка и фиксируйте, какие переменные DLE доступны в этом месте. Не вставляйте в шаблон серверную логику, SQL-запросы и обработку пользовательского ввода: так разметка быстро превращается в неотлаживаемый PHP-файл.

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

Хук: когда нужно вмешаться в существующий процесс

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

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

Обработчик должен быть коротким. В нём не стоит запускать тяжёлый запрос, отправлять внешний HTTP-запрос без тайм-аута или менять глобальные переменные DLE. Сложную работу вынесите в отдельный класс или сервис, а в хуке оставьте проверку условий и передачу данных.

Плагин или отдельный модуль: когда логика разрастается

Если изменение имеет собственные настройки, таблицы, права доступа, журналирование и экран управления, один обработчик быстро станет техническим долгом. Соберите функциональность в отдельный компонент: код, конфигурация, SQL-изменения, шаблоны и инструкция по установке должны лежать вместе.

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

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

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

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

Рабочий порядок внедрения

1. Скопируйте сайт и базу. Тестовая копия должна быть доступна по отдельному адресу, а резервная копия базы — проверена восстановлением. Просто наличие архива в панели хостинга не доказывает, что его можно развернуть.
2. Зафиксируйте версию DLE и PHP. Запишите точные значения, активный шаблон, используемую кодировку и список сторонних модулей. Проверка: другой разработчик может повторить окружение хотя бы по этой записи.
3. Опишите вход и выход. Укажите, кто запускает сценарий, какие поля приходят, что должно записаться и какую ошибку должен увидеть пользователь. Проверка: есть минимум один успешный и три ошибочных сценария.
4. Найдите штатную точку расширения. Сверьте документацию и исходный код конкретной версии. Проверка: вы знаете имя события, аргументы, ожидаемый результат и порядок вызова.
5. Вынесите логику из ядра. Код храните в отдельном компоненте или файле, а подключение к DLE делайте через поддерживаемый механизм. Проверка: отключение компонента возвращает сайт к прежнему поведению.
6. Проверьте права и входные данные. Ограничьте доступ по роли, проверяйте обязательные поля и не доверяйте значениям из формы, cookie или URL. Проверка: запрос без авторизации и запрос с изменённым идентификатором не дают доступ к чужим данным.
7. Протестируйте обновление. Разверните новую версию DLE на копии и примените компонент или патч. Проверка: сайт открывает главную страницу, авторизация, публикация материала, поиск и нужный сценарий работают без предупреждений PHP.

Что чаще всего ломают в доработках DLE

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

Как понять, что хук выбран неправильно

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

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

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

У безопасной доработки есть не только стоимость разработки, но и стоимость сопровождения. Шаблон обычно требует визуальной проверки. Хук — проверки совместимости аргументов и порядка вызова. Отдельный модуль — миграций и процедуры удаления. Правка ядра добавляет ручное слияние при каждом обновлении DLE.

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

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

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

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

Сноска. Патч — файл с формальным описанием изменений, который применяют к исходному коду автоматически или полуавтоматически. В отличие от ручной правки, он показывает, что именно изменилось и на каком месте новая версия перестала совпадать со старой.