WordPress завис в режиме обслуживания: сбой обновлений

Если сайт пишет "Briefly unavailable for scheduled maintenance. Check back in a minute." и пишет это дольше десяти минут, обновление было прервано и оставило в корне WordPress файл .maintenance. Удалите его через файловый менеджер или SFTP, и сайт вернётся. Это лечит симптом. Причина обычно одна из четырёх: упёрлись в лимит времени или памяти PHP посреди обновления, WordPress не смог записать в каталог, закончилось место на диске или в неудачный момент закрыли вкладку браузера. Пока вы не знаете, какая именно, следующее обновление закончится так же.

В этом материале разобрано всё семейство проблем: зависшая страница обслуживания, "Another update is currently in progress", "Could not copy file", запрос учётных данных FTP, обновление плагина, из-за которого упал сайт, и ручное обновление, когда от панели управления толку нет. Всё делается через файловый менеджер или SFTP, а в каждом разделе сказано, что проверить, прежде чем что-то менять.

Что делает WordPress во время обновления#

Обновление - это не одна операция, и порядок её шагов подсказывает, где именно случился сбой. Когда вы обновляете ядро, плагин или тему из панели управления, WordPress делает примерно следующее:

1. Скачивает zip во временное место и проверяет его.
2. Записывает в корень сайта файл .maintenance. С этого момента посетители видят страницу обслуживания.
3. Распаковывает архив в wp-content/upgrade/.
4. Копирует новые файлы поверх старых, каталог за каталогом.
5. Удаляет распакованные файлы и файл .maintenance.
6. После обновления ядра запускает обновление базы данных при следующем заходе администратора в панель.

Шаги со 2 по 5 - опасное окно, и на здоровом хостинге оно длится несколько секунд. Всё, что убивает PHP в это время, оставляет сайт в промежуточном состоянии: файл обслуживания на месте, часть файлов новая, часть старая, в wp-content/upgrade/ лежит остаток. WordPress умеет восстанавливаться после большинства таких случаев, поэтому страница обслуживания сама перестаёт действовать, но справиться с запросом, которому не дали закончиться, он не может.

Файл .maintenance крошечный. В нём лежит метка времени:

<?php $upgrading = 1761000000; ?>

WordPress сравнивает это число с текущим временем. Если файлу меньше десяти минут, показывается страница обслуживания. Через десять минут файл игнорируется, и сайт работает как обычно. Так что если вы видите страницу через четверть часа после начала обновления, то либо файл ещё обновляется работающим процессом (редко), либо страницу отдаёт кэш. Оба случая разобраны ниже.

Как вывести сайт из режима обслуживания#

Файл называется .maintenance, с точкой в начале, поэтому его так часто не могут найти. Файлы, имя которых начинается с точки, скрыты во многих SFTP-клиентах и некоторых файловых списках.

1. Откройте файловый менеджер или SFTP-клиент и перейдите в каталог, где лежит wp-config.php. Это корень WordPress.
2. Включите показ скрытых файлов. В FileZilla это Server, Force showing hidden files. В WinSCP - Options, Preferences, Panels, Show hidden files.
3. Удалите .maintenance.
4. Обновите сайт в приватном окне, чтобы закэшированная копия страницы обслуживания не ввела вас в заблуждение.

Если сайт вернулся, на этом не останавливайтесь. Откройте Dashboard, Updates. Если WordPress снова предлагает то же обновление, прошлая попытка не завершилась, и вероятнее всего ядро или плагин скопированы наполовину. Прежде чем запускать обновление второй раз поверх первого, прочитайте раздел о восстановлении недоделанного обновления.

Если файла уже нет, а сообщение об обслуживании остаётся, страницу отдаёт кэш. Обычные источники: плагин кэширования, сохранивший страницу, пока .maintenance существовал, кэш страниц на стороне сервера и CDN. Очистите кэш плагина на его странице настроек, а если панель недоступна, удалите содержимое wp-content/cache/. Если перед сайтом стоит CDN или прокси, сбросьте и его - в материале Cloudflare для сайтов и игровых серверов объяснено, какие его уровни кэшируют HTML, а какие нет.

Вторая, более редкая причина - собственная страница обслуживания. WordPress покажет wp-content/maintenance.php вместо стандартного сообщения, если такой файл существует. Плагины с режимом обслуживания или страницей "скоро открытие" часто работают именно так. Если на экране не стандартная фраза, поищите этот файл или включённый плагин обслуживания.

"Another update is currently in progress"#

Обновление ядра берёт блокировку, чтобы две вкладки браузера или два администратора не запустили его одновременно. Блокировка - это строка в базе данных, в таблице wp_options, с именем core_updater.lock. Она снимается, когда обновление заканчивается. Если PHP умирает посреди обновления, строка остаётся, и следующие 15 минут WordPress отказывается запускать новое обновление ядра, выводя "Another update is currently in progress".

Честное решение - подождать пятнадцать минут и повторить. У блокировки есть срок действия, и после его окончания WordPress игнорирует старую строку. Если ждать нельзя или вы хотите убедиться, что дело в строке, удалите её. На RE:NODE кнопка "Open in phpMyAdmin" в панели входит по одноразовому токену, который истекает через 60 секунд, так что вводить пароль не нужно. Выполните это во вкладке SQL, поменяв префикс таблиц, если он не wp_:

SELECT option_id, option_name, option_valueFROM wp_optionsWHERE option_name = 'core_updater.lock';DELETE FROM wp_optionsWHERE option_name = 'core_updater.lock';

Сначала убедитесь, что никакое обновление на самом деле не идёт. Если снять блокировку в середине копирования, вы получите ровно то повреждение, от которого она защищает. Если файл .maintenance есть и был записан минуту-две назад, возможно, что-то ещё работает. Подождите и проверьте снова.

То же сообщение появляется и по другой причине, на сайтах со сломанной отложенной задачей. WordPress запускает фоновые обновления из собственного планировщика, поэтому на сайте со сломанным cron блокировку может держать процесс, который никогда не завершится. В материале WP-Cron и настоящий cron объяснено, как это распознать и как сделать планировщик надёжным.

Почему обновления не проходят: причины по убыванию вероятности#

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

Место на диске. Обновлению нужно место одновременно под zip, распакованную копию и новые файлы, так что обновление ядра может ненадолго потребовать втрое больше места, чем занимает заменяемое. На маленьком тарифе с большой папкой загрузок этого хватает для сбоя. Посмотрите график диска в консоли панели, он показывает диск относительно лимита, и уберите лишнее: старые zip плагинов, содержимое wp-content/upgrade/, папки кэша и архивы плагинов резервного копирования, оставленные внутри wp-content. Плагин резервного копирования, который пишет архивы рядом с сайтом, - самый частый способ забить небольшой диск WordPress.

Лимиты. Обновление ядра распаковывает и копирует тысячи мелких файлов: на быстром накопителе это несколько секунд, на загруженной машине заметно дольше. Если max_execution_time очень мал или memory_limit достаточно мал, чтобы упереться в него при распаковке, PHP останавливает процесс посреди копирования. Какие значения проверять и как их повышать, написано в материале настройки PHP, которые важны для WordPress. Практическое правило: 256M для memory_limit и не менее 60 секунд для max_execution_time - разумный минимум для обновления. Материал сколько RAM нужно WordPress рассматривает обратную сторону: лимит, который PHP разрешает, а тариф обеспечить не может.

Исходящие соединения. Сервер скачивает обновление с wordpress.org, поэтому ему нужен исходящий HTTPS. Если DNS не работает или межсетевой экран блокирует запрос, вы увидите ошибку загрузки до того, как будет тронут хоть один файл. Это самый безопасный сбой, потому что ничего не изменилось. Повторите позже, а если не проходит, откройте Tools, Site Health и прочитайте проверки "WordPress.org REST API" и loopback.

Права на файлы и запрос данных FTP#

Именно этот сбой путает людей больше всего. Вы нажимаете Update, а WordPress показывает форму с запросом данных FTP или SFTP, либо заканчивает ошибкой "Could not create directory". Ни то ни другое не значит, что пароль неверный. Это значит, что WordPress проверил, может ли он писать в собственные каталоги, и решил, что не может.

WordPress выбирает способ записи файлов. По умолчанию он создаёт небольшой временный файл в wp-content и сравнивает его владельца с владельцем уже лежащих там файлов. Если они совпадают, запись идёт напрямую. Если различаются, WordPress решает, что PHP не владеет сайтом, и просит данные FTP. Поэтому запрос - на самом деле симптом смешанных владельцев: часть файлов создал один пользователь, обычно тот, кто загрузил их по SFTP или развернул архив, а PHP работает от имени другого.

Типичные права, если хостинг позволяет их задавать:

Чтобы войти в каталог, нужен бит исполнения, поэтому 644 на папке ломает всё, что в ней лежит. Никогда не используйте 777. Это не решает проблему владельца, а лишь делает каждый файл доступным для записи каждой учётной записи на машине, и именно это первым ищет атакующий. Остальное о правах доступа есть в материале защита WordPress.

Если можно выполнять команды, исправление - две строки, из корня WordPress:

$ find . -type d -exec chmod 755 {} +$ find . -type f -exec chmod 644 {} +

На хостинге с панелью сменить владельца часто нельзя вовсе, и это редко нужно. Файловый менеджер и SFTP работают с теми же файлами, которые отдаёт PHP, поэтому созданные через них файлы обычно доступны сайту для записи. Проблема чаще всего появляется после восстановления из архива, распаковки другим инструментом или переноса, который притащил старого владельца. Тогда правильный путь - тикет, потому что исправление на стороне хостинга. В материале SFTP: permission denied при правке файлов разобрано, как отличить проблему режима от проблемы владельца.

Если вы знаете, что файлы сайта доступны для записи, а WordPress всё равно спрашивает, можно запретить ему гадать, добавив строку в wp-config.php выше комментария "That's all, stop editing":

define( 'FS_METHOD', 'direct' );

Это не даёт никаких прав. Оно лишь останавливает собственные догадки WordPress. Если файлы действительно недоступны для записи, обновление теперь закончится понятной ошибкой прав вместо формы, что полезнее. Уберите строку, когда основная проблема будет исправлена.

Как починить недоделанное обновление#

Если обновление умерло на середине, может остаться три вида мусора. Разбирайте их по порядку и сначала сделайте резервную копию.

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

2. Очистите временные папки. WordPress распаковывает обновления в wp-content/upgrade/. На здоровом сайте эта папка пуста. Всё, что в ней лежит, - обломки неудачного запуска, а оставшаяся папка - причина "Destination folder already exists". Удалите содержимое, а не саму папку. Начиная с WordPress 6.3, при обновлении плагинов и тем старая версия также хранится в wp-content/upgrade-temp-backup/, чтобы неудачное обновление можно было откатить. Если там лежит каталог плагина, который вы обновляли, а его рабочий каталог сломан или пропал, эта копия - самый быстрый путь назад к рабочей версии: переместите её в wp-content/plugins/.

3. Переустановите то, что обновлялось. Если прерванное обновление касалось плагина или темы, удалите его папку и загрузите свежую копию. Это безопасно, потому что настройки хранятся в базе данных, а не в файлах плагина. Если это было ядро, сделайте ручное обновление ядра - оно в следующем разделе. Затем снова запустите обновление из Dashboard, Updates.

Если теперь сайт показывает критическую ошибку, обновление завершилось, но новый код не работает с чем-то на вашем сайте. Это другая проблема с другим журналом. Перейдите к материалу белый экран и ошибка 500 в WordPress, включите WP_DEBUG_LOG и прочитайте последнюю строку debug.log. Плагин, который ломается после обновления, можно отключить, переименовав его папку в wp-content/plugins/, и сайт тут же вернётся; настройки плагина остаются в базе данных.

Как обновить WordPress вручную#

Ручное обновление - обычный инструмент, а не крайняя мера. Оно работает, когда панель управления бессильна, и так же безопасно, как автоматический путь, если соблюдать порядок. Это тот же метод, что описан в документации WordPress.

1. Сделайте резервную копию файлов и базы данных.
2. Скачайте последний zip с wordpress.org и распакуйте его на своём компьютере, либо загрузите zip и распакуйте на месте файловым менеджером, который извлекает архивы там, где они лежат.
3. Если панель управления недоступна, ничего заранее не отключайте. Если доступна, можно сначала отключить плагины кэширования.
4. Удалите на сервере папки wp-admin и wp-includes. В них только файлы ядра, вашего содержимого там нет.
5. Загрузите новые wp-admin и wp-includes.
6. Загрузите отдельные файлы из корня нового пакета поверх старых: index.php, wp-login.php, wp-settings.php и остальные. Не перезаписывайте wp-config.php и не заменяйте wp-content.
7. Внутри wp-content можно обновить темы по умолчанию и встроенные плагины. Никогда не удаляйте собственные папки plugins, themes или uploads.
8. Откройте в браузере /wp-admin/upgrade.php. Если базу данных нужно обновить, WordPress сделает это и сообщит вам.
9. Удалите .maintenance, если он ещё на месте, очистите кэши и проверьте главную страницу, вход и одну запись.

Папки wp-admin и wp-includes удаляют, а не перезаписывают потому, что новая версия не только добавляет файлы, но и убирает их. При перезаписи удалённые файлы остаются, и старые файлы могут подгрузиться по ошибке. Удалять эти две папки безопасно, потому что ваших файлов в них нет.

Если у вас есть оболочка с WP-CLI, та же работа короче, и она выполнима даже при неработающей панели управления:

$ wp core version$ wp core download --force --skip-content$ wp core update-db$ wp core verify-checksums

--skip-content не трогает wp-content. verify-checksums сравнивает файлы ядра с официальными и перечисляет изменённые или отсутствующие, а это быстрый способ убедиться, что недоделанное обновление теперь целое. Файлы плагинов проверяются отдельно командой wp plugin verify-checksums --all. WP-CLI есть не на каждом тарифе, поэтому считайте базовым путь через файловый менеджер, а что даёт для этого панель RE:NODE, смотрите в последнем разделе этого материала.

Обновления плагинов и тем, которые ломают сайт#

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

Сначала обновляйте копию. Тестовый сайт - единственный способ узнать, что обновление ломает оформление заказа, раньше ваших покупателей. В материале рабочий процесс с тестовым сайтом WordPress показано, как его построить, переносить изменения и не затирать живые заказы и комментарии.

Обновляйте по одному. Если обновить пятнадцать плагинов одним щелчком, у сбоя окажется пятнадцать подозреваемых. Обновите, откройте главную страницу и важные страницы, потом продолжайте. Для сайта, который приносит деньги, делайте это в тихий час и со свежей резервной копией, сделанной непосредственно перед этим.

Заранее знайте путь назад. Плагин, сломавший сайт, можно отключить, переименовав его каталог. Чтобы сайт заработал, переименуйте wp-content/plugins/name в name.off и перезагрузите страницу. Если вы не знаете, какой это плагин, переименуйте всю папку plugins в plugins.off, и все плагины отключатся разом. WordPress это заметит, отключит их в базе данных и снова покажет панель управления. Верните имя папки и включайте плагины по одному, чтобы найти виновника. Чтобы вернуться к предыдущей версии плагина, скачайте её на странице плагина на wordpress.org, в разделе Advanced View, Previous Versions.

Автообновления меняют ставки. WordPress сам применяет малые выпуски ядра, в основном исправления безопасности. Управлять этим можно в wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Значения: true (все выпуски), false (никаких) и 'minor'. Оставляйте малые обновления включёнными. Автообновления плагинов включаются отдельно для каждого плагина на экране Plugins, и их лучше оставлять для тех, без которых сайт мог бы прожить день, и никто бы не заметил. Всё, что касается платежей, форм или вёрстки темы, должен обновлять человек, который потом посмотрит на сайт.

Как не допустить следующего сбоя обновления#

Общая нить неудачных обновлений в том, что никто не позаботился сделать сбой дешёвым. Это исправляет короткий регламент.

• Держите запас. Свободно на диске не меньше двойного размера ядра и самого крупного плагина, и memory_limit 256M или больше.
• Делайте копию, которую вы восстанавливали. Недостаточно просто сделать. Резервная копия, которую никогда не восстанавливали, - гипотеза. В материале резервные копии, которые действительно восстанавливаются объяснено, как проверить копию, не рискуя рабочим сайтом.
• Обновляйтесь, когда тихо, и наблюдайте первые минуты. Большинство недоделанных обновлений тот, кто их запустил, замечает сразу.
• Планируйте копию перед обновлением. Резервная копия по расписанию за час до обычного окна обновлений означает, что точка восстановления существует, даже если вы забудете. Образец показан в материале задачи по расписанию, которые стоит иметь.
• Не закрывайте вкладку. Обновление идёт внутри вашего запроса. Закрытие браузера во время распаковки не всегда останавливает PHP, но это классический способ получить зависший файл .maintenance.
• Держите структуру файлов в порядке. Резервным копиям, экспортам и старым zip не место в wp-content. Они забивают диск и отдаются всему миру, если путь легко угадать.

Что для этого даёт панель RE:NODE#

Большая часть сказанного не зависит от хостинга, но некоторые части панели прямо ложатся на шаги.

Линейка WordPress на RE:NODE устанавливает WordPress при первом запуске, а wp-config.php уже записан для собственной базы данных MySQL, так что учётные данные базы верны с самого начала. В файловом менеджере есть редактор в браузере, он принимает перетаскивание файлов и загрузку папок и распаковывает архивы на месте, поэтому ручное обновление сводится к загрузке одного zip и его извлечению. SFTP есть на каждом сервере, учётные данные у каждого сервера свои. Графики консоли показывают память, CPU и диск относительно лимитов тарифа, так что нехватка места под обновление видна ещё до его начала. Слот базы данных открывается в phpMyAdmin из панели, и именно так удаляется строка core_updater.lock.

Резервные копии есть на каждом тарифе, их можно делать по требованию или по расписанию, они хранятся вне машины, которую защищают, и восстанавливаются кнопкой, так что первый шаг любого ремонта выше - один щелчок. Расписания могут запускать копию перед вашим окном обновлений. Если для исправления нужны руки хостинга - восстановление из копии платформы или права на файлы, которые вы не можете изменить, - откройте тикет из панели, он доходит до всех сотрудников.

FAQ#

Как долго WordPress должен оставаться в режиме обслуживания?

Несколько секунд для плагина, до минуты для обновления ядра. Всё, что дольше десяти минут, означает, что обновление остановилось. Сам WordPress игнорирует файл .maintenance старше десяти минут, поэтому страница, которая видна после этого, обычно закэширована или идёт от плагина обслуживания.

Безопасно ли удалять файл .maintenance?

Да. В нём только метка времени, и WordPress создаёт его заново при каждом обновлении. Риск не в удалении, а в предположении, что обновление закончилось. После удаления загляните в Dashboard, Updates, и если то же обновление предлагается снова, исправьте его, прежде чем повторять.

Потеряю ли я содержимое, если обновление не прошло?

Записи, страницы, комментарии и настройки лежат в базе данных, которой прерванное копирование файлов не касается. Файлы плагинов, тем и ядра могут остаться записанными наполовину. Загрузки обновлениями не меняются. Всё равно сделайте резервную копию перед любым ремонтом.

Почему WordPress просит данные FTP, когда я нажимаю обновить?

Потому что он обнаружил, что владелец файлов, в которые он будет писать, - не тот пользователь, от имени которого работает PHP, и решил, что нужны внешние учётные данные. Причина в владельце или режиме, а не в пароле. Исправьте права или попросите об этом хостинг, а не вводите данные в форму.

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

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

Обновление прошло, но сайт показывает критическую ошибку. Что делать?

Новый код конфликтует с вашей темой, другим плагином или версией PHP. Переименуйте папку плагина, чтобы отключить его, верните сайт к жизни и прочитайте wp-content/debug.log, чтобы понять, какой файл упал и почему. Затем посмотрите в списке изменений плагина, не появилось ли новое требование к PHP.