Как безопасно обновить WordPress и версию PHP

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

Зачем вообще обновлять

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

Порядок, который работает

1. Резервная копия целиком. Файлы и база данных, обе части. Копия должна лежать там, откуда вы сможете её достать, даже если сайт не открывается.
2. Проверка совместимости. Посмотрите, когда плагины обновлялись в последний раз и какую версию поддерживают. Плагин, заброшенный три года назад, — главный кандидат сломать всё.
3. Тестовая копия. Разворачиваете сайт на поддомене или локально и обновляетесь сначала там. Для боевого магазина это обязательный шаг, для визитки допустимо обойтись копией и планом отката.
4. Сначала плагины, по одному. После каждого — открыть главную, страницу услуги, форму. Обновлять пачкой удобно ровно до первого падения: потом непонятно, что именно сломалось.
5. Потом ядро WordPress. Оно ломается реже плагинов, но после него надо проверить админку и редактор.
6. В последнюю очередь PHP. Версия переключается в панели хостинга. Делайте это, когда плагины и тема уже свежие.
7. Проверка после. Главная, ключевые страницы, форма заявки с реальной отправкой, корзина и оплата, мобильная версия, скорость.

Отдельно про переключение PHP

В панели хостинга это одна кнопка, и в этом опасность: переключили — и часть сайта отвалилась с белым экраном. Что помогает:

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

Если сайт всё-таки упал

• Белый экран. Включите отображение ошибок или посмотрите лог ошибок на хостинге — там будет имя файла, а значит и плагина.
• Не заходит админка. Отключите все плагины, переименовав папку plugins через файловый менеджер: сайт поднимется, дальше включайте по одному.
• Сломалась вёрстка. Обычно это конфликт темы с новой версией. Временно переключитесь на стандартную тему, чтобы понять, в ней ли дело.
• Ничего не помогает. Разворачивайте бэкап. Это не поражение, а нормальный план Б — ради него копия и делалась.

Живой пример: у одного из наших клиентов сайт уронило именно автообновление. Итог — пять часов простоя и падение показов в тот день втрое. Восстановили в тот же день из копии, после чего отключили автообновления и перевели их в ручной режим с проверкой.

Автообновления: включать или нет

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

Как часто это делать

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

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

Частые вопросы

Можно ли обновлять плагины сразу все?

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

Как понять, какую версию PHP выбрать?

Ориентируйтесь на ту, что WordPress отмечает как рекомендуемую, и переключайтесь ступенчато. Перед переключением проверьте состояние сайта в админке: там видно, какие плагины не готовы.

Нужен ли тестовый сайт?

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

Что делать, если плагин давно заброшен?

Искать замену заранее, а не в момент, когда он отвалится после обновления ядра. Заброшенные плагины — самая частая причина и падений, и взломов.

Сайт лежит прямо сейчас, что делать первым?

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