Wp cron


Cron — это команда UNIX, используемая для запуска периодически выполняемых задач, либо задач, которые должны быть запущены в определённое время.

Также важно упомянуть, что задачи WP-Cron не запускаются автоматически, просто при каждой загрузке страницы происходит сопоставление всех запланированных задач с текущим временем и, если время выполнения уже наступило, задача будет запущена. Это также значит, что если у вас запланирована задача на скажем 5:31 и если посещаемость вашего сайта не очень высокая, то задача скорее всего будет выполнена позднее указанного времени.

Наглядные примеры WP-Cron:

  • ну конечно же это проверка обновлений в WordPress, которая, если не ошибаюсь, происходит дважды в день,
  • запланированные посты,
  • также хороший пример, это когда премиумная подписка пользователя на сайте закончилась и его роль нужно поменять скажем с premium на subscriber.

Теперь давайте рассмотрим более практические примеры в рамках сайта на WordPress.

WP-Cron — это очень просто, однако я помню то время, когда боялся к нему подступиться. Просто читайте эту статью последовательно и сразу же выполняйте данные здесь примеры и этого будет достаточно, чтобы освоить планировщик задач в WordPress.

Проверим, работает ли WP-Cron у вас на сайте и если нет, попробуем исправить 


Обычно на сайтах WordPress с планировщиком всё окей, однако всё же бывают случаи, когда он не работает. Поэтому, прежде чем перейти к примерам, давайте убедимся, что с ним всё окей.

Делается это очень просто — нам нужно создать пост и в качестве даты публикации установить время в будущем, ну и понятное дело, чтобы долго ждать не пришлось, можно поставить время на 2 или 5 минут позже текущего.

Если WP_Cron работает на вашем сайте, то пост просто опубликуется через пару минут, а если не работает, то вот что вы получите:

Если у вас пост опубликовался, то можете пропустить следующую главу.

Как исправить WP_Cron? 

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

  1. Прежде всего попробуйте открыть файл wp-config.php и проверьте, нет ли там строчки, отключающей CRON define('DISABLE_WP_CRON', true);. Если есть, попробуйте её просто удалить и посмотрите, что получится.

  2. Если в wp-config.php всё в порядке, то… сами добавим эту строку… если быть точным, то мы попробуем подключить альтернативную конфигурацию планировщика, для это в wp-config.php помещаем следующий код:
  3. Если не помогло, то вы можете попробовать использовать системный планировщик в вашей хостинг-панели. Опять-таки нужно отключить (хотя он и так не работает) виртуальный WP_Cron строчкой:

    В хостинг-панели (например cPanel) вам нужно найти соответствующий инструмент планировщика. Заходим в него и в поле «Команда для выполнения» (или что-то типо того) указываем URL вашего файла wp-cron.php на сайте, а если быть точным, то:

  4. Всё ещё ничего не получается?.. Да пишите сразу в супорт хостинга со словами «че за фигня», если помочь не могут, то переходите на другой хостинг. Например на мой. Просто дело в том, что проблемы с виртуальным WP_Cron — это в большинстве случаев проблемы с сервером, а решать их должен именно супорт, я так считаю.

Попробуем запланировать собственную задачу, которая выполнится в определённое время 

Для этих целей в WordPress существует функция wp_schedule_single_event() (подробнее по ссылке, но переходить не обязательно, я и тут всё расскажу).

Пример 1. Пошагово. 

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


  • В первом параметре мы указываем время в UNIX-формате, в данном случае time() — текущее время, +60 — + 60 секунд, это значит, что событие запланируется на выполнение ровно через минуту после запуска функции.
  • Второй параметр — это название хука WordPress, который запустится через минуту. Про хуки и фильтры я обязательно подробно напишу отдельную статью. А пока что постараюсь просто подробно описать на примерах.

Окей, начало у нас есть, теперь вопрос — куда это вставить? Просто в functions.php не получится, ведь тогда событие будет пытаться запланироваться каждый раз при загрузке/обновлении любой страницы сайта.

Поэтому код непосредственно с запуском этой функции лучше всего добавлять в обработчики форм. Форма отправлена — событие запланировано. Всё просто.

Однако я воспользуюсь тем, что при смене темы WordPress на страницу передаётся параметр GET activated, равный true — в таком случае я смогу вставить код прямо в functions.php в следующем виде:

Это означает, что как только кто-то переключится на текущую тему, событие запланируется.

Хорошо, что же теперь делать с misha_action_hook


? Повторяю — это не функция! Просто очень частой ошибкой бывает, что люди начинают писать функцию function misha_action_hook(лалала) — это неправильно, а правильно будет так:

Незнакомая функция? Читайте подробнее про update_option().

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

Пример 1. Готовый код. 

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

Разве не просто?

И напоследок — у функции wp_schedule_single_event() есть ещё один, третий аргумент, который содержит параметры, передаваемые в хук, и тут я предлагаю вам два варианта — вы можете перейти по ссылке на функцию, чтобы почитать о ней подробнее там, либо переходите к следующему примеру, хоть он уже и про другую функцию, но параметр с аргументами работает у них одинаково.

Попробуем запланировать задачу, которая будет выполняться регулярно через определенные интервалы времени 

В этом нам поможет функция wp_schedule_event() (если хотите подробнее — перейдите по ссылке).

Пример 2. Пошагово. 

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

Значит сначала взгялнем на эту строчку кода:


  • В первом параметре указывается время первого выполнения задачи, при помощи функции time() я указал текущее время, то есть тот самый момент, когда функция будет запущена. Напоминаю, что время в UNIX-формате.
  • Второй параметр — это один из предопределенных вордпрессом интервалов времени, hourly — раз в час, twicedaily — дважды в день, daily — раз в день. О том, как задать собственный интервал, читайте ниже.
  • Третий параметр — это название хука, я надеюсь, что в предыдущем примере я хоть немного пролил на это свет и теперь хоть немного, но понятно, что это значит.
  • А вот четвертый — это одномерный массив из параметров, передаваемых в хук, в данном случае misha_hook_1.

Куда вставлять?

Тут я хочу обратить ваше внимание, что сколько раз вы запустите функцию wp_schedule_event(), то столько раз и запланируется повторяющееся событие!

А это значит, что по сути неважно, куда вы её вставите, главное сделайте проверку, что точно такая же задача уже не запланирована. В этом вам поможет функция wp_next_scheduled().

Событие считается уникальным, если хотя бы один из передаваемых параметров отличается.

Ну а дальше — функция и хук. Я не сказал вам, что моя цель — ежечасно отправлять себе сообщение с сайта.

Для отправки писем я использую стандартную функцию WordPress — wp_mail(). Обратите внимание, что необязательно создавать функцию misha_send()


, а можно сразу повесить wp_mail() на хук.

Пример 2. Готовый код. 

Ну и конечно же готовый код в одном листинге для вашего удобства.

Небольшой простой код — этот можно забацать прямо в functions.php.

Как задать свой собственный интервал? 

Если вас не устраивают стандартные вордпрессовские интервалы времени, вы с лёгкостью можете задать свой собственный.

Делается это предельно просто добавлением следующего хука в functions.php вашей темы:

Всё, интервал зарегистрирован, теперь можно использовать его имя kajd_3_min при планировке повторяющихся событий.

Как посмотреть все запланированные задачи 

Делается это довольно просто двумя способами — либо через плагин, либо через код. Если вам часто приходится мониторить, то конечно лучше и удобнее воспользоваться плагином, но обо всём по порядку.

Через код 

Cron-задачи хранятся в виде массива прямо в таблице wp_options базы данных. А значит их можно получить при помощи функции get_option(). И вот как это делается.


В результате они выведутся примерно в таком формате:

Используя плагин 

Зная из предыдущей главы, как выводятся задачи, вы теперь с лёгкостью и сами сможете написать плагин для мониторинга, а я поделюсь с вами тем плагином, который использую сам и в общем-то пока он меня устраивает — бесплатный Advanced Cron Manager (добавляйте прямо через админку). Если вы знаете плагины получше, прошу поделиться в комментариях ?

Заходим в Инструменты > Cron Manager и все задачи перед нами:

В колонке Schedule мы видим название интервала, single же означает, что задача выполнится только 1 раз, а затем сама удалится из расписания.

Конечно немного неудобно то, что в этом плагине не указывается сразу UNIX-штамп времени для каждой задачи, но его можно легко получить при помощи функции strtotime().

misha.blog

Публикация в группе: Otshelnik-Fm — мои работы (код, плагины, дополнения, статьи и руководства)

Категории группы: Работаем с Wp-Recall

Данная заметка позволит вам выявить проблемы в планировщике вордпресс (WordPress cron) и проверить его работу, принудительно запустив задание.


Про вордпресс крон в интернете написано много. Например тут, тут и здесь

Поэтому если что не найдете в этой заметке – не стесняйтесь – спрашивайте… Гугл.

Что есть WP-Cron:

Планировщик применяется для отложенных записей, для запроса обновлений и много для чего. Но мы тут собрались обсудить его работу с WP-Recall плагином.
Т.к. реколл использует дополнения – то им нужен функционал обновлений для верной работы с последними версиями реколл. Реколл отправляет письма пользователям о новых личных сообщениях и другие запланированные операции.

Плагин регистрирует три события:

  • rcl_cron_hourly_schedule — выполняется каждый час (отправка непрочитанных сообщений в личном чате)
  • rcl_cron_twicedaily_schedule — выполняется два раза в сутки (проверка обновлений аддонов)
  • rcl_cron_daily_schedule — выполняется один раз в сутки (удаление лимита переписки в чате, очистка кэша)

Проблемы?

Как правило, проблема становится заметна, когда не отправляются непрочитанные личные сообщения и если вы не видите обновления дополнений (а на сайте codeseller.ru вы видите — дополнения обновлены и прошло уже больше суток). Это звоночек что у вас проблема с вордпресс кроном.

В чем причины:

  • На низкопосещаемых сайтах (20 за сутки и менее просмотров. И реже чем раз в час) – т.к. крон вордпресса начинает работу только, если ваш сайт кто-то посещает. Если к примеру задание стоит на 2 часа ночи, а ваш сайт никто не посещает до 7-ми утра – есть вероятность что оно и не выполнится. Но в последних версиях вроде задание не «протухает» и выполняется даже через 4 часа и более. Но есть исключения.

  • Бывает на дешевых хостингах хостеры блокируют cron-job и крон не выполняется. – полезно спросить техподдержку хостинга о этом.
  • Есть вероятность что в файле wp-config-php  вписано вами давно и забыто:
  • Или в вашем используемом вордпресс шаблоне в файле functions.php (и всех тех, которые он подключает) вписан хук очистки определенного события крона wp_clear_scheduled_hook (не помешает переключиться временно на вордпресс тему по умолчанию twenty и проверить работу крона на ней)
  • Или вы установили плагин для блокирования крона или плагин безопасности – проверяйте отключив все плагины кроме WP-Recall

Ничего не нашли? что делать? Да и вообще хочу сам запустить:

Ставим плагин Advanced Cron Manager, активируем. Переходим в админке «Инструменты» — «Cron Manager» и нажимаем возле нужного события (описаны выше) кнопку «Execute». Например проверка обновлений аддонов rcl_cron_twicedaily_schedule. Нажали, через секунд 5 вверху увидели уведомление, переходим на страницу «WP-Recall» — «Дополнения». Должны высветиться обновления (если они на самом деле есть).

Wp cron


Дополнительно:

Крон события в логах сервера access.log пишутся так: POST /wp-cron.php?doing_wp_cron=*** и должен стоять ответ сервера 200

Если ответ сервера другой – задайте вопрос хостерам (если у вас нет доступа к настройкам сервера – обычный виртуальный хостинг)

Есть еще альтернативный крон ALTERNATE_WP_CRON – поисковые системы расскажут как его подключить.

Или настроить серверный крон — на виртуальных хостингах в панели управления в большинстве случаев есть такая возможность (спросите хостеров)

Заблуждение — вордпресс крон создает большую нагрузку!

не создает! Оно верно, только если у вас совсем гнилой и дешевый хостинг. Если ваш сайт имеет уникальных посетителей в день до 1000, вам и не должно приходить в голову отключать вордпресс крон. На дешевых хостингах вы столкнетесь не только с проблемой крона и перегрузок — так что переходите на нормальный хостинг.

Если у вас посетителей более 1000 в день — оптимизация нужна. Отключаете WP-cron, подключаете серверный (в интернете море информации по такой рокировке)

 

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

codeseller.ru

Что такое WP Cron

WP Cron — это встроенный в ядро WordPress планировщик, позволяющий выполнять различные задачи строго по заранее заданному расписанию, например:

  • Публикация запланированных записей;
  • Проверка обновлений ядра WordPress;
  • Проверка обновлений плагинов (если плагин зарегистрирован в репозитории плагинов WordPress);
  • Проверка обновлений тем (если тема есть в репозитории тем WordPress);
  • Рассылка email уведомлений;
  • И прочее подобное.

Преимущество WP Cron в том, что он абсолютно не зависит от настроек сервера и будет работать на любой платформе. Про недостатки будет ниже, когда дойдём до оптимизации настроек, а пока пару примеров, как создать и добавить своё событие в планировщик.

Как добавить событие в планировщик WP Cron

Нижеуказанный код можно вставить в functions.php или создать MU плагин

// 0 шаг - можно добавить свой интервал, например, 6 часов  add_filter( 'cron_schedules', function ( $schedules ) {     $schedules['every6hours'] = array(   // HOUR_IN_SECONDS - специальная константа, содержит число секунд в 1 часе. Умножаем на 6 часов.   'interval' => 6 * HOUR_IN_SECONDS,   'display' => __( 'Every 6 hours' ),   );     return $schedules;  } );    // 1 шаг - добавляем в WP Cron новое событие  add_action( 'init', function () {  	  	// Если событие ещё не зарегистрировано в планировщике  	if ( !wp_next_scheduled( 'sheensay_new_event' ) ) {  		  		// Добавляем его, стартуя прямо сейчас, с периодом "hourly (раз в час)". А назовём его sheensay_new_event  		// Если включили предыдущий фильтр, то можно использовать его. В нашем случае: "every6hours" (каждые 6 часов)  		wp_schedule_event( time(), 'hourly', 'sheensay_new_event' );  		// wp_schedule_event( strtotime('03:00:00'), 'hourly', 'sheensay_new_event' ); // Стартуем в 3 ночи  	}  } );    // 2 шаг - описываем подробно, что будем делать, когда наступит очередь событие исполнять "sheensay_new_event"   add_action( 'sheensay_new_event', function () {    	// Допустим, нужно удалять все Записи старше 10 дней    	// Получим все Записи  	$p = get_posts( [  		'post_type' => 'post',  		'posts_per_page' => -1,  			] );    	// Если записи есть, переберём их  	if ( $p ) {  		foreach ( $p as $post ) {  			  			// 10 дней живёт запись  			$days = 10;    			// DAY_IN_SECONDS - сколько секунд в 1 дне - это специальная константа, определённая в WordPress  			$offset = $days * DAY_IN_SECONDS;     			// Если Запись старше, чем 10 дней, удаляем её  			if ( get_post_time( $d = 'U', $gmt = TRUE, $post ) < time() - $offset ) {  				  				// Удаляем Запись в корзину, оттуда она позже удалится автоматически  				wp_delete_post( $post -> ID );  			}  		} unset( $post );  	}  } );  

Полный список волшебных констант времени в WordPress:

  • MINUTE_IN_SECONDS — число секунд в минуте;
  • HOUR_IN_SECONDS — число секунд в часе;
  • DAY_IN_SECONDS — число секунд в дне;
  • WEEK_IN_SECONDS — число секунд в неделе;
  • MONTH_IN_SECONDS — число секунд в месяце;
  • YEAR_IN_SECONDS — число секунд в году.

Это был абстрактный пример. Вы можете легко адаптировать схему под себя.
А для отладки, чтобы понять, работает ли код, я рекомендую использовать плагин WP Crontrol (про него далее).

WP Crontrol — плагин отладки расписания запланированных событий WordPress

WP Crontrol — это очень полезный плагин, который позволяет:

  • Просматривать все события WP Cron вместе с аргументами, периодичностью повторений, функциями, которые они вызывают (callback), а также их запланированными действиями;
  • Редактировать, удалять, а также запускать сиюминутно любое событие крона (очень сильно выручает при отладке событий);
  • Добавлять новые события в расписания;
  • Добавлять, редактировать и удалять собственные расписания в WP Cron.

Очень рекомендую использовать, всё наглядно и удобно.

Скачать WP Crontrol из официального репозитория Wordress.org

Итак, возвращаясь к предыдущей теме, если добавили код из вышеуказанного примера, то в списке событий Events http://example.com/wp-admin/tools.php?page=crontrol_admin_manage_page должно появиться новое событие sheensay_new_event
Список событий в WP Crontrol

Если событие sheensay_new_event не появилось, попробуйте загрузить любую страницу сайта с фронтенда, например, главную. Тогда сработает хук wp, и событие добавится в планировщик.

Теперь достаточно справа от нужного события нажать на Run Now и проверить результат (в нашем случае, не отправились ли старые записи в корзину).
Как видите, эта тема довольно проста в освоении. Если возникнут дополнительные вопросы, задавайте в комментариях. Далее, про настройку и оптимизацию WP Cron.

Недостатки WP Cron

Вся суть механизма работы встроеного планировщика заключается в том, что при каждом посещении сайта на WordPress любым пользователем идёт обращение к файлу wp-cron.php. Тот, в свою очередь, при каждом обращении проверяет расписание, и если время исполнения какого-то события в очереди наступило или уже прошло, то запускает его. Отсюда, понятно, какие могут быть недостатки у данного подхода:

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

Отсюда вывод — если есть возможность, постарайтесь настроить серверный cron взамен встроенному, а встроенный WP Cron отключить (инструкция будет далее).

Как правильно отключить WP Cron

в wp-config.php находим строку define( 'WP_DEBUG', false ); и под ней прописываем:

define('DISABLE_WP_CRON', true);

Если отключить стандартный WP Cron, строго необходимо настроить ему замену, так как иначе перестанут выполняться задачи по расписанию, например, не будут опубликовываться запланированные записи. Идеально подойдёт серверный планировщик задач, обычный cron, который есть в любом нормальном сервере (подробнее далее).

Как заменить WP Cron на серверный планировщик cron

Сначала отключаем WP Cron, в wp-config.php прописываем где-нибудь в начале файла, как было в примере выше:

define('DISABLE_WP_CRON', true);

Затем запускаем команду в консоль SSH

crontab -e

Откроется файловый редактор планировщика cron со всеми существующими расписаниями.
Далее, есть несколько вариантов (выберите один из них, я рекомендую первый):

Используем WP CLI
* * * * * cd /var/www/example.com/public_html; /usr/local/bin/wp cron event run --due-now --allow-root > /dev/null 2>&1

Здесь мы каждую минуту командой cd /var/www/example.com/public_html переключаемся в каталог с файлами сайта (в корень сайта), а wp cron event run --due-now --allow-root делаем запрос php к wp-cron.php с помощью WP CLI.
Это вариант имеет свои тонкости: php тут запускается из консоли, и потому пригодится, скажем, если на сервере закрыты порты 80 или 443, и wget или curl бессильны.

WP CLI работает в режиме PHP-CLI, а значит, что на исполнение php нет временных лимитов. Это означает:

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

Поэтому, тут решайте самостоятельно, взвесив плюсы и минусы, выбирать ли WP CLI или нет.

Или используем php
* * * * * cd /var/www/example.com/public_html; php wp-cron.php doing_wp_cron > /dev/null 2>&1

Здесь мы каждую минуту командой cd /var/www/example.com/public_html переключаемся в каталог с файлами сайта (в корень сайта), а php wp-cron.php делаем запрос php к wp-cron.php
Это вариант с php пригодится, скажем, если на сервере закрыты порты 80 или 443, и wget или curl бессильны.

Или используем wget
* * * * * wget -q -O - http://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Это правило каждую минуту с помощью wget обращается к файлу крона http://example.com/wp-cron.php?doing_wp_cron WordPress, тем самым заставляя регулярно запускаться запланированные в WP Cron события.

  • Из плюсов — wget стоит практически на любой машине по умолчанию.
  • Из минусов — его разработка ведётся долго, и потому он не поддерживает нормально https и другие некоторые опции, доступные curl. К тому же, проблемы могут возникнуть, если запросы к сайту блокируется по портам.
Или используем curl
* * * * * curl -O http://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Это правило каждую минуту будет посылать запросы с помощью curl к http://example.com/wp-cron.php?doing_wp_cron.

  • Плюсы curl — это продвинутый вариант wget, много опций с возможностью менять протоколы, user-agent, принудительный TLS, возможность сжимать ответ и многое другое.
  • Минусы — не всегда идёт по умолчанию с ПО сервера, и нужно устанавливать отдельно. Однако, в Ubuntu и Debian делается это легко:
    apt-get install curl php5-curl
  • Ещё минус — бывает, что сервер не принимает запросы (например, защита от парсеров)

Одну из вышеуказанных команд добавляете в конце файла (example.com заменяете на свой домен).

Работаем в putty. Инструкция для стандартного редактора nano (не vim, для vim инструкция ниже):

  1. Прописываем одну из вышеуказанных команд;
  2. Выходим Ctrl+X;
  3. На выходе спросят, сохранять ли изменения. Сохраняем Y;
  4. Имя файла для записи — оставляете без изменения — Enter;
  5. Если увидите подпись crontab: installing new crontab, значит изменения были сохранены

Если редактором выступает vim:

  1. Включам режим редактирования — Insert;
  2. Вносим правила в конец файла (примеры рассматривали выше);
  3. После внесения изменений отключаем режим редактирования — Esc;
  4. Сохраняем изменения — Shift+: (двоеточие), в появившемся поле вводим wq и сохраняем Enter;
  5. Если увидите ответ crontab: installing new crontab, значит изменения были сохранены и вступили в силу.

Чтобы выбрать подходящий редактор, можно воспользоваться командой

select-editor

Выбираем подходящий редактор командной строки Linux

Если хотите проверить, применились ли изменения к расписанию крона, воспользуйтесь командой crontab -l

Если у вас есть панель управления хостингом, возможно, там есть функционал, позволяющий задавать собственное расписание для планировщика cron. В таком случае, просто пропишите там правило обращаться раз в 5 минут к адресу http://example.com/wp-cron.php?doing_wp_cron (подставьте свой домен вместо example.com).

Ошибки, связанные с WP Cron

There was a problem spawning a call to the WP-Cron system on your site

There was a problem spawning a call to the WP-Cron system on your site. This means WP-Cron events on your site may not work. The problem was: cURL error 7: Failed to connect example.com port 80 443: connection refused

Ошибка выше означает, что curl не может получить доступ к сайту по стандартным портам 80 или 443.
Вы можете решить эту проблему, включив альтернативный вариант для работы WP Cron, прописав в wp-config.php:

define('ALTERNATE_WP_CRON', true);

Однако, у этого подхода есть недостаток — иногда к адресам страниц будут добавляться параметры ?doing_wp_cron=. Если Вас это не смущает, выбирайте его, он самый простой в настройке. Если нет — расскажу, как убрать doing_wp_cron из адреса страницы и настроить серверный планировщик cron взамен WP Cron.

Убираем doing_wp_cron из URL

?doing_wp_cron= появляется в адресе страницы, когда используется альтернативная версия ALTERNATE_WP_CRON, то есть, в корне сайта в файле wp-config.php определена константа:

define('ALTERNATE_WP_CRON', true);

Как правило, её включают, когда WP Cron не работает в стандартном варианте. Вам нужно постараться избежать её использования:

// Отключаем альтернативную версию WP CRON  define('ALTERNATE_WP_CRON', false);

Если WP Cron не заработает или будет выдавать ошибку в работе, можно полностью отключить WP Cron и использовать серверный крон (подробнее были выше).
Также, не лишним будет настроить редирект с ?doing_wp_cron= на оригинальную версию страницы:

Как сделать редирект из ?doing_wp_cron= в NGINX
# В секции location /  location / {   # ...   if ( $arg_doing_wp_cron ) { # Если в query string есть запрос ?doing_wp_cron=   return 301 $uri; # Редиректим на основной адрес   }   # Тут обычно далее идёт try_files $uri $uri/ /index.php?$args   # ...  }  
Как сделать редирект из ?doing_wp_cron= в .htaccess (Apache)
# Прописываем блок в самом начале .htaccess  <IfModule mod_rewrite.c>   RewriteEngine On   RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= [NC]   RewriteRule (.*) /$1? [R=301,L]  </IfModule>

Я отключил WP Cron, но в логах access.log снова появляется POST /wp-cron.php?doins_wp_cron?параметры

Бывает так, что, казалось бы, WP Cron отключен (всё сделано по инструкции выше), однако, в логах всё равно появляются отметки о том, что идут стандартные запросы

127.0.0.1 - - [08/Jun/2017:06:38:49 +0300] "POST /wp-cron.php?doing_wp_cron=1496893129.1262209415435791015625 HTTP/1.0" 200 236 "https://sheensay.ru/wp-cron.php?doing_wp_cron=1496893129.1262209415435791015625" "WordPress/4.7.5; https://sheensay.ru"

Дело в том, что тут может быть так, что Вы неверно прописали отключение WP Cron, а именно, строку define('DISABLE_WP_CRON', true); прописали в самом конце файла wp-config.php. Обязательно перенесите её к define('WP_DEBUG', false);:

define( 'WP_DEBUG', false );  define( 'DISABLE_WP_CRON', true );  

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

sheensay.ru

Поскольку WordPress должен работать на всех различных платформах, ОС и конфигураций, он не может рассчитывать, что служба cronjob будет на сервере, который может обрабатывать запланированные задачи. Вот почему разработчики CMS WordPress создали обходной путь – файл wp-cron.php в основной папке, WordPress запускает каждый раз, когда кто-то загружает страницу. Затем он проверяет, есть ли запланированное задание, которое должно быть сделано, и выполняет его в случае необходимости.

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

Во- первых, вам необходимо отключить файл, чтобы он не запускался каждый раз, когда кто – то загружает страницы. Для этого откройте файл wp-config.php в корневой папке WordPress и добавьте эту строку в конце, перед закрытием тега ?>:

DEFINE ( 'DISABLE_WP_CRON', TRUE);

После того, как вы сделаете это, вам нужно настроить реальную крон и выполнить этот файл. Если Вы не хотите, чтобы крон вызвался слишком часто, тогда поставьте 30 минут,  это должно быть хорошо для большинства веб – сайтов. Для этого, войдите в свой CPanel и перейти к инструменту CronJob, который находится в вкладке Advanced.

Выбрать Cron jobs на хостинге

Затем добавьте следующую команду, которая будет выполняться каждые 30 минут:

/usr/local/bin/php /home/user/public_html/wp-cron.php

Вы должны заменить / user / с вашим действительным именем пользователя Cpanel. Инструмент CronJob имеет некоторые из наиболее распространенных расписаний заранее, так что вы можете просто выбрать каждые 30 минуты из раскрывающегося списка и поместите * символ в других.

Настройки крона на хостинге

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

andreyex.ru

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

wpcronmanage[1]

Что такое WordPress Cron? Как он работает?

Cron — это технический термин, который используется для запуска команд в заданное время или через определенные интервалы. Большинство веб-серверов используют его для обслуживания и запуска запланированных задач.

В WordPress есть собственная система cron, которая позволяет ему выполнять регулярные задачи. Например, проверка обновлений, удаление старых комментариев из корзины и т.п.

Плагины также могут использовать cron для указанных вами задач.

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

Нерациональное использование WordPress cron плагинами может замедлить ваш сайт, особенно, не на выделенном сервере.

Если плагин очень часто выполняет ресурсоемкие задачи, то нужно разбираться в проблеме и исправлять её.

Давайте же посмотрим как можно просматривать и управлять системой WordPress cron.

Просмотр и управление системой WordPress Cron

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

После активации переходим на страницу Инструменты » Cron Events для настройки.

wpcronevents[1]

Вы увидите список всех событий cron, назначенных на выполнение на сайте в системе WordPress cron.

В первом столбце указано название хука, запускающего планировщик.

Как правило, названия хуков дадут вам подсказку о том, что именно выполняет конкретное событие.

Большинство стандартных хуков WordPress начинаются с префикса wp_, как например wp_update_plugins, wp_update_themes и т.п.

Ваши плагины могут использовать свои собственные префиксы для хуков. Например, yoast seo использует wpseo_ prefix.

Также вы увидите, когда задача запустится в следующий раз, а также интервалы между запусками.

В последнем столбце вы можете удалять, редактировать и запускать события cron.

Важно: Будьте осторожны при работе с событиями, и никогда не удаляйте стандартные события WordPress.

Теперь давайте представим, что вы видите событие, созданное плагином WordPress, которое потребляет много ресурсов.

Для начала вам нужно проверить настройки плагина на предмет настройки, которую можно отключить при необходимости. Если таковой не окажется, тогда нажимаем на ссылку ‘Edit’ рядом с событием cron для его изменения.

wpcronedit[1]

Нажав на кнопку Edit, вы увидите вкладку ‘Modify cron event’.

Здесь можно изменить частоту выполнения события.

modifycronsettings[1]

По окончанию настройки нажмите на кнопку сохранения изменений.

Добавляем свои собственные события в Cron в WordPress

Плагин WP Control позволяет легко добавлять свои собственные задачи в крон WordPress. Для этого переходим на страницу Инструменты » Cron Events и прокручиваем до вкладки ‘Add Cron Event’.

addcronevent[1]

Первым делом вам потребуется указать название хука для события. В названии не должно быть пробелов или спецсимволов.

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

Далее, указываем время запуска задачи. Можно ввести ‘now’, и при этом cron сработает моментально, или же ‘tomorrow’, ‘+2 days’, или ’25-02-2020 12:34:00?.

И, наконец, нужно выбрать расписание: ежечасное выполнение, дважды в день, ежедневно, или один раз в неделю. Можно создавать не повторяющиеся события.

По окончанию нажмите на кнопку Add Cron Event для сохранения изменений.

Вы заметите, что созданное событие появится в общем списке. Однако, оно не будет делать ничего, потому как вы не сообщили WordPress о том, что именно нужно делать.

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

  if ( ! wp_next_scheduled( 'wpb_custom_cron' ) ) {   wp_schedule_event( time(), 'hourly', 'my_task_hook' );  }    add_action( 'wpb_custom_cron', 'wpb_custom_cron_func' );    function wpb_custom_cron_func() {   wp_mail( 'you@example.com', 'Automatic email', 'Automatic scheduled email from WordPress to test cron');  }  

Не забудьте указать свой email адрес.

Эта функция просто отправит тестовое письмо при выполнении задачи по крону. Можно прокрутить страницу вверх и нажать на ссылку ‘Run Now’ рядом с событием, чтобы его протестировать.

Примечание: Использование cron предполагает навыки среднего уровня в программировании, а также в разработке WordPress. Такая рекомендация указана с целью того, чтобы вы сумели самостоятельно написать нужную функцию, которая будет выполняться при срабатывании триггера планировщика крона.

Вот и все, мы надеемся, что эта статья помогла вам научиться просматривать и контролировать задачи в WordPress cron.

По всем вопросам и отзывам просьба писать в комментарии ниже.

Не забывайте, по возможности, оценивать понравившиеся записи количеством звездочек на ваше усмотрение.

wpincode.com

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

Итак, за те 10 лет, которые прошли с момента первого релиза, WordPress превратилась из небольшой системы управления содержимым с открытым исходным кодом в мощный инструмент для создания веб-сайтов практически любой сложности. Я считаю, что на данный момент эта лучшая платформа для создания сайтов-визиток, блогов и прочих ресурсов, предназначенных для получения информации. Несомненно, за все это время система была «отполирована» и оптимизирована как нельзя лучше, однако и сейчас встречаются проблемы с которыми приходится бороться самостоятельно, редактируя и правя исходный код. Широкие функциональные возможности WordPress несут не только блага, но и проблемы, об одной из которых речь пойдет дальше.

Предыстория

Начну с предыстории. Совсем недавно один из сайтов, за которым я присматриваю около 5-ти месяцев, рухнул, гордо выдавая ошибку 504. Работает, как вы поняли, он под управлением WordPress (версия 3.4.2), а сам ресурс расположен на виртуальном хостинге, который администрируется при помощи cPanel.

В то время когда появились проблемы с доступом к сайту, количество запущенных процессов на сервере возросло. Одновременно увеличилась загрузка процессора и объем используемой оперативной памяти. Среди множества ничем непримечательных GET-запросов в логах, удалось обнаружить следующий POST-запрос:

93.125.XXX.XXX — — [26/Jun/2013:17:27:24 +0300] «POST /wp-cron.php?doing_wp_cron=1372256843.9632339477539062500000 HTTP/1.0» 200 — «-» «WordPress/3.4.2; http://www.xxxxx.xx»

Из него можно понять, что сам WordPress делает POST-запрос к своему же скрипту wp-cron.php. Время обращения к данному файлу совпадало с временем, когда начались проблемы с доступом к сайту и поэтому я решил разобраться, что же происходит внутри скрипта wp-cron.php.

Что делает wp-cron.php

wp-cron.php — это скрипт, который отвечает за периодический запуск различных задач. К таким задачам например относятся:

  • проверка обновлений WordPress и установленных плагинов;
  • запланированная публикация постов;
  • рассылка уведомлений о новых комментариях и прочих событиях;
  • запуск плагинов, таких например как Akismet для фильтрации комментариев на наличие спама;
  • оповещение сторонних сервисов о публикации нового материала;
  • и др.

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

Отключение wp-cron.php

Очевидным решением для снижения нагрузки на сервер является отключение периодического запуска скрипта wp-cron.php. Делается это добавлением всего одной строчки в конфигурационный файл WordPress wp-config.php.

Просто добавьте этот код в начало или конец wp-config.php.

define('DISABLE_WP_CRON', true);

Далее у вас есть выбор: оставить скрипт wp-cron.php отключенным навсегда или создать свою cron-задачу для запуска его с определенным интервалом. Хотя первый вариант позволит вам избавиться от нагрузок на сервер, я склоняюсь ко второму, поскольку каким бы «тяжелым» не было выполнение данного скрипта, он делает действительно необходимую и полезную работу. У вас может возникнуть вопрос: «Зачем тогда вообще отключать автоматическое выполнение wp-cron.php?». Дело в том, что сам WordPress может запустить его несколько раз в день, а, создав собственную cron-задачу, вы можете контролировать данный процесс и установить время, когда сайт, скажем, нагружен меньше всего.

Если для администрирования хостинга вы используете cPanel, то воспользуйтесь инструкцией по созданию cron-задач . Команда, которая выполнит скрипт wp-cron.php представлена ниже. Это простой GET-запрос к wp-cron.php и выводом результата в /dev/null.

wget http://www.vashdomen.com/wp-cron.php?doing_wp_cron > /dev/null

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

Заключение

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

www.sitedev.by

За что отвечает wp-cron.php

wp-cron.php это скрипт, который выполняет ряд задач, а именно:

  • публикация отложенных постов;
  • проверка обновлений (WP, плагины и шаблоны);
  • рассылка уведомлений о новых комментариях;
  • оповещение о новых постах;

и так далее.

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

Отключение wp-cron.php

Очевидным решением в такой ситуации для нас стал отключение автоматического запуска wp-cron.php самим WordPress. Делается это достаточно просто. Добавьте такой код в конфигурационный файла wp-config.php  (например после define (‘WPLANG’, ‘ru_RU’); )

define('DISABLE_WP_CRON', true);

Таким образом мы избавились от столь частого автоматического запуска wp-cron.php. Однако, как мы помним задачи он выполняет достаточно важные. Следовательно запуск его необходим. Поэтому необходимо добавить cron задачу на сервере следующего вида

curl "http://domen.com/wp-cron.php?doing_wp_cron"

Частоту запуска можно определить самостоятельно, в зависимости от потребностей. В нашем случае клиенту был установлен интервал запуска раз в 10 часов.

Заказать качественный VDS

friendhosting.net

WordPress has something called wp-cron. If you haven’t read about it, its fine. But please be aware that you cannot live without it! That is why, I am not asking you to disable wp-cron.

Disable wp-cron

Still, we need to disable WordPress default wp-cron behaviour by adding following line to wp-config.php file:

define('DISABLE_WP_CRON', true);

Setup a real cronjob

From your Linux terminal, first open crontab:

crontab -e

Then add a line like below in it.

*/10 * * * * curl http://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
OR
*/10 * * * * cd /var/www/example.com/htdocs; php /var/www/example.com/htdocs/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Please make sure you use correct path to wp-cron.php.

Alternately, you can also use WP-Cli

*/10 * * * * cd /var/www/example.com/htdocs; wp cron event run --due-now > /dev/null 2>&1

Above will run wp-cron every 10 minutes. You can change */10 to */5 to make it run every 5 minutes.

Difference between two-lines is, first one uses PHP-FPM (or PHP-CGI) and second one uses PHP-CLI. CLI scripts do not have time limits. Depending on your setup, it may be desirable or undesirable.

Is it recommend for high-traffic site?

I haven’t digged into wp-cron a lot but what I know is that it executes on every page-load. So if there is a long running process which gets triggers by wp-cron, it will delay page loading for that user.

Using crontab, wp-cron is run by independent PHP process. So it will not interfere with any visitors page-request.

Because of this, we highly recommend running wp-cron via linux crontab rather than WordPress’s default way, irrespective of size or traffic of your site.

easyengine.io


You May Also Like

About the Author: admind

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

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

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