Как устранить низкую производительность wp-admin / admin-ajax.php и высокую загрузку процессора

Медленная административная панель WordPress — одна из тех проблем, которые могут появиться неожиданно даже на сайте, который раньше работал быстро. Страницы /wp-admin/ начинают открываться по несколько секунд, редактор зависает, сохранение записей занимает слишком много времени, а в статистике хостинга процессор периодически загружается до 80–100%.

При анализе логов в таких ситуациях часто обнаруживается большое количество запросов к /wp-admin/admin-ajax.php. Однако сам admin-ajax.php обычно не является источником проблемы. Это штатный AJAX-обработчик WordPress, через который выполняются Heartbeat API, функции плагинов, фоновые операции и другие динамические задачи.

Поэтому главная задача — не заблокировать admin-ajax.php, а определить, какой процесс вызывает его слишком часто или выполняет слишком тяжёлые операции.

Краткий ответ: если wp-admin работает медленно, а admin-ajax.php создаёт высокую нагрузку на CPU, сначала найдите AJAX-действие (action), которое генерирует запросы. Чаще всего причиной становятся WordPress Heartbeat API, плагины, WP-Cron или WooCommerce Action Scheduler. Ограничьте лишние запросы, оптимизируйте фоновые задачи, базу данных и PHP, после чего повторно измерьте нагрузку.

Что такое admin-ajax.php и почему он появляется в отчётах о нагрузке

admin-ajax.php — системный файл WordPress, расположенный по адресу:

/wp-admin/admin-ajax.php

Он принимает AJAX-запросы и позволяет браузеру взаимодействовать с WordPress без полной перезагрузки страницы.

Например, AJAX может использоваться для:

• автоматического сохранения записи;
• блокировки одновременного редактирования;
• обновления информации в Dashboard;
• AJAX-поиска;
• фильтрации товаров;
• отправки форм;
• обновления корзины;
• работы некоторых функций WooCommerce;
• выполнения фоновых операций плагинов;
• получения уведомлений;
• динамической загрузки данных.

Поэтому присутствие admin-ajax.php в access log — абсолютно нормальное явление.

Проблема начинается тогда, когда запросов становится слишком много или выполнение одного AJAX-запроса занимает слишком много процессорного времени.

Например, один запрос может занимать всего 100–200 мс. Это практически незаметно.

Но если сайт одновременно генерирует сотни таких запросов, PHP-процессы начинают конкурировать за CPU, память и соединения с базой данных.

В результате замедляется не только /wp-admin/, но иногда и публичная часть сайта.

Основные причины высокой нагрузки admin-ajax.php

Универсальной причины не существует. На практике чаще всего встречается несколько сценариев.

WordPress Heartbeat API

Один из первых компонентов, который стоит проверить, — WordPress Heartbeat API.

Heartbeat — встроенный механизм WordPress, который периодически отправляет AJAX-запросы между браузером и сервером.

Он необходим для функций, работающих почти в реальном времени:

• автосохранения;
• контроля сессии;
• блокировки записи при одновременном редактировании;
• некоторых обновлений административной панели;
• взаимодействия отдельных плагинов с сервером.

Запросы Heartbeat выполняются периодически, поэтому одна открытая административная вкладка практически постоянно поддерживает связь с сервером.

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

Почему Heartbeat способен создавать высокий CPU

Предположим, Heartbeat выполняется раз в 15–60 секунд.

Одна вкладка практически незаметна.

Но если одновременно открыты:

• несколько вкладок редактора;
• WooCommerce Dashboard;
• административные страницы плагинов;
• панели нескольких сотрудников,

число обращений к серверу быстро возрастает.

Кроме того, плагины могут подключать собственные действия к Heartbeat. Тогда обычный heartbeat-запрос начинает выполнять дополнительный PHP-код и SQL-запросы.

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

Плагины WordPress

Вторая распространённая причина — плагины.

Многие расширения используют собственные AJAX-действия.

Особенно внимательно стоит проверить:

• AJAX-фильтры;
• live search;
• статистику посещений;
• page builders;
• security-плагины;
• системы уведомлений;
• чаты;
• формы;
• импорт и экспорт;
• резервное копирование;
• WooCommerce-расширения;
• плагины синхронизации;
• системы аналитики.

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

На сайте с небольшой посещаемостью это останется незаметным. При нескольких тысячах посетителей число обращений к PHP может стать огромным.

WP-Cron

WP-Cron — встроенный механизм WordPress для выполнения запланированных задач.

Через него могут выполняться:

• публикация отложенных записей;
• автоматические обновления;
• очистка временных данных;
• отправка писем;
• резервное копирование;
• синхронизация;
• задачи WooCommerce;
• задания сторонних плагинов.

WP-Cron отличается от классического системного cron.

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

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

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

В результате нагрузка от AJAX и cron накладывается друг на друга.

WooCommerce и Action Scheduler

На WooCommerce-сайтах необходимо отдельно проверять Action Scheduler.

Это система очередей фоновых задач, которую WooCommerce и различные расширения используют для:

• обработки платежей;
• webhooks;
• отправки писем;
• синхронизации;
• обработки подписок;
• импорта;
• выполнения отложенных действий.

Само наличие Scheduled Actions является нормальным.

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

Например:

• тысячи Pending actions;
• большое количество Failed actions;
• зависшие In-progress actions;
• один и тот же hook создаётся снова и снова.

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

Медленные SQL-запросы

Иногда admin-ajax.php лишь помогает обнаружить совершенно другую проблему.

Типичная цепочка выглядит так:

admin-ajax.php → плагин → SQL-запрос → MySQL → высокий CPU

Если один AJAX-запрос выполняет тяжёлый SQL-запрос в таблице с миллионами записей, даже небольшое количество AJAX-вызовов способно заметно замедлить сайт.

Особенно внимательно следует проверять:

• wp_options;
• wp_postmeta;
• WooCommerce-таблицы;
• таблицы Action Scheduler;
• собственные таблицы плагинов;
• таблицы статистики и логирования.

Слишком большой autoload в wp_options

WordPress автоматически загружает определённые записи из таблицы wp_options.

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

Это касается и admin-ajax.php.

Получается неприятная комбинация:

много AJAX-запросов + большой autoload + медленная база данных = высокая нагрузка CPU.

Поэтому при серьёзной диагностике WordPress необходимо проверять не только количество AJAX-запросов, но и состояние базы данных.

Как определить, что именно вызывает admin-ajax.php

Самый важный этап оптимизации — определить источник запросов.

Просто увидеть /wp-admin/admin-ajax.php в логах недостаточно.

Проверяем запросы через Chrome DevTools

Откройте проблемную страницу WordPress и нажмите:

F12 → Network → Fetch/XHR

После этого наблюдайте за запросами в течение одной-двух минут.

Если регулярно появляется:

/wp-admin/admin-ajax.php

откройте запрос и изучите его параметры.

Особое внимание уделите параметру:

action

Например:

action=heartbeat

означает, что запрос относится к Heartbeat API.

У стороннего плагина значение может выглядеть совершенно иначе:

action=plugin_name_some_action

Название action часто сразу указывает на источник проблемы.

Почему параметр action так важен

WordPress использует динамические AJAX hooks.

Для авторизованных пользователей они имеют вид:

wp_ajax_{action}

Для неавторизованных:

wp_ajax_nopriv_{action}

Поэтому, если вы обнаружили неизвестный action, выполните поиск соответствующей строки в:

/wp-content/plugins/

и:

/wp-content/themes/

Часто таким способом можно за несколько минут определить плагин или тему, зарегистрировавшие проблемное AJAX-действие.

Анализируем access log сервера

DevTools показывает запросы только вашего браузера.

Для полной картины необходимо изучить серверный access log.

Найдите обращения к:

/wp-admin/admin-ajax.php

После этого оцените:

• количество запросов;
• частоту;
• IP-адреса;
• User-Agent;
• метод запроса;
• время выполнения;
• AJAX action.

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

Как уменьшить нагрузку WordPress Heartbeat

Если выяснилось, что значительную часть запросов создаёт action=heartbeat, можно оптимизировать частоту Heartbeat.

Нужно ли полностью отключать Heartbeat

Обычно нет.

Полное отключение способно нарушить:

• автосохранение;
• блокировку записей;
• предупреждение об одновременном редактировании;
• функции некоторых плагинов.

Более безопасная стратегия — регулировать Heartbeat в зависимости от области сайта.

Например:

Frontend: отключить, если он там действительно не используется.

Dashboard: увеличить интервал.

Редактор записей: оставить включённым.

Так можно уменьшить количество обращений к admin-ajax.php, сохранив полезные функции WordPress.

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

Очень простой, но часто игнорируемый фактор — количество открытых вкладок браузера.

Если редактор или администратор оставил открытыми несколько страниц /wp-admin/, каждая из них потенциально продолжает выполнять фоновые запросы.

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

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

Читайте также:
Чем плагин Clearfy Pro полезен для сайтов WordPress

Как проверить плагины на чрезмерную AJAX-нагрузку

Если Heartbeat оптимизирован, но проблема осталась, переходите к плагинам.

Найдите владельца AJAX action

Допустим, DevTools показывает:

action=my_plugin_refresh

Выполните поиск:

my_plugin_refresh

по каталогу:

wp-content/plugins

С высокой вероятностью вы найдёте расширение, которое регистрирует это действие.

После этого необходимо понять:

1. Почему запрос выполняется?
2. Как часто он выполняется?
3. Нужна ли эта функция?
4. Можно ли уменьшить частоту?
5. Можно ли отключить конкретную функцию плагина?
6. Существует ли более производительная альтернатива?

Отключайте плагины только на staging

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

Однако на рабочем WooCommerce-сайте подобные эксперименты опасны.

Лучше создать staging-копию и проводить тесты там.

После отключения каждого подозрительного расширения сравнивайте:

• CPU;
• RAM;
• PHP workers;
• TTFB;
• количество запросов к admin-ajax.php;
• время ответа AJAX.

Важно измерять показатели, а не ориентироваться исключительно на субъективное ощущение «стало быстрее».

Как оптимизировать WP-Cron

Если сайт выполняет много фоновых заданий, стоит проверить WP-Cron.

Просмотр cron-задач

При наличии WP-CLI используйте:

wp cron event list

Посмотрите:

• какие hooks существуют;
• как часто они запускаются;
• есть ли просроченные события;
• существуют ли задачи удалённых плагинов;
• нет ли подозрительно частых заданий.

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

Перевод WP-Cron на системный cron

Для посещаемых сайтов и WooCommerce-магазинов можно рассмотреть запуск cron через системный планировщик сервера.

В wp-config.php стандартный запуск WP-Cron отключается:

define( 'DISABLE_WP_CRON', true );

После этого необходимо создать настоящее cron-задание на сервере, например с запуском каждые 5 минут.

Так выполнение фоновых задач становится более предсказуемым и меньше зависит от входящего трафика.

Важно: нельзя просто установить DISABLE_WP_CRON и больше ничего не делать.

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

Как проверить WooCommerce Action Scheduler

Если установлен WooCommerce, откройте:

WooCommerce → Status → Scheduled Actions

В некоторых конфигурациях Scheduled Actions также доступны через меню инструментов WordPress.

Какие статусы нужно проверить

Обратите внимание на:

Pending — ожидающие выполнения задачи.

Failed — задания, завершившиеся ошибкой.

In-progress — выполняющиеся задания.

Наличие нескольких задач — нормально.

Но если вы видите тысячи или десятки тысяч Pending/Failed actions, необходимо найти источник.

Не удаляйте очередь без выяснения причины

Предположим, плагин каждую минуту создаёт 100 новых задач.

Можно удалить 10 000 Pending actions.

Через несколько часов очередь появится снова.

Поэтому необходимо определить:

какой hook создаёт задачи → какой плагин ему принадлежит → почему очередь растёт.

Только после этого имеет смысл очищать накопившиеся задания.

Оптимизация базы данных WordPress

Если AJAX-запросов немного, но каждый выполняется долго, проблема может находиться в MySQL/MariaDB.

Используйте Slow Query Log

MySQL Slow Query Log позволяет обнаружить запросы, выполнение которых занимает слишком много времени.

Особенно полезно сопоставлять время SQL-запросов со всплесками CPU.

Например:

admin-ajax.php → plugin callback → SELECT ... → 4,2 секунды

Такой результат уже практически указывает на первопричину.

Проверьте wp_options и autoload

Большой объём autoload-данных увеличивает стоимость многих динамических запросов WordPress.

Причиной часто становятся:

• удалённые плагины;
• кэшированные настройки;
• транзиенты;
• плагины статистики;
• старые интеграции.

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

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

Проверьте таблицы плагинов

Некоторые плагины годами накапливают:

• логи;
• статистику;
• историю действий;
• сессии;
• события;
• очереди.

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

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

Redis и Persistent Object Cache

Для динамических WordPress-сайтов полезен Persistent Object Cache.

Чаще всего для этого применяется Redis.

Он может уменьшить количество повторных запросов к базе данных и особенно полезен для:

• WooCommerce;
• membership-сайтов;
• больших каталогов;
• сайтов с множеством авторизованных пользователей;
• проектов с активно используемым /wp-admin/.

Но важно понимать назначение Redis.

Если плагин отправляет тысячи ненужных AJAX-запросов, Redis не устранит причину.

Правильный порядок:

сначала убрать лишние запросы → затем оптимизировать выполнение оставшихся.

PHP-FPM, OPcache и серверные ресурсы

После оптимизации WordPress имеет смысл проверить серверную конфигурацию.

PHP-FPM

Обратите внимание на:

• количество PHP workers;
• лимиты памяти;
• максимальное количество процессов;
• время выполнения запросов;
• PHP-FPM slow log.

Если все workers заняты долгими AJAX-запросами, новые запросы будут ожидать освобождения процессов.

Пользователь при этом увидит очень медленный сайт.

OPcache

На production-сервере PHP OPcache обычно должен быть включён.

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

На WordPress с десятками плагинов это особенно заметно.

Всегда ли нужно увеличивать CPU

Нет.

Предположим, плагин генерирует 50 ненужных AJAX-запросов в секунду.

Переход с 2 CPU на 4 CPU действительно может временно улучшить ситуацию.

Но ошибочный процесс продолжит работать.

Через некоторое время нагрузка снова станет проблемой.

Поэтому масштабирование сервера должно происходить после программной оптимизации, а не вместо неё.

Что делать, если тормозит только wp-admin

Распространённая ситуация:

• главная страница открывается за 0,5 секунды;
• /wp-admin/ — за 5–10 секунд.

Это вполне возможно.

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

Каждое открытие страницы /wp-admin/ может запускать:

• WordPress Core;
• активные плагины;
• SQL-запросы;
• проверки обновлений;
• внешние API;
• административные уведомления;
• WooCommerce;
• фоновые процессы.

Поэтому высокая скорость frontend ещё не означает, что WordPress оптимизирован.

Что проверять в первую очередь

Если тормозит именно /wp-admin/, обратите особое внимание на:

1. плагины;
2. медленные SQL-запросы;
3. Heartbeat;
4. внешние HTTP-запросы;
5. WooCommerce Scheduled Actions;
6. WP-Cron;
7. autoload;
8. PHP workers.

Установка ещё одного cache-плагина в такой ситуации далеко не всегда поможет.

Что делать, если admin-ajax.php нагружает публичную часть сайта

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

Допустим, плагин выполняет один AJAX-запрос при каждом просмотре страницы.

При 10 000 просмотров получаем ещё:

10 000 PHP-запросов к admin-ajax.php.

Если каждый запрос выполняет пять SQL-запросов, сервер дополнительно получает до 50 000 обращений к базе данных.

Как оптимизировать такой сценарий

Задайте несколько вопросов:

• действительно ли AJAX нужен при каждом просмотре страницы;
• можно ли выполнять запрос только после действия пользователя;
• можно ли кэшировать ответ;
• можно ли увеличить интервал;
• можно ли объединить несколько запросов;
• можно ли перенести часть логики на клиент;
• можно ли заменить механизм более эффективной реализацией.

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

Может ли причиной быть бот или атака

Да. Не все обращения к admin-ajax.php обязательно создаются реальными посетителями.

Проверьте:

• IP-адрес;
• User-Agent;
• частоту;
• referrer;
• AJAX action;
• POST payload;
• характер интервалов.

Если один IP отправляет сотни одинаковых запросов в минуту, это может быть бот или автоматизированный скрипт.

Когда использовать WAF и Rate Limiting

Для ограничения нежелательного трафика можно использовать:

• Cloudflare WAF;
• Rate Limiting;
• Nginx;
• ModSecurity;
• средства защиты хостинга.

Но правило должно быть максимально точным.

Не стоит блокировать весь:

/wp-admin/admin-ajax.php

из-за одного проблемного действия.

Почему нельзя просто заблокировать admin-ajax.php

Это одна из самых опасных «оптимизаций».

Полная блокировка файла может нарушить:

• административную панель;
• автосохранение;
• WooCommerce;
• AJAX-фильтры;
• формы;
• поиск;
• плагины;
• динамические функции сайта.

То есть нагрузка действительно исчезнет — вместе с частью функциональности сайта.

Гораздо правильнее определить конкретный action и работать именно с ним.

Инструменты для поиска причины высокой нагрузки

Для профессиональной диагностики желательно использовать сразу несколько инструментов.

Chrome DevTools

Показывает AJAX-запросы браузера и позволяет определить их частоту и параметры.

Query Monitor

Полезен для анализа:

• SQL;
• hooks;
• HTTP API;
• PHP-ошибок;
• компонентов, выполняющихся при загрузке WordPress.

WP-CLI

Позволяет быстро работать с WordPress из командной строки, включая cron-задачи и базу данных.

PHP-FPM Slow Log

Помогает обнаруживать PHP-процессы, которые выполняются слишком долго.

MySQL Slow Query Log

Показывает медленные SQL-запросы.

APM

На крупных проектах можно использовать New Relic и другие APM-системы.

Они помогают увидеть цепочку:

HTTP request → PHP function → plugin → SQL → внешний API.

Это значительно ускоряет поиск узкого места.

Пошаговый алгоритм диагностики admin-ajax.php

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

Шаг 1. Зафиксируйте исходные показатели

Запишите:

• CPU;
• RAM;
• load average;
• количество PHP workers;
• TTFB;
• время ответа /wp-admin/.

Это позволит понять, действительно ли последующие изменения помогли.

Шаг 2. Проверьте access log

Найдите:

/wp-admin/admin-ajax.php

Посмотрите, насколько часто он вызывается.

Шаг 3. Определите action

Через DevTools или логи выясните значение:

action=...

Это один из самых важных этапов.

Шаг 4. Проверьте Heartbeat

Если используется:

action=heartbeat

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

Шаг 5. Найдите проблемный плагин

Если action принадлежит стороннему расширению, определите его по исходному коду.

Шаг 6. Проверьте WP-Cron

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

Шаг 7. Проверьте Action Scheduler

Для WooCommerce обязательно изучите Pending, Failed и In-progress actions.

Шаг 8. Проверьте базу данных

Используйте Slow Query Log и проанализируйте wp_options, autoload и крупные таблицы.

Шаг 9. Проверьте PHP

Изучите PHP-FPM workers, slow log, memory limit и OPcache.

Шаг 10. Повторите измерения

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

Именно последний шаг часто забывают.

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

Частые ошибки при устранении высокой нагрузки

Попытка максимально быстро снизить CPU иногда приводит к ещё большим проблемам.

Полное отключение Heartbeat

Может нарушить автосохранение и другие функции WordPress.

Лучше регулировать частоту.

Блокировка admin-ajax.php

Может вывести из строя множество функций сайта.

Удаление всех Cron Events

Часть плагинов перестанет выполнять необходимые фоновые операции.

Массовая очистка wp_options

Можно удалить критически важные настройки.

Очистка Action Scheduler без поиска причины

Очередь снова заполнится, если плагин продолжает создавать задания.

Немедленное увеличение мощности VPS

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

Установка нескольких оптимизаторов

Несколько cache/optimization-плагинов способны конфликтовать друг с другом и сделать диагностику ещё сложнее.

Как понять, что проблема действительно устранена

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

После оптимизации сравните:

• средний CPU;
• пики CPU;
• RAM;
• load average;
• количество admin-ajax.php запросов;
• среднее время AJAX-ответа;
• TTFB;
• PHP worker utilization;
• количество медленных SQL-запросов;
• размер очереди Scheduled Actions.

Лучше сравнивать одинаковые периоды.

Например:

24 часа до оптимизации → 24 часа после оптимизации.

Так результат будет значительно объективнее.

Вопросы и ответы

Высокая нагрузка от /wp-admin/admin-ajax.php — чаще всего симптом, а не самостоятельная проблема.

Самая распространённая ошибка — увидеть admin-ajax.php в отчёте хостинга и сразу попытаться отключить Heartbeat, заблокировать AJAX или увеличить мощность сервера.

Профессиональная диагностика строится иначе:

определить запрос → найти action → установить источник → измерить частоту → проверить выполняемый PHP/SQL → устранить причину → повторно измерить нагрузку.

В первую очередь стоит проверить WordPress Heartbeat API, плагины, WP-Cron и WooCommerce Action Scheduler. Если с количеством запросов всё нормально, следующий уровень диагностики — база данных, autoload, PHP-FPM, внешние API и серверная конфигурация.

И главное правило при работе с admin-ajax.php:

не блокируйте механизм целиком — найдите конкретный процесс, который использует его неэффективно.

Такой подход позволяет не только снизить загрузку CPU, но и заметно ускорить /wp-admin/, сократить время AJAX-ответов и повысить стабильность WordPress под нагрузкой.

Источники

1. FluxPress — admin-ajax.php High CPU in WordPress: Heartbeat & Cron Explained. Материал о высокой нагрузке admin-ajax.php, Heartbeat API и WP-Cron.
2. WordPress Developer Resources — Heartbeat API. Официальная документация WordPress о механизме Heartbeat, его AJAX-запросах и интервалах работы.
3. WordPress Developer Resources — wp_ajax_heartbeat(). Официальная документация серверного обработчика Heartbeat.
4. WordPress Developer Resources — wp_ajax_{$action}. Официальная документация динамических AJAX hooks и параметра action.
5. WordPress Developer Resources — _wp_cron(). Документация внутреннего механизма обработки запланированных событий WordPress.
6. WordPress Advanced Administration Handbook — wp-config.php. Официальная документация констант DISABLE_WP_CRON, ALTERNATE_WP_CRON и других параметров конфигурации WordPress.
7. Action Scheduler — официальная документация. Документация системы фоновых очередей, используемой WooCommerce и другими WordPress-плагинами.
8. Action Scheduler — Scheduled Actions Administration Screen. Документация по просмотру Pending, Failed, In-progress и других фоновых задач.

Алексей Шевченко

редактор wpcafe

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующийся на создании сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/