Bei der Registrierung eines neuen Artikeltyps können Sie selbst festlegen welche Rechte ein Benutzer haben muss um Artikel des Typs editieren, veröffentlichen, lesen und löschen zu dürfen. Dazu existieren drei Parameter:

• capability_type (string|array)
• capabilities (array) und
• map_meta_cap (bool)

Wenn Sie diese Parameter nicht definieren, wird WordPress Ihren neuen Artikeltyp so anlegen wie den Typ „Beitrag“ (registriert als post). Nämlich mit folgenden Capabilities:

• edit_post
• edit_posts
• edit_others_posts
• publish_posts
• read_post
• read_private_posts und
• delete_post.

Das hat zur Folge, dass die Rechtestruktur genau so aufgebaut wird, wie sie auch für den Artikeltyp post verwendet wird. Wenn Sie jedoch für unterschiedliche Benutzer unterschiedliche Rechte anlegen wollen, kommen sie nicht umher, eigene Capabilities zu erstellen. Diese können dann bestimmten Rollen zugeordnet werden.

11.2.1. Der Parameter capability_type

Erweitern wir das Beispiel aus dem vorherigen Kapitel wie folgt:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Wie Sie sehen, haben wir nun das Argument capability_type von post auf book geändert. Dies generiert nun folgende Capability-Sets automatisch für Sie:

• edit_book
• edit_books
• edit_others_books
• publish_books
• read_book
• read_private_books und
• delete_book.

Hinweis

Achten Sie darauf, dass Sie dem Argument capability_type den Namen des neuen Capabilities im Singular übergeben (also book und nicht books). Die Verwendung des Plural (books) würde dazu führen, dass den Capability-Sets ein doppeltes s angehängt wird:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Die einzelnen Rechte haben nachfolgende Bedeutungen:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

11.2.2. Die Parameter capabilities und map_meta_cap

Die volle Kontrolle über jedes einzelne Capability gibt das Argument capabilities. Es erlaubt die separate Benennung jedes einzelnen Rechts.

Wichtig zu Wissen ist folgendes: es gibt drei so genannte Meta-Capabilities, die selbst nicht direkt zu Rollen zugewiesen werden (können). Es wird später also nicht geprüft, ob ein Benutzer mit einer bestimmten Rolle das Recht hat z.B. einen Artikel zu bearbeiten, sondern welche Rechte benötigt werden um das zu tun. Damit ist es möglich den Artikeltyp so einzurichten, dass jeder Benutzer nur seine eigenen Artikel bearbeiten kann, nicht jedoch andere. Wichtig ist also: Meta-Capabilities beziehen sich auf Objekte, nicht auf Rollen.

• edit_post
  Prüft ob ein Benutzer einen spezifischen Artikel bearbeiten darf.
• read_post
  Prüft ob ein Benutzer einen spezifischen Artikel lesen darf.
• delete_post
  Prüft ob ein Benutzer einen spezifischen Artikel löschen darf.

Dazu kommen fünf primitive Capabilities die einer Rolle zugewiesen werden müssen damit sie funktionieren. Sie prüfen den generellen Zugriff auf eine bestimmte Aktion.

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Zum Schluss gesellen sich dann noch sechs weitere Capabilities hinzu die in der Funktion map_meta_cap() eine Rolle spielen und nur dann registriert werden, wenn map_meta_cap auf true gesetzt wird.

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Im ersten Beispiel entfernen wir den Parameter capability_type und fügen stattdessen capabilities ein.

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Hier wurden alle Rechte so umbenannt, wie man es erwarten würde. Jedes Capability erhält das genau Gegenstück mit Erweiterung book. Lediglich das primitive Capability edit_posts wurde gelassen, wie es ist. Das hat zur Folge, dass z.B. ein Benutzer mit der Rolle “Redakteur“ (engl. “editor“) das Menü „Books“ sehen und neue Artikel diesen Typs anlegen darf, sonst aber keine Rechte hat.

Aber, Sie werden feststellen, dass das Anlegen gar nicht funktioniert. Und das, obwohl im Menü der Link “Add New“ bzw. “Erstellen“ erscheint. Warum?

Das liegt daran, dass das Argument map_meta_cap deaktiviert wurde. Im Beispiel 2 müssen wir es also explizit aktivieren damit die Rechte des Objekts festgestellt werden können:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

Beispiel 3: Folgendes Beispiel hat die gleiche Funktionalität wie Beispiel 2. Jedoch muss der Rolle “Redakteur“ nun das Recht edit_books gewährt werden, da beim Speichern nun das Recht edit_books abgefragt wird (da die WordPress interne Behandlung der Meta-Capabilities explizit deaktiviert wurde):

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.

11.2.3. Zugriff explizit sperren

Durch die Capability do_not_allow lassen sich komplette Funktionen sperren. Folgendes Beispiel verbietet das Löschen von einmal erstellten Artikeln:

Dieser Inhalt ist nur eingeschränkt verfügbar. Melden Sie sich vorher an.