Сломался WP Cron

Примерно с середины прошлого месяца в моём блоге перестал работать планировщик выполнения задач WordPress, назовём его для краткости «крон». С тех пор у меня накопилось более тысячи невыполненных заданий типа «Wordfense scheduled scan» и «WPBTD hook scan», и хотя некоторые из ответственных за них плагины были удалены или деактивированы, задачи продолжали стоять в очереди.

Проверить состояние крона и отследить выполнение задач можно с помощью плагина «Advanced Cron Manager» (и множества других подобных плагинов).

Эта проблема, судя по всему, достаточно широко распространена, но в русскоязычном сегменте интернета я информации практически не нашёл. Возможно, плохо искал. Начну с простого, постепенно переходя более к сложному.

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

Во-вторых, если время вашего блога и сервера, на котором он размещён, сильно отличаются2 (к примеру, у вас зарубежный западноевропейский хостинг, а живёте вы где-то в Сибири, разбег по понятным причинам может быть от 5 до 10 и более часов). В таком случае попробуйте узнать у своего хостера или в открытых источниках, где физически расположен дата-центр с вашими файлами, и выставите в настройках тот же часовой пояс для своего блога, и после этого посмотрите, заработал ли крон.

В-третьих, крон может быть отключен в конфигурации вашего WP-блога1. Проверьте содержимое файла  wp-config.php  на предмет наличия строки:

define('DISABLE_WP_CRON', true);

В случае наличия такой строчки достаточно поменять параметр true на false (либо вовсе закомментить строку или удалить её), и затем сохранить изменённый конфигурационный файл на веб-сервере. Естественно, в таком случае возникает вопрос, кто команду на отключение крона туда добавил, но мало ли какие ситуации бывают?

В-четвёртых, проблема невыполнения заданий типа публикации отложенных постов может быть связана с веб-сервером, на котором размещён WordPress-блог, и его настройками. Например, специалисты-плагинисты пишут3, что веб-сервер LiteSpeed ради быстродействия может снимать с выполнения задачи, которые занимают по времени несколько бóльший период, чем мгновение, отчего различные плагины безопасности и бэкап-плагины не могут завершить антивирусное сканирование и создание бэкапа соответственно.

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

В-пятых, ваш хостинг-провайдер может в целях безопасности отключить loopback-соединения, и тогда крон не будет работать вовсе. В данном случае вам поможет альтернативная конфигурация крона1, включаемая добавлением одного-единственного параметра в файл  wp-config.php  (добавлять строку кода рекомендуется где-то в середине файла, иначе есть вероятность, что фича не сработает):

define('ALTERNATE_WP_CRON', true);

С добавлением этого параметра, если причина проблемы заключалась в отключенных loopback connections или в настройках LiteSpeed, крон сразу же должен начать работу. «Косяк» тут только один: в моменты выполнения задач к УРЛу вашего блога начнёт добавляться набор знаков вида ?doing_wp_cron= 1428264015.9538888931274414062500. Такое безобразие будет отображаться далеко не всегда, и, соответственно, не всем посетителям вашего сайта, но всё же.

Терпеть не могу «грязные» километровые УРЛы типа гугловских, в которых чуть ли не всё обо мне записано — откуда пришёл, куда кликнул, каким браузером пользуюсь, какие соцсети предпочитаю… Если с Гуглом и ему подобными всё понятно, никуда от них (кроме разве что DuckDuckGo в части поиска) не денешься, то какие-то блоги или обычные контент-сайты со сложносочинёнными УРЛами вызывают у меня стойкое отторжение.

В случае с альтернативной конфигой крона, конечно, УРЛ не такой «грязный», но всё же периодическое наличие в адресе блога «doing_wp_cron» и множества цифр вызывает у меня стойкое желание продолжить поиск альтернатив.

Поэтому я обратился за помощью к своему хостинг-провайдеру Fozzy. Сервер, на котором размещён мой блог, именно «сверхбыстрый» LiteSpeed, и специалист техподдержки мне ответил, что не может менять параметры виртуального хостинга, так как это затронет других пользователей, и посоветовал либо установить плагин «WP Missed Schedule»2, либо включить на своём сервере настоящий крон2, потому что по умолчанию в WordPress используется «виртуальный крон». Либо переехать с LiteSpeed на Apache.

fozzy banner

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

Про Апач: быстродействие блога в целом меня устраивает, с учётом удалённости сервера оно вполне стандартное для WP-комбайнов, а с Апачем может и упасть, поэтому решаю попробовать сначала предложенные костыли и варианты, а потом уже о переезде на другой сервер (со всеми вытекающими) думать.

Включаем системный планировщик WordPress

Для начала необходимо виртуальный крон отключить — о том, как это сделать и затем вернуть всё обратно, уже есть упоминание выше (см. пункт «в-третьих») — в файл  wp-config.php  нужно добавить строку:

define('DISABLE_WP_CRON', true);

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

Далее идём в предоставленную хостинг-провайдером cPanel, чтобы найти и кликнуть в разделе «Расширенный» пункт меню «Запланированные задания». Затем нужно заполнить форму добавления нового запланированного задания по образцу. Должно получиться что-то вроде этого:

Добавляем реалный крон в WordPress через cPanel

Самое главное тут — правильная команда. Не забудьте поменять http://yoursite.com на доменное имя вашего сайта!

wget -O /dev/null http://yoursite.com/wp-cron.php?doing_wp_cron

Затем остаётся только добавить новое запланированное задание и мониторить его выполнение. Существуют способы добавления системного крона и в условиях отсутствия cPanel, и на своём собственном сервере, которые по понятным причинам я не пробовал. Читайте источник информации № 2 в сносках.

На этом всё. Надеюсь, ваш крон работает и никогда не сломается. Если это не так, удачи в поиске причины и возвращении этой сволочи к жизни!


Ссылки в тексте указывают на следующие источники информации:

  1. My scheduled backups do nothing, or “Backup Now” stops mid-way;
  2. How to FIX WordPress Posts Missed Schedule Problem;
  3. I am having trouble backing up, and my web hosting company uses the LiteSpeed webserver.

Сломался WP Cron: 6 комментариев

  1. У меня часто проблемы были из за крона, пришлось временно его отключить, пока не решила вопрос с большой загрузкой сайта

  2. Алексей, привет! А какую оптимальнее всего установить периодичность выполнения нового задания? Поставила пока раз в 5 минут, хожу ищу информацию об этом, не могу ничего найти пока. Хостер замучил сообщениями о том, что я сильно нагружаю сервер, предложили вообще скрипт CRON выключить. Но это ведь не вариант, он ведь много и полезных функций выполняет.

    1. Привет, Ксюша!

      5 минут — это слишком часто, поставьте раз в 30 минут или раз в час. Тогда и нагрузка на сервер будет меньше, и эффективность работы движка блога не снизится. Выключать его совсем не надо, много чего работать перестанет, но и слишком часто его запускать смысла нет. Я не знаю, какой набор плагинов у вас установлен, рассмотрите каждый плагин и каждую функцию, запускаемую по расписанию с помощью cron, на предмет необходимости и разумной частоты выполнения. К примеру, кэшировать страницы каждый час можно, но вовсе не нужно. Таким образом, в настойках кэширующего плагина лучше выставить суточную периодичность, к примеру.

      По поводу хостинга могу посоветовать только поменять его на нормальный.

  3. Спасибо за статью, как раз для Фоззи! А то я нарывал другую строчку по запуску крона и у меня в корне хостинга наспавнилось 14к пустых файлов wp-cron.php))))

Добавить комментарий