Свой модуль для DLE: рабочие приёмы без хрупких правок

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

Сначала выберите границу модуля

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

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

Для небольшого блока обычно важнее сохранить раздельность PHP-логики и шаблона, чем строить сложную архитектуру. Если модуль меняет редактор материалов, админку или обработку запросов, заранее выясните, поддерживает ли ваша версия нужную точку расширения. Не считайте наличие похожего файла в чужой сборке подтверждением стабильного API.

Хороший модуль можно отключить и удалить, не восстанавливая вручную изменённые файлы ядра.

Три подхода к подключению

Способ интеграции выбирают не по привычке, а по цене сопровождения. Для сравнения проверьте каждый вариант на копии сайта с той же версией DLE, что и на проде.

Что не стоит копировать вслепую

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

Разделите запрос, обработку и шаблон

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

1. Проверьте входные параметры. Не доверяйте значениям из адресной строки и формы. Ограничьте допустимый формат и диапазон. Проверка готова, когда пустое или некорректное значение не меняет смысл запроса.
2. Получите только нужные данные. Не выбирайте все поля и все записи, если модулю нужны несколько строк и пара столбцов. Проверка готова, когда пустой результат обрабатывается без предупреждений PHP.
3. Передайте данные в шаблон. Оставьте HTML в шаблоне, а не в строках PHP. Проверка готова, когда текст и разметку можно изменить без переписывания логики запроса.
4. Проверьте вывод. Данные пользователя нельзя выводить как доверенную HTML-разметку. Используйте предусмотренное вашей версией DLE экранирование и проверьте строку с кавычками и символами разметки.

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

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

• Пустой экран или ошибка PHP. Проверьте журнал ошибок, путь подключения и совместимость кода с версией PHP на хостинге. Не скрывайте ошибки на тестовой копии.
• Модуль работает на одной странице, но не на другой. Проверьте, откуда берутся параметры и доступно ли нужное окружение DLE в выбранной точке подключения.
• Вместо текста видны HTML-теги или исполняется разметка. Разделите доверенный шаблон и пользовательские данные; проверьте экранирование вывода.
• После обновления исчез блок. Сравните изменённые файлы с оригиналами новой версии и восстановите подключение через документированную точку расширения, если она есть.

«Работает на моём сайте» — не тест совместимости. Проверьте модуль на чистой копии DLE и отдельно на копии с вашими шаблонами и дополнениями: именно разница между ними обычно показывает, к чему модуль привязан.

Что проверить перед публикацией

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

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

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

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

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