<b>Обновления в Multisite ломают сеть не из-за ядра, а из-за хаоса в процессе</b>

<b>Обновления в Multisite ломают сеть не из-за ядра, а из-за хаоса в процессе</b>

В сети WordPress Multisite обновление нужно проверять не “вообще”, а по слоям: ядро, плагины сети, плагины отдельных сайтов, тема, MU-plugins. Если обновить всё разом, потом сложно понять, что именно сломало логин, кеш или редактор.

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

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

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

Если в сети есть нестандартные роли, кастомные настройки доменов или свои MU-плагины, тестируйте именно эти сценарии. Обновление считается успешным не тогда, когда “сайт открылся”, а когда сеть продолжает работать по всем ключевым маршрутам.