Сломался 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: 9 комментариев

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

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

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

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

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

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

  4. А как узнать выключился крон или нет? Удалил строки из конфига, но очу убедиться. Потому что изза этого редиректа doing cron вылетили страницы из поиска

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *