Как найти и отключить лишние cron-задачи в WordPress

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

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

Когда cron-задачи действительно мешают

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

• в админке заметны паузы при сохранении записей или открытии страниц;
• на хостинге растёт число медленных PHP-запросов;
• в логах видны повторяющиеся обращения к wp-cron.php;
• одни и те же задания выполняются слишком часто;
• после удаления плагина остались его события в расписании.

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

Диагностика проблемы: что проверить в первую очередь

Посмотреть расписание WP-Cron

Самый практичный способ — вывести список событий через WP-CLI, если он доступен. Это быстрее и точнее, чем искать вручную в базе:

wp cron event list

Команда покажет hook, время следующего запуска и интервал. Ищите:

• события с подозрительно частым интервалом;
• hook-и, которые относятся к удалённым плагинам;
• много одинаковых строк с разными временными метками;
• задачи, которые постоянно перезапланируются.

Если WP-CLI нет, можно временно поставить отладочный плагин для просмотра cron-событий или использовать код ниже на тестовом сайте.

Проверить, какие события зарегистрированы

Для быстрой диагностики удобно вывести список cron-расписания в админке или в лог. Вот безопасный пример для functions.php дочерней темы или собственного мини-плагина:

add_action('admin_init', function () {
    if (!current_user_can('manage_options')) {
        return;
    }

    $crons = _get_cron_array();

    error_log('--- WP Cron events ---');
    foreach ($crons as $timestamp => $hooks) {
        foreach ($hooks as $hook => $events) {
            error_log($timestamp . ' | ' . $hook . ' | count: ' . count($events));
        }
    }
});

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

Как отключить лишнее событие без поломки сайта

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

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

register_deactivation_hook(__FILE__, function () {
    $timestamp = wp_next_scheduled('my_plugin_cleanup_event');
    if ($timestamp) {
        wp_unschedule_event($timestamp, 'my_plugin_cleanup_event');
    }

    $next = wp_next_scheduled('my_plugin_daily_event');
    if ($next) {
        wp_unschedule_event($next, 'my_plugin_daily_event');
    }
});

Если нужно убрать все повторяющиеся запуски hook-а, удобнее использовать wp_clear_scheduled_hook():

if (function_exists('wp_clear_scheduled_hook')) {
    wp_clear_scheduled_hook('my_plugin_daily_event');
}

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

Сравнение подходов: плагин, код или серверный cron

Пошаговое решение для боевого сайта

1. Сделайте резервную копию базы и файлов.
2. Снимите список cron-событий через wp cron event list или отладочный код на тестовой копии.
3. Отметьте hook-и, которые относятся к удалённым плагинам или явно дублируются.
4. Проверьте, не использует ли плагин один hook с разными аргументами.
5. Удалите только то, что понимаете: через wp_clear_scheduled_hook() или wp_unschedule_event().
6. После очистки проверьте, не создаются ли события снова при следующем заходе на сайт.

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

Как проверить, что решение сработало

Проверка должна быть не на глаз, а по факту:

• в wp cron event list больше нет удалённого hook-а;
• в логах исчезли повторяющиеся обращения к wp-cron.php от этого события;
• админка открывается без заметных пауз в моменты запуска задачи;
• если был дублирующийся cron, количество записей в расписании уменьшилось;
• после нескольких часов работы событие не появилось снова без причины.

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

Частые ошибки и как их исправить

Удаляют не тот hook

Название hook-а может быть похоже на нужный, но отличаться суффиксом или префиксом. Если удалить лишнее, плагин начнёт работать нестабильно. Решение простое: сначала смотрите список событий целиком и сверяйте имя hook-а с кодом плагина.

Не учитывают аргументы события

Некоторые cron-задачи регистрируются с аргументами. В таком случае wp_clear_scheduled_hook() может убрать не всё, а wp_unschedule_event() требует точного timestamp. Если видите несколько одинаковых hook-ов, проверьте аргументы в расписании.

Чистят расписание, но не источник проблемы

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

Оставляют WP-Cron без контроля на нагруженном сайте

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

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

Не держите диагностический код в продакшене дольше, чем нужно. Любой вывод в лог или админку должен быть временным. Если задача касается большого сайта, сначала проверяйте изменения на staging-копии. И ещё один полезный момент: не ставьте слишком частые интервалы для задач, которые не требуют минутной точности. Чем чаще cron, тем выше шанс создать лишнюю нагрузку при обычном трафике.

Если вам нужно регулярно чистить мусорные события, имеет смысл оформить это как небольшой mu-plugin или отдельный мини-плагин с понятной деактивацией. Так вы не потеряете контроль после смены темы и не привяжете инфраструктурную логику к шаблону оформления.

Для сайтов, где cron используется как часть контентной или SEO-автоматизации, полезно также периодически пересматривать список активных плагинов. Часто лишние задания остаются после тестов, миграций и временных интеграций — именно они потом незаметно копятся в расписании.