Вопрос или проблема
Если я использую REST API для создания конечных точек в своем плагине, должен ли я сбрасывать правила переопределения на init или в rest_api_init?
Я понимаю, что это должно быть сделано при активации/деактивации плагина. Однако, как только одно из этих событий будет вызвано, разве вы все равно не должны соблюдать традиционный процесс хуков, чтобы убедиться, что правила переопределения сброшены ПОСЛЕ их изменения? Иными словами – после того, как были добавлены REST-маршруты.
Пример:
function activate() {
// делаем что-то, когда этот плагин активирован...
add_action( 'init', function () {
flush_rewrite_rules( true );
}, 9999 );
return true;
}
# Активация плагина
register_activation_hook( __FILE__, function () {
require_once( PATH . '/backend/inc/activation.php' );
Backend\activate();
} );
init
add_action( 'init', function () {
flush_rewrite_rules( true );
}, 9999 );
rest_api_init
add_action( 'rest_api_init', function () {
flush_rewrite_rules( true );
}, 9999 );
Сброс правил переопределения не должен производиться регулярно, как указано в кодексе:
Не делайте это на любом хуке, который будет вызываться регулярно.
Вы должны делать это либо через хуки активации плагина, либо через хуки переключения темы:
add_action( 'after_switch_theme', 'wpse315001_flush_rewrite_rules' );
register_deactivation_hook( __FILE__, 'wpse315001_flush_rewrite_rules' );
register_activation_hook( __FILE__, 'wpse315001_flush_rewrite_rules' );
function wpse315001_flush_rewrite_rules() {
flush_rewrite_rules();
}
Один из вышеприведенных методов должен использоваться ПОСЛЕ того, как вы зарегистрировали свои пользовательские типы записей.
Кроме того, вы должны сбрасывать правила переопределения после деактивации плагина. Это гарантирует отсутствие невалидных правил.
Тем не менее, как и с каждой другой проблемой, у этого есть неприятное обходное решение. Если ваши правила переопределения содержат полупоисковое слово, вы можете получить правила переопределения из настроек, выполнить поиск и сбросить их только в случае необходимости:
add_action( 'init', 'wpse315001_flush_rewrite_rules', 99999 );
function wpse315001_flush_rewrite_rules(){
// Получаем правила переопределения
$rules = get_option('rewrite_rules');
// Проверяем, существует ли ваше полупоисковое правило в этой строке
if ( ! strpos( $rules, 'your-rewrite-rules' ) ) {
// Сбрасываем все!
flush_rewrite_rules();
}
}
Возможно, это не лучшее решение, но это подойдет.
Ответ или решение
Обсуждение: Сброс правил перенаправления в init или rest_api_init?
Когда речь идет о создании пользовательских конечных точек с использованием REST API в вашем плагине, возникает вопрос, где лучше всего сбрасывать правила перенаправления: в хуке init или rest_api_init. Давайте рассмотрим эту проблему более подробно, учитывая различные аспекты, которые следует учитывать.
1. Когда необходимо сбрасывать правила перенаправления?
Сброс правил перенаправления на самом деле должен выполняться не на каждой итерации, а только в определенные моменты жизни вашего плагина. К таким моментам относятся:
- Активация плагина: Когда плагин активируется, все новые правила должны быть зарегистрированы, и только затем необходимо выполнить сброс.
- Деактивация плагина: Важно также сбросить правила, чтобы избежать накопления недействительных маршрутов.
- Переключение темы: При смене темы рекомендуется сбросить правила, если они зависят от определенных условий темы.
2. Подходы к сбросу правил перенаправления
Существует два метода, которые можно использовать для сброса правил перенаправления:
-
Хук
init: Этот хук является хорошей отправной точкой для большинства действий, связанных с инициализацией WordPress. Он вызывается до того, как будет обработан любой запрос, что делает его подходящим местом для выполнения регистрации пользовательских маршрутов и сброса правил.add_action('init', function() { // Регистрация пользовательских маршрутов // ... flush_rewrite_rules(); }, 9999); -
Хук
rest_api_init: Этот хук срабатывает после инициализации REST API и перед выполнением любого запроса к API. Однако работать сflush_rewrite_rules()здесь не рекомендуется, поскольку этот хук вызывается часто, что может привести к неоправданным затратам ресурсов.add_action('rest_api_init', function() { // Регистрация маршрутов специфичных для REST API // ... flush_rewrite_rules(); }, 9999);
3. Что стоит учитывать при выборе хука?
Исходя из спецификации работы хуков, следует помнить следующее:
- Не сбрасывайте правила на рутинной основе: WordPress Codex подчеркивает, что сброс должен происходить только в ответ на изменения структуры маршрутов, такие как их регистрация или обновление.
- Сброс после модификаций: Лучше всего сбрасывать правила после того, как вы зарегистрировали пользовательские типы записей, чтобы избежать конфликтов.
4. Рекомендации по сбросу правил
В идеале, вы должны сбрасывать правила перенаправления в момент активации вашего плагина, а также после переключения темы или деактивации:
function wpse315001_flush_rewrite_rules() {
flush_rewrite_rules();
}
// Хуки активации и деактивации плагина
register_activation_hook(__FILE__, 'wpse315001_flush_rewrite_rules');
register_deactivation_hook(__FILE__, 'wpse315001_flush_rewrite_rules');
// Хук для переключения темы
add_action('after_switch_theme', 'wpse315001_flush_rewrite_rules');Можно добавить условие для проверки существования уникальных ключевых слов для ваших правил, чтобы избежать чрезмерного срабатывания сброса.
Заключение
В заключение, рекомендуется сбрасывать правила перенаправления через хук init, а не в rest_api_init, чтобы избежать ненужных затрат ресурсов. Сброс правил должен выполняться исключительно в ответ на конкретные события, такие как активация, деактивация плагина или переключение темы. С учетом всех факторов, эти подходы помогут вам сохранить производительность вашего плагина и избежать потенциальных проблем.