Обновление DLE без потери доработок: разбор сбоя

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

Что произошло в типовом инциденте

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

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

Резервная копия спасает данные. Только карта доработок помогает понять, что именно восстанавливать после обновления.

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

Где ломается граница между ядром и доработкой

Файлы движка

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

Шаблон и его настройки

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

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

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

Доработка¹ — любое изменение стандартного поведения или файла: от правки шаблона до отдельного модуля, обработчика, SQL-изменения или интеграции с внешним сервисом.

Как восстановить цепочку изменений

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

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

Что сравнивать до и после обновления

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

Почему обычный откат не всегда помогает

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

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

Граничные случаи и цена ошибки

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

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

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

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

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

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

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