Podstawowa różnica polega na:
add_rewrite_rule()
Dodaje konkretny przepis , który jest interpretowany
add_rewrite_tag()
Dodaje zastępczy do stosowania w konstrukcjach URL. Ten symbol zastępczy jest następnie używany do generowania wielu reguł.
Załóżmy na przykład, że jesteś biurem podróży reklamującym hotele w różnych krajach. Możesz chcieć, aby adres URL hotelu był jak
www.example.com/hotels/UK/Balmoral
Gdzie kraj (w tym przykładzie Wielka Brytania) to niestandardowy termin taksonomiczny, a Balmoral to hotel (typ pocztowy). Moglibyśmy dodać do tego reguły przepisywania, ale wtedy musielibyśmy wygenerować regułę dla:
- sam hotel
- załączniki do hotelu
- Reguła dla hoteli (postów), w których rozlewa się na kilka stron itp.
Generowanie tych reguł może się skomplikować. Ponadto prawdopodobnie będziemy konkurować z własnymi regułami WordPress dla tego typu postów - generowanymi na podstawie struktury permastralnej, którą ustaliliśmy podczas rejestracji typu posta. (W każdym razie pozwól, aby WordPress wykonał pracę).
Ta „permastruktura” - podobna do tej, którą ustawiasz dla postów w ustawieniach permalink - określa reguły przepisywania generowane przez WordPress. Ale ponieważ chcemy struktury zawierającej jakieś nieznane (kraj) - które chcemy interpretować - musimy podać symbol zastępczy formularza %country%
. (Jest prawie identyczny jak w %category%
przypadku postów).
Na przykład:
add_action_init('init','wpse71305_register_types');
function wpse71305_register_types(){
//You'll need to register the country taxonomy here too.
//Add 'country' tag.
add_rewrite_tag('%country%', '([^&/]+)'));
//Register hotel post type with %country$ tag
$args = array(
...
'has_archive'=>true,
'rewrite' => array(
'slug'=>'hotels/%country%',
'with_front'=> false,
'feed'=> true,
'pages'=> true
)
...
);
register_post_type('hotel',$args);
}
Uwaga: WordPress nie wie, jak wygenerować adres URL z %country%
tagu - musisz to powiedzieć. (Omawiam to w artykule, który zamieściłem poniżej).
Wreszcie WordPress zapisze również dopasowaną wartość, abyś mógł ją odzyskać get_query_var()
(coś, czego nie ma w przypadku standardowej reguły przepisywania).
Możesz także tworzyć tagi do użycia w permastruktury postów (ustaw go na stronie ustawień Permalink).
Dodając tag, możemy go użyć w permastrukturach. WordPress to wie
- Czego oczekiwać
- Jak interpretować adres URL (sprawdź, czy pasuje)
- Jak interpretować wartość (tj. „Wielka Brytania”)
(Jako odniesienie patrz ten artykuł, który napisałem: http://wp.tutsplus.com/tutorials/creative-coding/the-rewrite-api-the-basics/ ).
Edytować
Jak zauważono w komentarzach, powyższy przykład jest kiepski, jak register_taxonomy()
w rzeczywistości wzywa add_rewrite_tag()
.
Odnośnie do dokumentacji Kodeksu dotyczącej używania ich „w połączeniu”: być może jest to mylące, ponieważ można ich używać niezależnie. Jak wspomniano powyżej, add_rewrite_tag()
dodaje jednak nazwę znacznika do WordPress-zrozumienia „zmiennych zapytań”. W praktyce pozwala to odzyskać wartość za pomocą get_query_var()
. Tak więc, gdy add_rewrite_rule()
jest używany z add_rewrite_tag()
, zmienna będzie przechowywana przez WordPress. Ale są na to inne sposoby (zobacz tę odpowiedź - zwróć uwagę również na komentarz Roba Vermeera).
Powiązane również: Jak odzyskać zmienne $ _GET z przepisanych adresów URL?
add_rewrite_tag()
można jej użyć do tworzenia symboli zastępczychSettings->Permalinks
. Czy przy korzystaniu z taksonomii jest to wymaganeadd_rewrite_tag()
? Mam wrażenie ze strony Kodeksu, że tak nie jest, ale wydaje się powszechnie używane. Rozszerzyłem swoje pytanie dotyczące używaniaadd_rewrite_tag()
w połączeniu z,add_rewrite_rule()
jak sugerowano na stronie Kodeksu .