Когда следует использовать add_rewrite_tag()?
Я потратил несколько дней, пытаясь разобраться, как лучше добавлять правила перезаписи. На данный момент я понимаю, что для простых правил подходит add_rewrite_rules()
, во многом благодаря Яну Фабри на этом форуме, чьи разъяснения были очень полезны.
Хотя он упоминает add_rewrite_tag()
, я не нашел руководств, объясняющих, когда его использование выгодно по сравнению с другими способами добавления правил перезаписи, или хороших примеров его применения. Похоже, это более мощный инструмент, но это все, что я могу понять. Примеры в Кодексе кажутся слишком загадочными или неполными. Может кто-то объяснить подробнее или указать на какие-то ресурсы? В Google я не нашел ничего полезного.
редактировать:
Страница в Кодексе говорит о том, что его «обычно» используют вместе с add_rewrite_rules()
, но не уточняет. Аналогично страница Кодекса для add_rewrite_rules()
ссылается на add_rewrite_tag()
, но тоже содержит очень мало информации. Когда и как следует использовать такое сочетание? Единственный пример, который я нашел - это этот ответ Роба Вермеера, который мне непонятен.

Основное различие заключается в следующем:
add_rewrite_rule()
добавляет конкретное правило, которое интерпретируетсяadd_rewrite_tag()
добавляет заполнитель для использования в структурах URL. Этот заполнитель затем используется для генерации множества правил.
Например, предположим, что вы — турагент, рекламирующий отели в разных странах. Вы можете захотеть, чтобы URL отеля выглядел так:
www.example.com/hotels/UK/Balmoral
Где страна (в данном примере UK) — это пользовательский термин таксономии, а Balmoral — отель (тип записи). Мы могли бы добавить правила перезаписи для этого, но тогда нам пришлось бы генерировать правило для:
- самого отеля
- вложений отеля
- правила для отелей (записей), где контент разбит на несколько страниц и т.д.
Генерация этих правил может стать сложной. Более того, мы, вероятно, будем конкурировать с собственными правилами WordPress для этого типа записи — сгенерированными из структуры постоянных ссылок, которую мы установили при регистрации типа записи. (В любом случае, пусть WordPress делает работу).
Эта 'структура постоянных ссылок' — аналогичная той, что вы устанавливаете для записей в настройках постоянных ссылок — определяет правила перезаписи, которые генерирует WordPress. Но поскольку мы хотим структуру, содержащую некоторую неизвестную (страну) — которую мы хотим интерпретировать — нам нужно предоставить заполнитель в форме %country%
. (Это почти идентично %category%
для записей).
Например:
add_action_init('init','wpse71305_register_types');
function wpse71305_register_types(){
//Здесь вам также нужно зарегистрировать таксономию страны.
//Добавляем тег 'country'.
add_rewrite_tag('%country%', '([^&/]+)'));
//Регистрируем тип записи 'hotel' с тегом %country%
$args = array(
...
'has_archive'=>true,
'rewrite' => array(
'slug'=>'hotels/%country%',
'with_front'=> false,
'feed'=> true,
'pages'=> true
)
...
);
register_post_type('hotel',$args);
}
Примечание: WordPress не знает, как сгенерировать URL из тега %country%
— вам нужно указать ему, как это сделать. (Я рассказываю об этом в статье, ссылку на которую привожу ниже).
В итоге WordPress также сохранит совпавшее значение, чтобы вы могли получить его через get_query_var()
(чего не происходит со стандартным правилом перезаписи).
Вы также можете создавать теги для использования в структуре постоянных ссылок записей (установите их на странице настроек постоянных ссылок).
Добавляя тег, мы можем использовать его в структурах постоянных ссылок. WordPress тогда знает:
- Что ожидать
- Как интерпретировать URL (проверить, соответствует ли он)
- Как интерпретировать значение (т.е. 'UK')
(В качестве справки см. статью, которую я написал: http://wp.tutsplus.com/tutorials/creative-coding/the-rewrite-api-the-basics/).
Редактирование
Как отмечено в комментариях, приведенный выше пример неудачен, так как register_taxonomy()
фактически вызывает add_rewrite_tag()
.
Относительно документации Codex об их использовании 'в комбинации': это, возможно, вводит в заблуждение, так как они могут использоваться независимо. Как отмечено выше, однако, add_rewrite_tag()
добавляет имя тега к 'переменным запроса', понятным WordPress. На практике это позволяет вам получить значение с помощью get_query_var()
. Таким образом, когда add_rewrite_rule()
используется вместе с add_rewrite_tag()
, переменная будет сохранена WordPress. Но есть и другие способы сделать это (см. этот ответ — обратите также внимание на комментарий Rob Vermeer).
Также по теме: Как получить переменные $_GET из переписанных URL?

Спасибо за это. Из вашего ответа я понял, что add_rewrite_tag()
можно использовать для создания плейсхолдеров, которые будут применяться в Настройки->Постоянные ссылки
. Обязательно ли использовать таксономию для работы с add_rewrite_tag()
? Из страницы в Кодексе у меня сложилось впечатление, что нет, но часто встречается именно такое использование.
Я расширил свой вопрос касательно использования add_rewrite_tag()
совместно с add_rewrite_rule()
, как предложено на странице Кодекса.

Вы абсолютно правы насчет таксономий (это был неудачный пример с моей стороны). Смотрите эту часть register_taxonomy()
. Лучшим примером было бы использование чего-то вроде %country%
, когда country - это просто общая переменная запроса, а не таксономия. Такие случаи редки - мне никогда не приходилось использовать add_rewrite_tag()
.

@StephenHarris в каких случаях следует выбирать add-rewrite_tag()
для добавления плейсхолдеров вместо хука фильтра query_vars
?
