Автообновление плагина положило сайт за пять минут: разбор и предохранители
В 18:06 WordPress сам обновил плагин, в 18:11 сайт перестал открываться. Никто ничего не нажимал. Разбираем по минутам, почему автообновление, которое должно защищать, положило сайт, и что сделать, чтобы у вас такого не случилось.
- Что случилось — Автообновление поставило плагин на несколько поколений новее того, что стоял с 2022 года. Тема сайта опиралась на убранный код — главная упала за пять минут.
- Почему — Три причины сошлись: четыре года без обновлений, тема того же времени и соседний плагин, потерявший настройки. Автообновление ни одной из них не видит.
- Что делать — Заплатки безопасности — автоматически и быстро. Крупные обновления — руками, на копии сайта, с резервной копией. И не держать версии четырёхлетней давности.
В 18:06 WordPress на сайте, который мы обслуживаем, сам обновил плагин. В 18:11 сайт перестал открываться. Никто ничего не нажимал, никто не заходил в админку, не было ни взлома, ни сбоя хостинга. Система просто сделала то, для чего её настроили годы назад, и сделала это безупречно.
Этот разбор — о том, почему автоматическое обновление, которое должно защищать сайт, иногда его кладёт, и что сделать, чтобы у вас такого не случилось. Без теории: всё ниже — хронология одного вечера и одного следующего утра.
Хронология: пять минут от обновления до мёртвого сайта
18:06. WordPress запускает плановое автообновление плагина Elementor — конструктора, на котором собраны все страницы сайта. На сайте стояла версия 3.6.5, выпущенная ещё в 2022 году. Обновление ставит сразу 4.3.5, перескочив через несколько лет изменений.
18:11. Главная страница отдаёт ошибку. Посетители видят белый экран вместо сайта. Редактор в админке не может ни открыть страницу, ни сохранить её.
18:14. В рабочую группу прилетает сообщение: «не сохраняется страница». О том, что сайт лежит целиком, ещё никто не знает.
19:25. Сайт работает. Между этими двумя точками — час разбора, и именно он интересен.
Почему это случилось: три причины, сошедшиеся в одну
1. Версия плагина из 2022 года
Автообновление не обновляло этот плагин четыре года — а потом сработало. Почему именно в тот вечер, неважно: важно, что прыжок с версии 3.6 на 4.3 — это не «заплатка», а смена поколения. Разработчик за это время убрал часть старого кода, который считал устаревшим. Это нормальная практика — но лишь для тех, кто обновляется регулярно и замечает предупреждения по дороге.
2. Тема сайта опиралась на тот же старый код
Тема оформления тоже из 2022 года и тоже не обновлялась. В восьми её блоках использовались функции, которые в новом Elementor исчезли. Тема вызывает функцию — функции нет — PHP останавливает выполнение. Для посетителя это выглядит как пустая страница с ошибкой.
3. Соседний плагин потерял настройки
На сайте стоял ещё один плагин, который скрывает стандартные адреса WordPress от роботов и сканеров. Во время обновления он потерял правило подмены адресов именно для файлов Elementor. Так что даже там, где тема не ломалась, редактор не мог загрузить собственные файлы: сервер отвечал «не найдено».
Автообновление не знает, что ваша тема из 2022 года, что рядом стоит плагин, перехватывающий адреса, и что на этом сайте никто не обновлялся четыре года. Оно знает лишь одно: есть новая версия, и её надо поставить.
Как лечили
- Вернули плагин на 3.6.5 — ту версию, что работала утром. Новую не удалили, а отложили: вернуться к ней можно за минуту, когда тема будет готова.
- Восстановили потерянное правило в плагине, скрывающем адреса.
- Выключили автообновление именно для Elementor. Иначе ночью всё повторилось бы — WordPress не помнит, что в прошлый раз стало хуже.
- Проверили главную и внутренние страницы — открываются, ошибок нет, оформление на месте.
И отдельно сказали владельцу честно: версия 3.6.5 — четырёхлетней давности, держать её долго не стоит. В старых версиях со временем находят уязвимости, и тогда уже не обновляться становится опасно. Самая свежая версия, совместимая с этой темой, — 3.25. Но и тема из 2022 года: рано или поздно она упрётся в это снова. Правильный путь — сделать копию сайта и там спокойно проверить обновление, без риска для рабочего.
Второй звоночек на следующее утро
В 9:49 новое сообщение: «ошибка 503» при сохранении страницы. На первый взгляд — продолжение вчерашнего. На самом деле — другая история, и она тоже поучительна.
Сервер не отказывал. При сохранении падал сам процесс PHP, а браузер показывал это как 503. Страница оказалась очень тяжёлой: 226 блоков, из них 111 картинок. А ограничения PHP на сайте стояли минимальные, из коробки хостинга: 128 МБ памяти и 30 секунд на запрос. Конструктор для нормальной работы требует как минимум 256 МБ и 300 секунд. Сайт годами работал на пределе — и на самой тяжёлой странице этот предел закончился.
Подняли лимиты, перезапустили PHP — не помогло. Журнал показал: память и время тут ни при чём, процесс гибнет на самом сохранении. Причиной оказалась одна из настроек ускорения PHP, известная проблема на этой версии. Выключили — заработало.
Урок тут простой: сбой редко имеет одну причину. Вчерашнее обновление здесь ни при чём, но сайт, который годами живёт на минимальных лимитах, рано или поздно сломается на чём-то другом.
Что делать владельцу сайта
- Узнайте, что у вас обновляется само. В админке WordPress: «Плагины» → колонка «Автообновление». То же для тем. Если вы не знаете ответа — это уже первая проблема.
- Разделите обновления на «безопасности» и «крупные». Мелкие исправления внутри версии (3.25.10 → 3.25.11) можно оставить автоматическими. Переход между крупными версиями (3 → 4) — только руками и только после проверки.
- Проверяйте крупные обновления на копии. Хостинги обычно дают тестовую копию сайта одним нажатием. Обновили там, посмотрели, что ничего не отвалилось, — тогда обновляете рабочий.
- Делайте копию перед каждым обновлением. Не «бэкап есть на хостинге», а копия, с которой вы лично знаете, как восстановиться за десять минут.
- Не держите версии четырёхлетней давности. Чем дольше не обновляетесь, тем болезненнее будет прыжок и тем больше уязвимостей накапливается. Плановое обновление раз в месяц дешевле одной ночи без сайта.
- Имейте того, кто увидит за пять минут. Сайт лежал с 18:11, а сообщение пришло в 18:14 — и то не о сайте, а о редакторе. Без мониторинга владелец узнаёт о мёртвом сайте от клиента, который не смог заказать.
Парадокс: не обновляться — тоже опасно
Может показаться, что вывод — «выключите автообновление и живите спокойно». Нет. Недавно мы писали о критических уязвимостях PHP, где единственная защита — именно обновление, и откладывать его нельзя. Там промедление стоит взломанного сервера. Здесь спешка стоила вечера без сайта.
Разница в одном: обновления безопасности надо ставить быстро и все, а функциональные — осознанно и после проверки. Автообновление этой разницы не видит. Её должен видеть человек.
Не уверены, что у вас обновляется само и что произойдёт после следующего обновления? Напишите нам — посмотрим на ваш сайт и скажем прямо, где он на пределе.