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

Модуль для DLE, который работает на тестовом сайте, ещё не готов к продакшену. На реальном проекте его могут сломать другой префикс таблиц, включённый кеш, права обычного пользователя, обновление DLE или неожиданный POST-запрос. Ниже — практический чек-лист для ветки DLE 18.x: от фиксации версии до проверки удаления. На полный прогон закладывайте от одного до трёх часов, если есть отдельная копия сайта и базы.
Сначала зафиксируйте окружение
Не проверяйте модуль на абстрактном «DLE последней версии». Запишите конкретный релиз CMS, версию PHP, тип базы данных и состав подключённых расширений. Поведение ядра, шаблонов и хуков может отличаться между минорными версиями.
- версия DLE из панели управления;
- версия PHP и включённые расширения;
- версия MySQL или MariaDB;
- активный шаблон и его дочерние шаблоны, если они используются;
- режим ЧПУ, кеширование и сжатие HTML;
- префикс таблиц базы данных;
- список других модулей и плагинов, которые меняют те же страницы.
Скопируйте эти значения в README модуля или внутреннюю задачу. Отдельно укажите, на какой версии DLE вы тестировали релиз: «DLE 18.1» или другой фактический минорный выпуск, а не только «DLE 18.x». Если точный релиз неизвестен, его нужно определить до тестирования.
Главный тест модуля — не «страница открылась», а «модуль переживает отказ, повторный запрос, другой аккаунт и удаление без повреждения сайта».
Выберите способ интеграции
До проверки кода решите, что именно вы выпускаете. В DLE внешний модуль, административное расширение и интеграция через плагины имеют разные точки отказа. Не смешивайте файлы, которые относятся к разным механизмам.
| Вариант | Когда подходит | Основной риск | Что проверить |
|---|---|---|---|
| Публичный внешний модуль | Нужна отдельная страница или действие для посетителя | Доступ без авторизации, прямые запросы и обход интерфейса | URL модуля, права групп, GET и POST, кеш, шаблон |
| Административная часть | Настройки и операции доступны только редакторам или администраторам | Слишком широкие права и опасные действия без подтверждения | Группы пользователей, CSRF-защита, журналирование, удаление |
| Интеграция с существующим экраном | Модуль меняет вывод новости, профиля или другого раздела | Конфликт с шаблоном, другим расширением или обновлением DLE | Порядок вызовов, повторное подключение, кеш и резервный вывод |
Если модуль можно сделать обычным расширением без изменения файлов ядра, выбирайте этот путь. Правки ядра дешевле только на старте: после обновления DLE их придётся восстанавливать и повторно проверять.
Чек-лист перед установкой
1. Упаковка и структура файлов
Откройте архив как обычный пользователь, а не как автор разработки. Внутри не должно быть дампов базы, временных файлов, локальных конфигураций, паролей, токенов, папок IDE и резервных копий с расширениями вроде .bak или .old.
- имя каталога и файлов совпадает с инструкцией;
- пути не зависят от регистра букв;
- в архиве нет лишнего уровня вложенности;
- права на записываемые каталоги описаны отдельно;
- есть инструкция установки и удаления;
- указаны версия DLE, PHP и совместимость с шаблоном.
Проверка: распакуйте архив во временный каталог и найдите все файлы конфигурации, SQL и подключения. Каждый из них должен быть объясним.
2. Установка на чистую копию
Разверните резервную копию сайта и базы на отдельном домене или локальном стенде. Не устанавливайте первый релиз поверх боевого сайта: ошибка в SQL или правах может проявиться до того, как вы успеете сделать откат.
- Создайте резервные копии. Сохраните файлы сайта и полный дамп базы. Проверьте, что дамп действительно восстанавливается, а не просто появился в каталоге. Проверка: тестовая копия открывает главную страницу и панель управления.
- Установите модуль по инструкции. Не заменяйте файлы ядра, если это не указано явно и не описан способ возврата. Проверка: в журнале сервера нет фатальной ошибки, а панель управления открывается.
- Проверьте SQL. Таблицы, индексы и настройки должны создаваться с учётом префикса базы. Не рассчитывайте на имя таблицы вроде
dle_module_items, если префикс сайта может быть другим. Проверка: модуль работает на копии базы с изменённым префиксом. - Повторите установку. Если повторная установка создаёт дубликаты, падает с ошибкой или портит настройки, процедуру нельзя считать готовой. Проверка: после второй попытки остаётся один набор таблиц и настроек.
- Удалите модуль. Удаление должно вернуть сайт в исходное состояние или честно перечислить, что останется в базе. Проверка: страницы, которые не относятся к модулю, открываются так же, как до установки.
3. Запросы, входные данные и права
Проверьте не только форму в браузере. Отправьте запрос вручную через инструменты разработчика или HTTP-клиент с пустыми, длинными и неожиданными значениями. Не включайте в этот тест реальные секреты.
- пустая строка и отсутствующий параметр;
- число вместо строки и строка вместо числа;
- слишком длинный текст;
- кавычки, HTML и специальные символы;
- повторная отправка формы;
- POST без ожидаемого токена или с просроченной сессией;
- запрос от гостя, обычного пользователя, редактора и администратора.
Разделяйте проверку входных данных и экранирование вывода. Безопасная строка для SQL не становится автоматически безопасной HTML-строкой, и наоборот. Для каждого действия ответьте на три вопроса: кто может его вызвать, что произойдёт при повторе и можно ли отменить результат.
* Префикс таблиц — часть имени таблицы, которую задают при установке DLE, например условная строка перед названием таблицы. Жёстко зашитое имя без этого префикса ломает модуль на части сайтов.
Что проверить на работающем сайте
Производительность и кеш
Сделайте минимум два прогона: с пустым кешем и с прогретым. Смотрите время ответа, количество SQL-запросов, размер HTML и записи в журнале PHP. Если таких метрик нет, замерьте хотя бы время ответа через панель браузера и серверный access log.
Модуль не должен выполнять тяжёлый запрос на каждой странице, если данные меняются раз в час. Проверьте пагинацию, сортировку и фильтры: запрос без ограничения может быть незаметен на ста записях и стать причиной тайм-аута на реальной базе. Отдельно проверьте страницу без результатов и страницу с большим количеством результатов.
Конфликты и обновление
Включите по очереди активные модули и плагины сайта. Проверяйте не только экран модуля, но и главную, страницу новости, поиск, профиль и административную панель — в зависимости от того, куда он подключается.
После обновления копии DLE до целевой версии повторите установку и основные сценарии. Если расширение зависит от внутреннего файла ядра, класса или переменной, запишите это как риск в README. Такие зависимости нельзя маскировать формулировкой «работает с DLE».
Где подход ломается
- Работает только у администратора. Обычно код проверяли в одной сессии. Создайте отдельные аккаунты для каждой группы и протестируйте прямой URL, а не только видимость кнопки.
- После включения кеша показываются чужие данные. Проверьте, не попадает ли персональный или закрытый результат в общий кеш. Для таких страниц кеширование нужно отключить или разделить по пользователю.
- Ошибка появляется только после второго клика. Ищите неидемпотентное действие: повторная отправка может создавать дубликат, повторно списывать значение или менять статус.
- На одном сервере всё работает, на другом — белая страница. Сравните версию PHP, расширения, права файлов и режим отображения ошибок. Детали ошибки смотрите в журнале, но не выводите стек и пути к файлам посетителю.
- После удаления остаются таблицы и настройки. Это допустимо только при явном предупреждении. Лучше добавить безопасную очистку или отдельную инструкцию по ручному удалению.
Финальная проверка перед релизом
Перед копированием на боевой сайт пройдите список без пропусков:
- зафиксированы версии DLE, PHP и базы;
- есть резервная копия файлов и базы с проверенным восстановлением;
- модуль установлен на чистую копию;
- повторная установка не создаёт дубликаты;
- проверены все группы пользователей;
- POST-действия защищены от подделки и повторной отправки;
- входные данные проверяются, вывод экранируется;
- нет секретов, тестовых URL и отладочного вывода;
- проверены пустые результаты, большие выборки и ошибки базы;
- проверены холодный и прогретый кеш;
- описан откат и удаление;
- есть журнал изменений и список известных ограничений.
Что делать дальше
После релиза поставьте на первые сутки наблюдение за HTTP-ошибками 4xx и 5xx, временем ответа, ошибками PHP и ростом таблиц модуля. Сравните эти показатели с периодом до установки. Если модуль работает с личными данными или изменяет контент, добавьте отдельную проверку журналов и резервного восстановления. Следующий полезный шаг — автоматизировать чистую установку на копию DLE и прогонить хотя бы сценарии входа, создания записи, повторной отправки и удаления.
Тендерный специалист 44-ФЗ / 223-ФЗ: Разбор PDF-документации закупки, поиск «заточек» под поставщика, чек-лист заявки.
Спросить за 20 ₽Источники: Официальная документация DataLife Engine, Официальный сайт разработчика DataLife Engine
Частые вопросы
Нужно ли тестировать модуль на каждой версии DLE?
Можно ли устанавливать модуль сразу на боевой сайт?
Что делать, если после установки появилась белая страница?
Как понять, что модуль безопасен для обычного пользователя?
Что будет, если в базе другой префикс таблиц?
Можно ли оставить отладочный вывод после запуска?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.