Обновление в DLE: рабочие приёмы без простоя сайта

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

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

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

• Запишите текущую версию DLE, PHP, MySQL или MariaDB и активного шаблона.
• Сохраните полный архив файлов сайта, включая engine/data/config.php, каталог templates, загрузки и пользовательские изображения.
• Сделайте отдельный дамп базы данных. Архив файлов не заменяет резервную копию базы.
• Составьте список сторонних модулей, плагинов и ручных изменений в системных файлах.
• Проверьте свободное место на диске и возможность временно включить техническую страницу или ограничить доступ к сайту.

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

Главный вопрос перед обновлением DLE — не «куда загрузить новые файлы», а «какие изменения на сайте нельзя потерять».

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

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

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

Обновление на копии сайта

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

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

Стенд для сайта с изменённым шаблоном

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

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

Чистая установка

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

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

Порядок обновления на практике

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

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

Шаблон выглядит иначе

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

Админпанель открывается, но функция модуля исчезла

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

Появились ошибки PHP

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

Сайт показывает старую версию

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

Когда обновление нужно откатить

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

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

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

После обновления поставьте задачу не на «проверить сайт», а на конкретные наблюдения: ошибки PHP, ответы 500 и 502, время открытия админпанели, неудачные отправки форм и рост числа запросов к базе. В течение первых суток сравнивайте эти показатели с обычным уровнем.

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