Как обновить DLE и не потерять доработки

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

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

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

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

В DLE обычно встречаются четыре источника изменений:

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

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

Без журнала доработок обновление — это не установка новой версии, а угадывание, какие функции сайт потеряет.

Сначала соберите карту проекта

Материал рассчитан на DLE 18.x. Если сайт обновляется с 17.x или более старой ветки, сначала прочитайте официальную инструкцию именно для вашей пары версий: между соседними релизами и крупными обновлениями меняются состав файлов, требования к PHP и процедура миграции базы.

До начала работ зафиксируйте состояние сайта в репозитории или хотя бы в двух отдельных архивах: файлы и база данных. Резервная копия должна быть проверяемой. Архив, который никто не разворачивал, не считается рабочим бэкапом.

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

Что именно ревьюить перед переносом

Правки в ядре

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

Особенно внимательно проверяйте места, где код напрямую меняет SQL-запросы, фильтрует входные параметры, формирует HTML или зависит от конкретного имени переменной DLE. Такие участки чаще всего конфликтуют с обновлённой логикой CMS.

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

Шаблоны и клиентский код

Шаблон — не безопасная зона по умолчанию. Новая версия может добавить обязательный тег, изменить набор переменных или поменять ожидаемую структуру формы. Сравнивайте не только визуальный результат, но и HTML-атрибуты, скрытые поля, классы, обработчики JavaScript и сообщения об ошибках.

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

Модули и внешние интеграции

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

Интеграции с оплатой, почтой, CRM и рекламными системами тестируйте отдельно. Успешная загрузка страницы не доказывает, что письмо отправляется, заказ уходит в CRM или webhook принимается.

Три стратегии переноса доработок

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

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

Как проводить рефакторинг до обновления

Не пытайтесь одновременно заменить DLE, PHP, тему и все модули. Иначе при ошибке вы не поймёте, какая перемена её вызвала. Рабочая последовательность выглядит так:

1. Заморозьте функциональный состав. Не добавляйте новые возможности в ту же ветку, где готовится обновление. Иначе ревью будет сравнивать старую версию с движущейся целью.
2. Разделите большие правки. Один коммит должен менять одну причину: например, перенос формы, исправление фильтра или обновление интеграции. Так проще откатить только проблемный фрагмент.
3. Уберите дублирование. Если одна и та же проверка пользователя, преобразование даты или сборка URL копируется в нескольких местах, вынесите её в единый слой. Это уменьшает число конфликтов при следующем обновлении.
4. Добавьте журнал решений. Для спорных изменений запишите причину, дату, автора и ожидаемое поведение. Через год такой комментарий полезнее, чем попытка угадать назначение старой строки.
5. Проверьте отказоустойчивость. Внешний сервис может вернуть ошибку, пользователь — отправить пустое поле, а база — не принять значение. Сайт должен показать понятное сообщение и не раскрыть внутренний путь к файлу или текст SQL-ошибки.

Рефакторинг не должен превращаться в переписывание всей CMS. Его задача — уменьшить площадь конфликта между вашим кодом и обновлением DLE.

Тестовый стенд и переключение

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

Проверяйте сайт в таком порядке:

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

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

Что ломается чаще всего

Новая версия перезаписала ручную правку

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

Страница открывается, но функция не работает

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

После обновления пропали данные

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

Сайт показывает старый дизайн

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

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

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

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

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