Кнопка «Обновить» в WordPress выглядит безопасно, но коммерческий сайт состоит не только из ядра. Тема, плагины, PHP, база, кеш и внешние интеграции развиваются с разной скоростью. Одновременная смена нескольких компонентов может остановить формы, корзину или личный кабинет.
При этом годами откладывать обновления тоже нельзя: накапливаются уязвимости, несовместимость и технический долг. Безопасный подход — обновлять регулярно, поэтапно и с возможностью вернуть рабочее состояние.
Содержание:
Почему обновления ломают сайты
Новая версия может удалить устаревшую функцию, изменить структуру шаблона, повысить требования к PHP или исправить поведение, на которое случайно опирался чужой код. Особенно рискованны сайты, где редактировали файлы плагинов и родительской темы напрямую.
Проблема может быть не видна на главной странице. После обновления иногда перестаёт отправляться одна форма, не применяется промокод, не работает cron или нарушается передача данных в CRM. Поэтому «сайт открылся» — недостаточная проверка.
Шаг 1. Проведите инвентаризацию
Зафиксируйте текущие версии WordPress, PHP, базы, активной темы и плагинов. Отметьте критичные модули: формы, WooCommerce, оплата, доставка, авторизация, кеш, безопасность, SEO и интеграции.
Проверьте, где находится кастомный код. Он должен храниться в дочерней теме, собственном плагине или репозитории, а не внутри стороннего модуля. Если происхождение изменений неизвестно, до обновления нужен технический аудит.
Шаг 2. Сделайте резервную копию и проверьте восстановление
Нужны копии файлов и базы данных, созданные непосредственно перед работами. Архив должен храниться отдельно от сайта: если аккаунт хостинга повреждён, резервная копия внутри него может оказаться недоступной.
Наличие файла ещё не означает возможность отката. Убедитесь, что архив открывается, база импортируется и известна последовательность восстановления. Официальная документация WordPress также рекомендует начинать обновление с полного бэкапа сайта.
Шаг 3. Создайте тестовую копию
Обновления коммерческого проекта сначала выполняют на staging-среде или закрытом поддомене. Копия должна быть максимально похожа на продакшен по версиям программного обеспечения и настройкам.
Закройте её от поисковой индексации и реальных оплат. Отключите отправку боевых писем и заявок либо направьте их на тестовые адреса, чтобы проверка не создавала ложные заказы.
Шаг 4. Составьте матрицу совместимости
Перед сменой PHP проверьте требования WordPress, темы и каждого критичного плагина. То, что ядро поддерживает новую версию, не гарантирует совместимость старого модуля оплаты или самописной интеграции.
Изучите журнал изменений и известные проблемы. Для давно заброшенного плагина заранее подберите замену. Если замена меняет структуру данных, её тестируют как отдельную миграцию.
Шаг 5. Не обновляйте всё одним действием
Универсального порядка для всех сайтов нет, но изменения должны быть разделены. Сначала на копии обновляют совместимые плагины и тему, проверяют сайт, затем ядро и снова выполняют проверку. Переход на новую ветку PHP лучше делать отдельным этапом.
Если сайт пропустил много крупных версий, безопаснее двигаться промежуточными шагами. После каждого этапа нужно понимать, какой компонент вызвал ошибку. Одновременное обновление двадцати модулей лишает этой возможности.
Шаг 6. Проверяйте бизнес-сценарии
Подготовьте короткий набор приёмочных сценариев. Для корпоративного сайта это формы, почта, поиск, мобильное меню, карты и аналитика. Для магазина добавляются каталог, фильтр, корзина, промокод, доставка, оплата, письма, личный кабинет и обмен остатками.
Проверяйте ошибки PHP, консоль браузера, сетевые запросы и журнал интеграций. В WordPress можно вести журнал отладки, скрывая технические сообщения от посетителей. После диагностики отладочный режим на продакшене отключают.
Шаг 7. Перенесите изменения в согласованное окно
Выберите период низкой активности, предупредите ответственных сотрудников и зафиксируйте критерии отката. Для магазина определите, как будут обрабатываться новые заказы во время работ.
Перед переносом повторите резервное копирование. После обновления очистите все уровни кеша, проверьте фоновые задачи и выполните контрольную заявку или заказ до уведомления о завершении.
Что обновлять автоматически
Небольшие обновления безопасности ядра обычно разумно устанавливать автоматически при наличии мониторинга и копий. Автоматические обновления плагинов и темы стоит включать выборочно: для некритичных компонентов риск ниже, а ключевые функции лучше сначала проверять.
На сложном сайте полностью автоматическая схема допустима только вместе с тестами, уведомлениями и быстрым откатом. Просто включить автообновление для всех модулей — не регламент обслуживания.
Как обновлять PHP
Сначала проверьте код анализатором совместимости и журналом предупреждений на тестовой среде. Исправьте устаревшие функции, обновите зависимости и только затем меняйте версию PHP.
Не совмещайте переход PHP с изменением хостинга, темы и ядра без необходимости. Один контролируемый риск проще диагностировать, чем четыре изменения одновременно.
Что должно быть в плане отката
План содержит рабочую копию файлов и базы, старую версию PHP, время принятия решения и ответственного. Откат плагина без базы может не сработать, если обновление изменило таблицы.
После возврата нужно сохранить данные, появившиеся во время работ: заявки, заказы и пользователей. Поэтому для динамического сайта откат проектируют до начала, а не после обнаружения ошибки.
Сколько занимает безопасное обновление
Небольшой поддерживаемый сайт может потребовать несколько часов. Старый WordPress с неподдерживаемой темой, десятками модулей и устаревшим PHP сначала обследуют и обновляют по этапам. В German Web работа разработчика рассчитывается по ставке 2 300 ₽ в час.
Результатом первого этапа может быть карта совместимости, резервная копия, тестовый контур и последовательность обновлений. Это небольшой контролируемый договор вместо риска сразу переделывать весь сайт.
Частые вопросы
Можно ли обновлять WordPress прямо на рабочем сайте?
Для простого некритичного проекта это возможно при хорошем бэкапе. Коммерческий сайт безопаснее сначала проверить на копии.
Что обновлять первым: плагины или ядро?
Единого правила нет. Порядок зависит от совместимости версий, поэтому изменения разделяют и тестируют после каждого этапа.
Нужно ли включать автоматическое обновление всех плагинов?
Нет. Для критичных модулей оплаты, форм и интеграций разумнее контролируемое обновление после проверки.
Почему после обновления PHP появился белый экран?
Тема или плагин может использовать функцию, несовместимую с новой версией. Нужны журналы ошибки и возврат на рабочую версию до исправления.
Достаточно ли резервной копии хостинга?
Только если подтверждены её состав, срок хранения и восстановление. Желательно иметь независимую копию файлов и базы.
Можно ли обновить очень старый WordPress сразу?
Технически иногда можно, но при большом разрыве версий безопаснее промежуточные этапы и отдельная проверка темы, плагинов и PHP.
Нужно безопасно обновить WordPress?
German Web может проверить совместимость, развернуть тестовую копию, составить порядок обновлений и выполнить перенос с планом отката. Рабочий сайт не меняется до завершения проверки.
