Автоматические обновления WordPress не выполняются — как найти и устранить причину

Коротко: автообновления WordPress: в большинстве случаев проблема вызвана неправильными константами в wp-config.php, отсутствием WP-Cron или ограничениями файловой системы. Убедитесь, что define('WP_AUTO_UPDATE_CORE', true) не заблокирован, проверьте права на запись и работу планировщика задач.

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

Что понадобится

• Доступ к файлам сайта через FTP/SSH или файловый менеджер хостинга
• Возможность редактировать wp-config.php
• Доступ к логам ошибок веб-сервера

Как WordPress выполняет автоматические обновления

WordPress использует встроенный планировщик WP-Cron для периодической проверки наличия обновлений ядра, плагинов и тем. При обнаружении новой версии система загружает архив с серверов wordpress.org, распаковывает его во временную папку wp-content/upgrade и заменяет файлы. Для успешного завершения процесса необходимы корректные права на запись, доступ к удалённым ресурсам и активный механизм cron.

Проверка обновлений инициируется событием wp_version_check, которое по умолчанию запускается дважды в день. Однако WP-Cron срабатывает только при посещении страниц сайта, поэтому на площадках с низкой посещаемостью задачи могут накапливаться. Кроме того, константы в wp-config.php способны полностью запретить автоматические операции.

• Для успешного обновления необходимы: работающий WP-Cron или системный cron, права на запись в директории WordPress, доступность api.wordpress.org и downloads.wordpress.org, отсутствие блокирующих констант в wp-config.php.

Критические константы в wp-config.php

Файл wp-config.php управляет многими аспектами WordPress, включая автоматические обновления. Несколько констант способны полностью заблокировать процесс, даже если всё остальное настроено верно. Наиболее частые виновники — DISALLOW_FILE_MODS, AUTOMATIC_UPDATER_DISABLED и неверное значение WP_AUTO_UPDATE_CORE.

Константа DISALLOW_FILE_MODS, установленная в true, запрещает любые изменения файлов: обновления, установку и удаление плагинов и тем. AUTOMATIC_UPDATER_DISABLED полностью отключает все автоматические фоновые обновления. WP_AUTO_UPDATE_CORE управляет типом разрешённых обновлений ядра.

1. Откройте wp-config.php через FTP или файловый менеджер хостинга.
2. Найдите строки, содержащие define с упоминанием обновлений.
3. Убедитесь, что define('DISALLOW_FILE_MODS', true) отсутствует или закомментирован.
4. Проверьте, что define('AUTOMATIC_UPDATER_DISABLED', true) не задан.
5. При необходимости добавьте или исправьте define('WP_AUTO_UPDATE_CORE', true); для включения всех обновлений ядра. Для разрешения только минорных версий используйте 'minor'.

Важно: Не дублируйте константы, иначе это вызовет фатальную ошибку.

Работа WP-Cron и альтернатива на системном cron

Встроенный планировщик WP-Cron удобен, но ненадёжен: задачи выполняются только при заходе посетителей. Если сайт посещается редко или пиковая нагрузка не совпадает с запланированным временем, обновления могут никогда не запуститься. Более того, некоторые хостинги или плагины безопасности отключают WP-Cron.

Правильным решением для стабильной работы автообновлений является замена виртуального cron на системный cron сервера. При этом в wp-config.php отключают WP-Cron, а в crontab добавляют вызов wp-cron.php с нужной периодичностью.

1. Проверьте, нет ли в wp-config.php строки define('DISABLE_WP_CRON', true). Если она есть, значит WP-Cron отключён.
2. Если WP-Cron отключён, настройте задачу в системном cron: каждые 5-15 минут выполняйте команду wget -q -O — https://вашсайт.ru/wp-cron.php?doing_wp_cron > /dev/null 2>&1 или php /путь/к/сайту/wp-cron.php.
3. В панели хостинга или crontab укажите интервал и команду, соответствующую вашему окружению.
4. Убедитесь, что URL или путь к файлу доступен и не требует авторизации.

Важно: На некоторых виртуальных хостингах системный cron недоступен — уточните в поддержке.

Права доступа и владелец файлов

Для замены файлов веб-серверу нужны права на запись в корневой каталог WordPress и подкаталоги wp-admin, wp-includes, wp-content. Если файлы были загружены под одним пользователем, а веб-сервер работает от имени другого, операции записи завершатся ошибкой Permission denied. Типичная ситуация: файлы принадлежат пользователю FTP, а процесс Apache или PHP-FPM выполняется от nobody, www-data или аналогичного.

Корректные права для файлов — 644, для директорий — 755. В особых случаях папке wp-content и её поддиректориям могут потребоваться права 775, но это не рекомендуется на общедоступных серверах.

1. Через FTP-клиент или терминал проверьте владельца файлов: ls -l в корне сайта.
2. Сравните владельца с пользователем веб-сервера (например, www-data, apache, nginx).
3. При несовпадении смените владельца рекурсивно: chown -R www-data:www-data /путь/к/сайту (требуются root-права, может потребоваться обращение в поддержку хостинга).
4. Установите права: find /путь/к/сайту -type d -exec chmod 755 {} ; и find /путь/к/сайту -type f -exec chmod 644 {} ;

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

Сетевое подключение к серверам обновлений

WordPress загружает обновления с api.wordpress.org и downloads.wordpress.org. Если хостинг блокирует исходящие HTTP/HTTPS-соединения с помощью брандмауэра, обновления не смогут начаться. Аналогичная ситуация возникает при отсутствии PHP-расширения curl или устаревшей версии OpenSSL.

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

1. Выполните из SSH-терминала: curl -I https://api.wordpress.org. Вы должны получить HTTP/2 200.
2. Если curl не установлен, проверьте через wget: wget —spider https://api.wordpress.org.
3. При ошибке соединения уточните у провайдера, разрешены ли исходящие запросы на порт 443.
4. Убедитесь, что PHP-расширения curl и openssl активны: создайте файл phpinfo(); и найдите соответствующие разделы.

Важно: Некоторые хостинги блокируют запросы к внешним ресурсам из PHP, но разрешают из CLI — это можно использовать как временное решение через системный cron.

Влияние плагинов безопасности и кеширования

Плагины безопасности, такие как Wordfence, Sucuri или iThemes Security, могут перехватывать запросы обновлений и блокировать их, ошибочно принимая за вредоносную активность. Агрессивное кеширование через плагины или серверные средства (Varnish, NGINX FastCGI Cache) иногда кеширует ответ wp-cron.php или мешает корректному выполнению фоновых задач.

Для проверки временно отключите все плагины безопасности и кеширования, затем запустите принудительную проверку обновлений в админ-панели «Консоль -> Обновления».

1. Перейдите в «Плагины» и деактивируйте плагины безопасности и кеширования.
2. Зайдите на страницу «Обновления» и нажмите «Проверить еще раз».
3. Если обновления появились и начали устанавливаться, поочерёдно включайте плагины обратно, чтобы выявить конфликтный.
4. В настройках проблемного плагина добавьте исключения для файлов обновлений или IP-адресов WordPress.

Диагностика через логи и режим отладки

Когда внешние проверки не выявляют явных блокировок, включите режим отладки WordPress. Константы WP_DEBUG и WP_DEBUG_LOG записывают все ошибки в файл /wp-content/debug.log, что позволяет увидеть точную причину сбоя — от невозможности создать временную директорию до проблем с загрузкой пакета.

После включения отладки инициируйте проверку обновлений вручную и сразу изучите лог. Помимо PHP-ошибок, обратите внимание на записи веб-сервера (error_log) — там могут быть сообщения о нехватке памяти или таймаутах.

1. В wp-config.php добавьте строки: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
2. Повторите попытку автоматического обновления или запустите ручную проверку в админ-панели.
3. Откройте файл /wp-content/debug.log и найдите записи, связанные с update, core, upgrade.
4. Проанализируйте ошибки: Permission denied указывает на права, Unable to locate WordPress Content directory — на неправильный ABSPATH, файл не найден — на сетевые проблемы.

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

Проверка результата

• Проверьте, что в корне сайта нет файла .maintenance: удалите его, если он остался после предыдущей неудачной попытки.
• Убедитесь, что константа DISALLOW_FILE_MODS не задана как true в wp-config.php.
• Проверьте, не пустует ли папка wp-content/upgrade: если там остались временные файлы, удалите их вручную.
• Попробуйте открыть в браузере https://вашсайт.ru/wp-cron.php — появление белого экрана или ошибки 500 укажет на проблему с cron.
• Просмотрите журнал ошибок веб-сервера на наличие строк «permission denied» или «Could not create directory».

Частые ошибки и нюансы

• Установка define('DISALLOW_FILE_MODS', true) для повышения безопасности блокирует все обновления, включая критические исправления.
• Отключение WP-Cron без настройки системного крона оставляет сайт без автоматических фоновых задач.
• Размещение WordPress в подкаталоге, где права на запись выданы только владельцу FTP, но не веб-серверу.
• Наличие плагинов, которые переопределяют константы обновлений через must-use плагины или в неправильном порядке в wp-config.php.

FAQ

Как понять, что автоматические обновления вообще попытались запуститься?

Проверьте логи сайта, включите WP_DEBUG_LOG. В таблице *_options найдите записи с option_name 'auto_updater.lock' или 'auto_core_update'. В разделе «Инструменты -> Здоровье сайта» иногда отображается информация о последних попытках обновлений.

Почему обновления перестали работать после переноса сайта на другой хостинг?

Чаще всего меняется владелец файлов или отключается WP-Cron. Проверьте права доступа и настройку крона, а также доступность curl.

Может ли плагин кеширования влиять на автообновления?

Да, некоторые агрессивные системы кеширования могут блокировать запросы к wp-cron.php или служебные URL обновлений. Временно отключите кеширование для проверки.

Безопасно ли добавлять define('WP_AUTO_UPDATE_CORE', true)?

Да, эта константа включает автоматическое обновление для всех версий ядра (включая мажорные). Если нужны только минорные обновления и обновления безопасности, используйте значение 'minor'.

Что делать, если хостинг-провайдер заблокировал исходящие соединения к серверам WordPress?

Обратитесь в техподдержку и запросите открытие доступа к api.wordpress.org и downloads.wordpress.org на порты 80 и 443. Без этого автоматические обновления невозможны.

Итог

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

Также может быть интересно

Ошибка 502 Bad Gateway в WordPress: пошаговая диагностикаОткрыть инструкциюОшибка 403 в WordPress: причины появления и практические способы исправленияОткрыть инструкциюЧто делать, если Elementor перестал открыватьсяОткрыть инструкцию