Предотвратить бесконечный цикл AJAX при использовании собственного API

В настоящее время я пытаюсь выяснить интеграцию между 2 плагинами WordPress: плагином WooCommerce Follow-Up Emails и плагином Ninja Forms (с конечной целью, чтобы мы могли отправить шаблон последующего электронного письма ручного типа в качестве действия в ответ на формы ниндзя). представление). Мы используем Ninja Forms 3, чего бы это ни стоило.

При определении параметров для Класс действий Я предоставляю пользователю список шаблонов, чтобы при определении действия он мог выбрать шаблон для отправки. Чтобы получить шаблоны писем из плагина последующих писем, я использую их Клиент API, конкретно get_emails() метод (который, в свою очередь, переводит в GET вызов /emails конечная точка под их URL API).

Проблема заключается в следующем: на каждой странице загрузить ninja_forms_register_actions называется действие, во время которого я создаю экземпляр своего класса действий. В течение __construct вызов, мы заполняем настройки для действия, и для этого мы вызываем API Follow-Up Emails. Это инициирует загрузку страницы, во время которой ninja_forms_register_actions действие называется …

Хотя я и предвидел эту проблему, мое запланированное решение не помогло: я планировал использовать переходные процессы для хранения результата вызова API, например, так:

private static function _get_templates()
{
error_log('_get_templates() started - ' . microtime(true));
if (false === ($templates = get_transient(self::TEMPLATE_TRANSIENT))) {
error_log('_get_templates() fetching - ' . microtime(true));
$fue_api = self::fue_api();
$templates = $fue_api->get_emails();
set_transient(self::TEMPLATE_TRANSIENT, $templates, self::TEMPLATE_TRANSIENT_EXPIRY);
error_log('_get_templates() fetched - ' . microtime(true));
}
error_log('_get_templates() done - ' . microtime(true));

return $templates;
}

Однако результат в моих журналах следующий:

[22-May-2016 23:53:33 UTC] _get_templates() started - 1463961213.692187
[22-May-2016 23:53:33 UTC] _get_templates() fetching - 1463961213.694222
[22-May-2016 23:53:34 UTC] _get_templates() started - 1463961214.05998
[22-May-2016 23:53:34 UTC] _get_templates() fetching - 1463961214.061054
[22-May-2016 23:53:38 UTC] _get_templates() started - 1463961218.660683
[22-May-2016 23:53:38 UTC] _get_templates() fetching - 1463961218.661265
[22-May-2016 23:53:40 UTC] _get_templates() started - 1463961220.772228
[22-May-2016 23:53:40 UTC] _get_templates() fetching - 1463961220.774142
[22-May-2016 23:53:41 UTC] _get_templates() started - 1463961221.150277
[22-May-2016 23:53:41 UTC] _get_templates() fetching - 1463961221.654757
[22-May-2016 23:53:45 UTC] _get_templates() started - 1463961225.306565
[22-May-2016 23:53:45 UTC] _get_templates() fetching - 1463961225.308898
[22-May-2016 23:53:46 UTC] _get_templates() started - 1463961226.281794
[22-May-2016 23:53:46 UTC] _get_templates() fetching - 1463961226.283803

Это продолжается до тех пор, пока я не убью процесс веб-сервера или что-то еще радикальное, например, удалив / переименовав папку подключаемых модулей, после чего переходный процесс заполняется кодом ошибки HTTP (что само по себе неудивительно). Ясно, что мое решение для переходных процессов не работает, так как переходный процесс все еще не установлен до окончания запроса.

В некоторых ситуациях, подобных этой, я бы добавил проверку DOING_AJAXОднако это не подходит по двум причинам — мне все еще нужно, чтобы эти данные были доступны процессам AJAX Ninja Forms, а также я не уверен, действительно ли здесь будет установлен DOING_AJAX, поскольку FUE API не использует admin-ajax.php, Я думал о переходе на что-то вроде следующего:

private static function _get_templates()
{
error_log('_get_templates() started - ' . microtime(true));
if (false === get_option(self::TEMPLATE_LOCK_OPTION, false) && false === ($templates = get_transient(self::TEMPLATE_TRANSIENT))) {
delete_option(self::TEMPLATE_LOCK_OPTION);
add_option(self::TEMPLATE_LOCK_OPTION, true, '', 'no');
error_log('_get_templates() fetching - ' . microtime(true));
$fue_api = self::fue_api();
$templates = $fue_api->get_emails();
delete_option(self::TEMPLATE_LOCK_OPTION);
set_transient(self::TEMPLATE_TRANSIENT, $templates, self::TEMPLATE_TRANSIENT_EXPIRY);
error_log('_get_templates() fetched - ' . microtime(true));
}
error_log('_get_templates() done - ' . microtime(true));

return $templates;
}

Но использование опций в качестве блокировок кажется грязным и неправильным, и я чувствую, что это оставляет место для ошибок, когда используется кэширование объектов (например, WPEngine et al). Есть ли лучший / нормальный способ справиться с этим, или, наоборот, нет реальной проблемы с вышесказанным?

Изменить: Таким образом, решение для блокировки тоже не работает на 100% — я закончил делать это с работой WP Cron — каждые десять минут мы выбираем список шаблонов, а не по мере необходимости, и сохраняем его в опции. Мне не особенно нравится это решение, но я пока не смог придумать лучшего. Еще интересно, есть ли общее решение этой проблемы.