Die Rewrite-API: Beitragstypen und Taxonomien

German (Deutsch) translation by Katharina Grigorovich-Nevolina (you can also view the original English article)

Dies ist Teil zwei einer Reihe, die sich mit der Rewrite-API von WordPress befasst. Im ersten Teil machten wir eine Whistle-Stop-Tour durch die Grundlagen der Rewrite-API von WordPress. In diesem Tutorial werden wir uns die Umschreibeinstellungen ansehen, die uns bei der Registrierung eines Beitragstyps oder einer Taxonomie zur Verfügung stehen. Während benutzerdefinierte Beitragstypen und Taxonomien (im Gegensatz zu den Standardbeiträgen, Kategorien und Tags) keine Einstellungen - > Permalink-Oberfläche haben, ist das Einrichten von Umschreibungen für benutzerdefinierte Typen immer noch recht einfach. Wir werden auch die in Teil 1 vorgestellten Methoden verwenden. Wenn Sie dies noch nicht getan haben, empfehlen wir Ihnen, WordPress Rewrite API Teil 1: Die Grundlagen zu lesen.

Spülen der Rewrite-Regeln

Wenn Sie einen benutzerdefinierten Typ registrieren, registriert WordPress auch Umschreiberegeln (eigentlich nicht ganz, und ich werde im Abschnitt "Permastrukturen" erklären, warum). Wie in Teil 1 erwähnt, werden diese Regeln erst aufgenommen, wenn die Umschreiberegeln "gelöscht" sind. Themes und Plug-Ins können dieses "Flushing" erzwingen, indem sie flush_rewrite_rules() aufrufen. Dies muss und sollte nur einmal bei der Aktivierung und dann erneut bei der Deaktivierung erfolgen (um nach sich selbst aufzuräumen).

Bevor Sie die Umschreiberegeln löschen, müssen Sie sie natürlich hinzugefügt haben. Der init-Hook, an dem Beitragstypen registriert werden sollen, wurde jedoch bereits ausgelöst, und als dies der Fall war, war Ihr Plug-In oder Thema noch nicht aktiv, sodass Ihre Beitragstypen und Taxonomien noch nicht registriert sind. Um die Umschreiberegeln zu registrieren, die mit Ihren Beitragstypen und Taxonomien geliefert werden, müssen Sie sie bei der Aktivierung manuell registrieren, bevor Sie die Umschreiberegeln löschen. Dies sollte also Ihr Setup sein:

function wptuts_register_types() {
	//function which registers your custom post type and taxonomies
}
add_action('init','wptuts_register_types');

function wptuts_plugin_activation() {

	// Register types to register the rewrite rules
	wptuts_register_types();

	// Then flush them
	flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'wptuts_plugin_activation');

function wptuts_plugin_deactivation() {

	flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'wptuts_plugin_activation');

Themen können die Hooks after_switch_theme zur Aktivierung und switch_theme zur Deaktivierung verwenden.

Benutzerdefinierte Beitragstypen

Wenn Sie einen Beitragstyp mit register_post_type registrieren, ist eines der Argumente, die Ihnen zur Verfügung stehen, das Umschreibungsargument. Dies sollte ein Array mit den folgenden Schlüsseln sein:

slug - Ein Slug, mit dem der Beitragstyp in URLs identifiziert wird. Der Butzen des Pfostens wird an diesen für den Permalink des Postens angehängt, z.B. www.example.com/books/the-wizard-of-oz
with_front - wahr oder falsch. Wenn die Permalink-Struktur Ihres Posts mit einer konstanten Basis beginnt, z. B. '/blog', kann dies auch zur Permalink-Struktur Ihres benutzerdefinierten Post-Typs hinzugefügt werden, indem Sie sie auf wahr setzen, z.B. wahr gibt www.example.com/blog/books/ und falsch www.example.com/books/
feeds - wahr oder falsch. Gibt an, ob Regeln zum Umschreiben von Feeds generiert werden sollen, z.B. www.example.com/books/feed/rss und www.example.com/book/rss. Der Standardwert ist der Wert von has_archive.
pages - wahr oder falsch. Gibt an, ob eine Regel für die "hübsche" Paginierung für das Post-Typ-Archiv generiert werden soll, z.B. www.example.com/books/page/2 anstelle von www.example.com/books?page=2. Der Standardwert ist wahr.
ep_mask - Dies war früher ein separates Argument: permalink_epmask. Ab 3.4 wird es in das Rewrite-Array verschoben. Der Standardwert ist EP_PERMALINK.

Die Schlüssel 'Feeds' und 'Pages' betreffen nur die Archivseite nach dem Typ (für die Sie das Argument has_archive auf true gesetzt haben müssen). Aus diesem Rewrite-Array übernimmt WordPress automatisch die Generierung der Rewrite-Regeln für Ihre Beitragstypen. Als Beispiel:

$labels = array(
	'name' => __('Books', 'your-plugins-translation-domain'),
	//array of labels
);

$args = array(
	'labels' => $labels,
	'has_archive'=>true,
	'rewrite' => array(
		'slug'=>'books',
		'with_front'=> false,
		'feed'=> true,
		'pages'=> true
	)
);
register_post_type('book',$args);

Würde die folgenden Umschreiberegeln geben:

Der Permalink des Buches 'the-wizard-of-oz': www.example.com/books/the-wizard-of-oz
Archiv aller Bücher www.example.com/books (und www.example.com/books/page/2)
Der Feed des obigen Archivs: www.example.com/books/feed/rss (und www.example.com/books/rss)

Taxonomien

Die Funktion register_taxonomy() bietet weniger Optionen:

slug - eine Schnecke zur Identifizierung der Taxonomie, z. www.example.com/genre/history
with_front - Wie oben.
hierarchical - wahr oder falsch. Wenn true festgelegt ist und die Taxonomie hierarchisch ist, spiegelt der Begriff Permalink die Hierarchie wider. Der Standardwert ist falsch.
ep_mask - Hinzugefügt in 3.4. Siehe Abschnitt EP-Maske unten.

Die ersten beiden Optionen ähneln den oben genannten. Die hierarchische Option gibt dem Begriff Permalinks die gleiche Struktur wie Seiten. Zum Beispiel sei "Geschichte" ein Genre und "Militärgeschichte" ein Untergenre. Wenn die Hierarchie auf falsch gesetzt ist, hat 'Militärgeschichte' den Permalink:

1	www.example.com/genre/military-history

Auf wahr gesetzt, wird es Folgendes haben:

1	www.example.com/genre/military/military-history

Durch das Registrieren einer Taxonomie werden die Feeds Ihrer Taxonomie-Begriffe automatisch registriert:

1	www.example.com/genre/military-history/feed

Sie können den Feed-Link-Permalink zu jedem Taxonomiebegriff mit $feed_link = get_term_feed_link($term_id, $taxonomy, $feed) abrufen.

Beitragstyp Archive

Standardmäßig erstellt WordPress keine "hübschen" Permalinks für die Jahr-, Monats- oder Tagesarchive Ihres benutzerdefinierten Beitragstyps (noch für das Autorenarchiv - aber wir lassen dieses vorerst). Während:

1	www.example.com/?post_type=book&year=2012&monthnum=05

Gibt korrekt ein Archiv aller im Mai 2012 veröffentlichten Bücher an:

1	www.example.com/books/2012/05

Gibt einen 404-Fehler aus. Wir können jedoch einfach zusätzliche Umschreiberegeln hinzufügen, indem wir die verfügbaren Umschreib-API-Methoden verwenden, die wir in Teil 1 behandelt haben. Eine Methode besteht darin, die folgende Liste von Umschreiberegeln hinzuzufügen, wenn Sie Ihren Beitragstyp registrieren:

// Add day archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/([0-9]{2})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&paged=$matches[4]','top');
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/([0-9]{2})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&day=$matches[3]','top');

// Add month archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&paged=$matches[3]','top');
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]','top');

// Add year archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&paged=$matches[2]','top');
add_rewrite_rule("books/([0-9]{4})/?",'index.php?post_type=book&year=$matches[1]','top');

Dies kann leicht etwas chaotisch werden - insbesondere, wenn Sie bedenken, dass Sie zusätzliche Regeln hinzufügen müssten, wenn Ihre Archive hübsche URLs für ihre Feeds unterstützen sollen. Das Obige veranschaulicht jedoch eine wichtige Tatsache beim Hinzufügen benutzerdefinierter Regeln: Die Reihenfolge, in der die Regeln hinzugefügt werden, ist wichtig.

Denken Sie daran, dass diese Regeln dem Rewrite-Array in der Reihenfolge hinzugefügt werden, in der Sie add_rewrite_rule aufrufen. Beim Parsen einer Anfrage verwendet WordPress die erste Übereinstimmungsregel. Versuchen Sie, die Reihenfolge zu ändern, in der die Archivierungsregeln für Jahr und Monat hinzugefügt werden. Sie werden feststellen, dass Sie unter www.example.com/books/2012/04/ zum Archiv 2012 gelangen. Dies liegt daran, dass diese URL mit den Mustern für das Jahr- und das Monatsarchiv übereinstimmt, die erstere jedoch zuerst hinzugefügt wurde. Denken Sie daran, immer zuerst die spezifischere Regel hinzuzufügen.

Wenn Sie dagegen eine Umschreiberegel hinzufügen, deren Regex in der Regel bereits vorhanden ist, wird diese Regel von der neuen Regel überschrieben.

Permastrukturen

Es gibt einen einfachen Weg, um das oben genannte zu erreichen: add_permastruct. Diese Funktion wird von WordPress verwendet, um "Permastrukturen" zu erstellen, aus denen Umschreiberegeln (wie oben) generiert werden, die Paginierung und Feeds verarbeiten. Wenn Sie einen benutzerdefinierten Beitragstyp registrieren, erstellt WordPress nicht automatisch alle Umschreiberegeln. Stattdessen registriert es eine Permastruktur - und nur wenn die Regeln generiert werden (d. h. Wenn sie geleert werden), verwendet WordPress diese Permastrukturen, um die eigentlichen Umschreiberegeln zu generieren.

Ein Beispiel für eine Permastruktur ist die, die Sie unter Einstellungen - > Permalinks verwenden. Diese akzeptieren alle 'fest codierten' Slugs oder Tags, die standardmäßig vorhanden sind oder mit add_rewrite_tag hinzugefügt wurden, die wir in Teil 1 behandelt haben. Beispielsweise würde die Permastruktur %year%/%category%/%author% die folgenden Umschreiberegeln generieren:

www.example.com/2012/url-rewriting/stephen
www.example.com/2012/url-rewriting/stephen/page/2
www.example.com/2012/url-rewriting/stephen/feed/rss

www.example.com/2012/url-rewriting/
www.example.com/2012/url-rewriting/page/2
www.example.com/2012/url-rewriting/feed/rss

www.example.com/2012/
www.example.com/2012/page/2
www.example.com/2012/feed/rss

Die Funktion `add_permastruct`

Die Funktion add_permastruct akzeptiert vier Argumente:

name - Eine eindeutige Schnecke zur Identifizierung Ihrer Permastruktur
struct - Die Permastruktur selbst, z.B. '%year%/%category%/%author%'
with_front - wahr oder falsch. Dies ist das gleiche Argument wie bei der Registrierung des Beitragstyps
ep_mask - Siehe Abschnitt EP-Maske unten

Hier müssen einige Warnungen zur Verwendung von add_permastruct gemacht werden. Erstens: Sie sollten sicherstellen, dass eine benutzerdefinierte Permastruktur nicht mit den Umschreiberegeln von WordPress für Beiträge und Seiten in Konflikt gerät. Dies kann erreicht werden, indem Sie Ihrer benutzerdefinierten Permastruktur etwas Festcodiertes voranstellen. Beispielsweise:

1	'something-hard-coded/%year%/%monthnum%/%day%'

Zweitens - die Regeln werden in dieser Reihenfolge hinzugefügt - wenn Ihre Tags also "zu allgemein" sind, werden die letzteren Regeln möglicherweise nie angewendet. Zum Beispiel funktioniert die obige Struktur (die Sie auf Ihrer Seite Einstellungen - > Permalinks ausprobieren können) im Allgemeinen gut, außer dass:

1	www.example.com/2012/page/2

Wird als Seite mit Beiträgen des Autors '2' in der Kategorie 'Seite' im Jahr 2012 interpretiert. Wenn Sie add_permastruct verwenden möchten und Ihre Paginierungs- und Feed-Regeln gut kaskadieren möchten, müssen Sie Tags verwenden, die nicht 'generisch' sind. (womit ich meine, dass die Regex-Ausdrücke nicht generisch sind). %author% und %category% sind gute Beispiele für ein generisches Tag, da diese normalerweise mit jedem Zeichen übereinstimmen.

Beispiel für benutzerdefinierte Permastrukturen: Beitragstyp Datum Archiv

Die Tags für Jahr, Monat und Tag sind dagegen sehr spezifisch - sie stimmen nur mit positiven Ganzzahlen der Längen vier und zwei überein, sodass wir add_permastruct für das Datumsarchiv unseres Beitragstyps verwenden können. Aufgrund der besonderen Art der Datums-Tags müssen diese Regeln vor der Permalink-Regel für den Post-Typ hinzugefügt werden. Fügen Sie daher unmittelbar vor der Registrierung Ihres Post-Typs Folgendes hinzu:

// Please note that this will only work on WordPress 3.4+ http://core.trac.wordpress.org/ticket/19871

add_rewrite_tag('%book_cpt%','(book)s','post_type=');

add_permastruct('book_archive', '%book_cpt%/%year%/%monthnum%/%day%');

Oben fungiert das benutzerdefinierte Tag %book_cpt% als fest codierter Slug, um diese Permastruktur von anderen Regeln zu unterscheiden (gemäß der ersten Warnung). Die generierten Regeln gelten nur, wenn %book_cpt% mit 'books' übereinstimmt. In diesem Fall wird der Teil 'book' erfasst und als Wert für post_type interpretiert. Bitte beachten Sie, dass add_rewrite_tag nur das dritte Argument seit WordPress 3.4 akzeptiert. Sie können jedoch die folgende Problemumgehung verwenden:

1	global $wp_rewrite;
2	$wp_rewrite->add_rewrite_tag('%book_cpt%','(book)s','post_type=');

Wenn Sie die Bucharchive eingerichtet haben, können Sie das auch erwarten

1	www.example.com/books?year=2012

Würde uns auch zum Bucharchiv 2012 bringen. Das Testen zeigt jedoch, dass wir stattdessen zur Archivseite nach dem Jahr gelangen:

1	www.example.com/2012/

WordPress hat uns aufgrund einer so genannten Kanonisierung auf eine andere Seite weitergeleitet.

Kanonische Weiterleitung

In der Regel gibt es viele URLs, die auf denselben Inhalt Ihrer Website verweisen können. Beispielsweise:

www.example.com/year/2012

www.example.com/year/2012/page/1

www.example.com/2012/////////page/1

www.example.com/index.php/2012/

www.example.com/index.php////2012///page/1

Sie werden alle zur ersten Seite Ihres 2012-Archivs weitergeleitet. Aus SEO-Sicht ist dies nicht besonders gut - wir können nicht davon ausgehen, dass Suchmaschinen diese URLs als dieselbe Ressource erkennen und diese URLs möglicherweise miteinander konkurrieren. Google kann Sie auch aktiv für doppelte Inhalte bestrafen. Es ist zwar gut zu bestimmen, wann diese Duplizierung nicht "böswillig" ist, es wird jedoch empfohlen, diese überflüssigen URLs auf eine bevorzugte "kanonische" (oder Standard-) URL umzuleiten. Dies nennt man Kanonisierung.

Dies hilft nicht nur, Bewertungen wie die Beliebtheit von Links zu konsolidieren, sondern auch Ihren Benutzern. Wenn sie eine hässliche oder "falsche" URL verwenden - sie werden zur "richtigen" URL weitergeleitet - und in ihrer Adressleiste ist es wahrscheinlicher, dass sie zurückkehren.

Seit 2.1.0 hat WordPress die kanonische Umleitung übernommen und sogar den gesuchten Inhalt erraten, wenn die ursprüngliche Abfrage eine 404 zurückgegeben hat. Leider leitet WordPress in diesem Fall zur falschen URL um. Dies liegt daran, dass die von uns gewünschte URL von WordPress nicht nativ verstanden wird und der Teil "Beitragstyp" der URL ignoriert wurde. Glücklicherweise können wir jedoch den Filter redirect_canonical verwenden, um dies zu beheben.

add_filter('redirect_canonical', 'wptuts_redirect_canonical', 10, 2);
function wptuts_redirect_canonical($redirect_url, $requested_url) {

	global $wp_rewrite;

	// Abort if not using pretty permalinks, is a feed, or not an archive for the post type 'book'
	if( ! $wp_rewrite->using_permalinks() || is_feed() || ! is_post_type_archive('book') )
		return $redirect_url;

	// Get the original query parts
	$redirect = @parse_url($requested_url);
	$original = $redirect_url;
	if( !isset($redirect['query'] ) )
		$redirect['query'] ='';

	// If is year/month/day - append year
	if ( is_year() || is_month() || is_day() ) {
		$year = get_query_var('year');
		$redirect['query'] = remove_query_arg( 'year', $redirect['query'] );
		$redirect_url = user_trailingslashit(get_post_type_archive_link('book')).$year;
	}

	// If is month/day - append month
	if ( is_month() || is_day() ) {
		$month = zeroise( intval(get_query_var('monthnum')), 2 );
		$redirect['query'] = remove_query_arg( 'monthnum', $redirect['query'] );
		$redirect_url .= '/'.$month;
	}

	// If is day - append day
	if ( is_day() ) {
		$day = zeroise( intval(get_query_var('day')), 2 );
		$redirect['query'] = remove_query_arg( 'day', $redirect['query'] );
		$redirect_url .= '/'.$day;
	}

	// If paged, apppend pagination
	if ( get_query_var('paged') > 0 ) {
		$paged = (int) get_query_var('paged');
		$redirect['query'] = remove_query_arg( 'paged', $redirect['query'] );

		if ( $paged > 1 )
			$redirect_url .= user_trailingslashit("/page/$paged", 'paged');
	}

	if( $redirect_url == $original )
		return $original;

	// tack on any additional query vars
	$redirect['query'] = preg_replace( '#^\??&*?#', '', $redirect['query'] );
	if ( $redirect_url && !empty($redirect['query']) ) {
		parse_str( $redirect['query'], $_parsed_query );
		$_parsed_query = array_map( 'rawurlencode', $_parsed_query );
		$redirect_url = add_query_arg( $_parsed_query, $redirect_url );
	}

	return $redirect_url;
}

Die obige Funktion ist langwierig, aber nicht sehr kompliziert. Es könnte verbessert werden und ist nur als Beispiel dafür gedacht, was Sie mit dem Filter redirect_canonical tun können. Zuerst wird überprüft, ob hübsche Permalinks aktiviert sind, ob wir hinter unserem 'Buch'-Archiv her sind und ob es sich nicht um einen Feed handelt. Es prüft dann der Reihe nach:

Ist es ein Jahr-, Monats- oder Tagesarchiv? Wenn ja, entfernen Sie die Variable 'year' aus der Abfragezeichenfolge und setzen Sie die Weiterleitungs-URL auf www.example.com/books/[year]
Ist es ein Monats- oder Tagesarchiv? Wenn ja, entfernen Sie die Variable 'monthnum' aus der Abfragezeichenfolge und hängen Sie den Wert an die Weiterleitungs-URL an: www.example.com/books/[year/[monthnum]
Ist es ein Tagesarchiv? Wenn ja, entfernen Sie die Variable 'day' aus der Abfragezeichenfolge und hängen Sie den Wert an die Weiterleitungs-URL an: www.example.com/books/[year/[monthnum/[day]
Wenn eine ausgelagerte Variable vorhanden ist, hängen Sie diese an die Umleitungs-URL an

Tags in den Permalinks des Beitragstyps

Eine weitere Funktion, die für Beitragstypen oder Taxonomien nicht sofort unterstützt wird, ist die Verwendung von Tags in der Permalink-Struktur. Während Tags, die im 'Slug' des Rewrite-Arrays eines Beitragstyps (oder einer Taxonomie) verwendet werden, korrekt interpretiert werden, ersetzt WordPress diese Tags beim Generieren der Permalinks nicht durch die entsprechenden Werte - wir müssen sie selbst ersetzen. Die Verwendung solcher Tags unterbricht jedoch auch die Archivseite des Beitragstyps. Daher verwenden wir eine andere Methode. Nehmen wir als Beispiel an, wir möchten, dass unser benutzerdefinierter Beitragstyp "Buch" die folgende Struktur hat:

1	www.example.com/books/[some-genre]/[a-book]

Ich verwende das Beispiel einer benutzerdefinierten Taxonomie, aber die gleichen Methoden können für jede Permastruktur verwendet werden (z. B. einschließlich Datum, Autor oder sogar eines benutzerdefinierten Felds). Zunächst fügen wir die Umschreiberegel hinzu:

1	function wptuts_custom_tags() {
2	add_rewrite_rule("^books/([^/]+)/([^/]+)/?",'index.php?post_type=book&genre=$matches[1]&book=$matches[2]','top');
3	}
4	add_action('init','wptuts_custom_tags');

Jetzt verweist beispielsweise www.example.com/book/fiction/the-wizard-of-oz auf das Buch 'the-wizard-of-oz'. Der von WordPress generierte Permalink erzeugt jedoch immer noch www.example.com/book/the-wizard-of-oz. Der nächste Schritt besteht darin, den erzeugten Permalink zu ändern.

Wir haben im ersten Teil etwas Ähnliches gemacht, als wir ein benutzerdefiniertes Tag in der Post-Permalink-Struktur verwenden wollten. Dann haben wir den post_link Filter verwendet; Dieses Mal verwenden wir das Äquivalent für benutzerdefinierte Beitragstypen, den Filter post_type_link. Mit diesem Haken können wir unsere Struktur in die Permalinks der Bücher injizieren.

function wptuts_book_link( $post_link, $id = 0 ) {

	$post = get_post($id);

	if ( is_wp_error($post) || 'book' != $post->post_type || empty($post->post_name) )
		return $post_link;

	// Get the genre:
	$terms = get_the_terms($post->ID, 'genre');

	if( is_wp_error($terms) || !$terms ) {
		$genre = 'uncategorised';
	}
	else {
		$genre_obj = array_pop($terms);
		$genre = $genre_obj->slug;
	}

	return home_url(user_trailingslashit( "books/$genre/$post->post_name" ));
}
add_filter( 'post_type_link', 'wptuts_book_link' , 10, 2 );

Manipulieren von WordPress-Rewrites

Erweitern wir die obige Permalink-Struktur, um Folgendes zu erreichen:

Ein bestimmtes Buch: www.example.com/books/[some-genre/[a-book]
Alle Bücher eines Genres: www.example.com/books/[some-genre]
Alle Bücher: www.example.com/books/

Denken Sie daran, dass die Reihenfolge, in der Umschreiberegeln hinzugefügt werden, von Bedeutung ist. Insbesondere haben zuerst hinzugefügte Regeln Vorrang.

Also registrieren wir zuerst unser benutzerdefiniertes Taxonomie-Genre mit:

$args = array(
	...
	'rewrite' => array(
		'slug'=>'books'
	),
	...
)
register_taxonomy('genre',$args);

Dies fügt die folgende Permastruktur hinzu:

Bücher in einem Genre: www.example.com/books/[some-genre]

Nach der Registrierung der Taxonomie registrieren wir unseren benutzerdefinierten Beitragstyp wie folgt:

$args = array(
	...
	'rewrite' => array(
		'slug'=>'books'
	),
	...
)
register_post_type('book',$args);

Dies würde die folgenden Regeln registrieren:

Alle Bücher: www.example.com/books/ (was wir wollen)
Ein bestimmtes Buch: www.example.com/books/[a-book] (was wir nicht wollen)

Die zweite widerspricht jedoch der konkurrierenden Regel, die bei der Registrierung unserer Taxonomie hinzugefügt wurde (und wird von dieser "geschlagen"). Die resultierende Struktur ist:

Buch namens "Slug": www.example.com/books/fiction/slug
Bücher im Genre "Slug": www.example.com/books/slug
Alle Bücher: www.example.com/books/

EP_Masks

Früher, als wir uns mit der Registrierung von Beitragstypen, Taxonomien (oder anderen Permstrukturen) befassten, ließen wir WordPress unsere eigene 'ep_mask' angeben. Also was sind sie?

In Teil eins haben wir uns angesehen, wie wir mit add_rewrite_endpoint Endpunkte hinzufügen können. Das zweite Argument in dieser Funktion ist eine Konstante (oder eine Kombination von Konstanten mit bitweisen Operatoren), die bestimmen, wo der Endpunkt hinzugefügt wird. Beispielsweise:

1	add_rewrite_endpoint( 'form', EP_PAGES );

Fügt jedem Seitenpermalink das Umschreibung form(/(.*))?/?$ hinzu und:

1	add_rewrite_endpoint( 'json', EP_PAGES \| EP_PERMALINKS);

Fügt jedem Post- und Seitenpermalink den Umschreibung-json(/(.*))?/?$ hinzu. Diese Konstanten geben also einen "Ort" an (d. h. "Am Ende eines Post-Permalinks") und werden als Endpunktmasken (oder Ep-Masken) bezeichnet.

Wenn Sie einen Beitragstyp registrieren, registriert WordPress eine Permastruktur - und verknüpft damit eine Endpunktmaske. Wenn dann die Umschreiberegeln generiert werden, werden auch alle Endpunkt-Umschreiberegeln hinzugefügt, die dieser Endpunktmaske hinzugefügt wurden.

Wenn WordPress beispielsweise den Standard-Beitragstyp "Seite" registriert, ordnet es der Seitenpermastruktur die Endpunktmaske EP_PAGES zu. Anschließend werden alle zu EP_PAGES hinzugefügten Regeln zum Umschreiben von Endpunkten tatsächlich zu dieser Seitenpermastruktur hinzugefügt. Wenn Sie einen Beitragstyp registrieren, können Sie Ihre eigene Endpunktmaske angeben oder eine vorhandene verwenden. Standardmäßig ist dies EP_PERMALINKS. Dies bedeutet, dass alle Endpunkt-Umschreiberegeln, die zu EP_PERMALINKS hinzugefügt werden, zu den Umschreiberegeln Ihres benutzerdefinierten Beitragstyps hinzugefügt werden.

Natürlich möchten Sie möglicherweise keine Endpunktregeln für Ihren Beitragstyp hinzufügen (in diesem Fall können Sie die Endpunktmaske EP_NONE verwenden), oder Sie möchten möglicherweise nur Ihrem benutzerdefinierten Beitragstyp einige Regeln zum Umschreiben von Endpunkten hinzufügen. Dazu müssen Sie zunächst eine Endpunktmaske erstellen, die nichts anderes als eine Konstante ist, die Folgendes erfüllt:

Der Wert der Konstante ist eine positive Zahl und eine Potenz von 2:2^x(z. B. 2097152 = 2²¹).
Dieser Wert ist eindeutig

Die Potenz-2-Anforderung ist erforderlich, da WordPress mithilfe der binären Logik bestimmt, wo Endpunktregeln hinzugefügt werden sollen. Leider ist dies fast unmöglich zu überprüfen, so dass der beste Rat darin besteht, Endpunktmasken nur bei Bedarf hinzuzufügen und einen sehr hohen Wert zu vergeben (z. B. 2²¹). Zum Zeitpunkt des Schreibens werden 2⁰ bis 2¹³ von Core verwendet.

Definieren Sie Ihre Endpunktmaske kurz vor der Registrierung Ihres Beitragstyps oder Ihrer Taxonomie:

	define('EP_BOOK', 8388608); // 8388608 = 2^23

	$args = array(
		'labels' => $labels,
		'has_archive'=>true,
		'rewrite' => array(
			'slug'=>'books'
			'with_front'=> false
			'feed'=> true
			'pages'=> true
			'ep_mask'=> EP_BOOK
		)
	);

	register_post_type('book',$args);

	// Then you can endpoint rewrite rules to this endpoint mask
	add_rewrite_endpoint('loan', EP_BOOK);

(Hinweis: In den obigen Ausführungen werden WordPress 3.4-Argumente verwendet. Wenn Sie eine ältere Version von WordPress verwenden, müssen Sie die jetzt veraltete permalink_epmask verwenden.) Ab WordPress 3.4 können Sie auch bei der Registrierung einer Taxonomie eine Endpunktmaske angeben.

Zusammenfassung

In diesem Tutorial habe ich die Grundlagen der Rewrite-API für Beitragstypen und Taxonomien, aber auch einige fortgeschrittenere Themen behandelt. Die Handhabung von Umschreibungen durch WordPress ist (notwendigerweise) komplex. Der beste Weg, dies zu verstehen, besteht darin, sich mit dem Quellcode zu befassen und ihn mit dem Gelernten und einem Plug-In für den Umschreibeanalysator zu testen.

Derzeit arbeiten sich einige Tickets durch die WordPress-Entwicklungs-Trac, die sich auf die Rewrite-API beziehen. In Zukunft sehen wir eine viel einfachere und konfliktfreie Möglichkeit, Endpunktmasken zu übergeben.