Почему обновления ломают не сайт, а привычки команды

Почему обновления ломают не сайт, а привычки команды

В WordPress Multisite обновление — это не кнопка «исправить всё», а точка проверки. Если сеть живёт на десятках сайтов, любой апдейт надо запускать как процесс, а не как импульс.

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

Ошибка, которую видят чаще всего: обновляют ядро, а потом ищут, какой сайт в сети «поехал». В multisite проблемы часто сидят не в самом обновлении, а в связке: MU-плагины, сетевые настройки, роли, кэш, интеграции с внешними сервисами. Один неучтённый модуль способен положить сразу несколько сайтов. ⚙️

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

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