Схоже, WordPress зайво запускає WP CRON на кожному завантаженні сторінки. Я думаю, замість того, щоб він працював на кожному відвідуванні, чому б просто не запланувати його запуск кожні 5 хвилин через сервер? Я міг би просто запустити wp-cron.php кожні п’ять хвилин і досягти бажаного результату?
Чи є якийсь мінус у цьому?
Відповіді:
Немає жодних недоліків для запуску WP CRON з використанням завдань cron сервера. Насправді це рекомендована практика.
Згідно з офіційним документом щодо розробки плагінів WordPress :
WP-Cron не працює постійно, що може бути проблемою, якщо є критичні завдання, які повинні виконуватися вчасно. Для цього є просте рішення. Просто налаштуйте планувальник завдань вашої системи для роботи на потрібні інтервали (або в певний час, необхідний).
Для цього потрібно спочатку відключити поведінку cron за замовчуванням у wp-config.php:
define('DISABLE_WP_CRON', true);Потім плануйте wp-cron.phpз вашого сервера. Для Linux це означає:
crontab -eОднак замість запуску в командному рядку (CLI) запустіть його як HTTP-запит. Для цього ви можете використовувати wget:
*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronWordPress завантажує всі необхідні основні файли, додатки тощо у wp-cron.phpнаступному КОДІ:
if ( !defined('ABSPATH') ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . '/wp-load.php' );
}
Тому не хвилюйтеся, що WordPress не завантажує важливі функції.
define('DISABLE_WP_CRON', true);вимикає лише ту частину процесу cron, а потім викликає скрипт cron з таким кодом: */5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronна сервері гарантує виконання завдань cron. Будь-який плагін планування навіть не знатиме різниці.
Є кілька недоліків: По-перше, при використанні wp-cron.php як кліпу такі речі, як $ _SERVER змінні, не встановлюються. Люди долають це обмеження, використовуючи запит на згортання замість wp-cron.php.
По-друге, тому що сам WP не завантажений wp-cron.php; якщо ви використовуєте плагін SMTP-пошти, він не завантажується під час виклику wp-cron. Знову ж, використання виклику curl вирішує цю проблему. Здається, Curl є найбільш часто використовуваним методом.
Однак; Я вважаю за краще використовувати wp-cli після встановлення налаштувань пошти у postfix та (для nginx) php-fpm config config та встановлення crontab, таких як
*/5 * * * * wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1(Перерахуйте всі крони із специфічними полями у форматі csv - гачок називається cron; час наступного запуску - час. Скрепіть ті, що показують "зараз" як наступний запуск (ті, що належать зараз) за допомогою AWK, передайте цей список xargs до зателефонуйте wp cron event run $HOOKдо кожного cron.) Використання wp-cli завантажує WordPress правильно (я вибираю пропускати плагіни при переліку кронів, оскільки помилки коду та php попередження викручують сценарій виводу; але не пропускати їх під час запуску cron з xargs, як може знадобитися завантаження плагінів)
Сподіваюсь, це дає вам деякі вказівки, на що слід звернути увагу.
Є багато причин не вимкнути wp-cron. Насправді майже неможливо знайти випадок використання для цього. Це не сповільнює ваш сайт, і він використовується для речей, про які ви можете не знати.
Багато плагінів використовують WP-Cron для планування речей. Вони можуть заплутатися, якщо вимкніть планувальник.
Існує поширення навчальних посібників з цього приводу, тому що це заплутано і тому, що він не робить багато вашому сайту, коли ви його відключаєте. Що це зробить, це заподіяти головний біль дияволу, який повинен виправити таємничу проблему, яку він створює за півроку.
Крім того, WP Heartbeat спрацьовує кожні 15 секунд в області адміністратора, вирішуючи це питання для 99% людей, які думають, що вони мають.
Я ще не можу знайти справжній мінус для завантаження wp-cron на зовнішнє обслуговування. Робимо це вже багато років.
Особливо в світі сьогодні, де можна запускати програми як мікросервіси.
Я використовую окремі контейнери Docker для кожного компонента WordPress - php, web, db, crontab, redis тощо). Маючи crontab як окремий контейнер, викликаючи wp-cron через http за допомогою локальної мережі, працює лише тоді, коли мені це потрібно.
Це зменшує навантаження на резервні вузли та покращує безпеку за рахунок меншої поверхні атаки.
Якщо розробник не може зрозуміти, як робити речі, не викликаючи wp-cron під час кожного завантаження сторінки, чорт, це просто говорить про недосвідченість від його імені. "Залишаючи це в спокої", тому що ти не розумієш, як все працює, - це не вагомий привід зберегти це.
wget http://YOUR_SITE_URL/wp-cron.phpбез додавання.?doing_wp_cronТак, що, краще один з інших? Що додає те?doing_wp_cron, що неверсія не має?