Ryan Boren, ein Entwickler von WordPress, hat in einem Artikel (engl.) einmal genauer erläutert, wie die neuen Benutzerlevels in Zukunft eingesetzt werden. Ich fand diesen Artikel interessant, so dass ich mich mal hingesetzt und das ganze Geraffel übersetzt habe:
Einer, der am meisten kritisierten Aspekte bei WordPress ist das System, mit dem die Benutzerrechte geregelt werden. Bei den Versionen 1.5.x und früher, geschieht das über Benutzer-Level. Jedem Benutzer ist hier ein Level zwischen 0 und 10 zugeordnet, wobei 10 die vollen administrativen Rechte, und Null praktisch keine Befugnisse hat. Die Level sind ausserdem hierarchisch. Der Benutzer eines höheren Levels kann die Beiträge eines Benutzers eines niedrigeren Levels bearbeiten. Das hört sich nach einem guten und einfachen Schema an, aber in der Praxis sorgt es doch für eine Menge Durcheinander. Die mit einem Level verbunden Privilegien sind nämlich alles andere als klar. Was ist der Unterschied zwischen Level Zehn und Level fünf? Wer kann hier wen bearbeiten? Kann ein Level fünf ein anderen Level fünf bearbeiten? Was genau kann jede der elf Level tun?
Für die 2.0er Version haben wir entschieden, dass dieses System einer Überholung bedarf. Nachdem wir einmal nachgeschaut haben, wie andere Weblog- und CMS Applikationen mit den Rechten umgehen, haben wir uns für ein Modell mit Rollen und Befugnissen entschieden. Nach einer Diskussion über den Ablauf, den wir etablieren wollten, begannen wir mit der Kreation von fünf Rollen: Registrierter Leser, Mitarbeiter, Autor, Herausgeber und Administrator. Jede dieser Rollen hat eine Sammlung von verknüpften Befugnissen. Ein registrierter Leser hat sehr begrenzte Befugnisse. Er kann den Tellerrand sehen und sein eigenes Profil bearbeiten. Das ist alles. Ein Mitarbeiter darf Entwürfe herstellen, diese aber nicht veröffentlichen. Ein Autor kann Beiträge veröffentlichen. Ein Herausgeber kann nicht nur die Beiträge anderer bearbeiten, sondern darf auch Kategorien, Linklisten, Kommentare und statische Seiten verwalten. Ein Administrator kann alles machen. Er kann die Themes “umschalten”, Plugins aktivieren, Dateien bearbeiten und Importer einsetzen.
Obwohl diese Rollen hierarchisch zu sein scheinen, sind sie es nicht. Jede Rolle ist einfach nur eine Sammlung von Befugnissen. Die Rollen der Herausgeber und Administratoren haben jetzt auch die Befugnis, Beiträge zu bearbeiten, die nicht von ihnen sind. Sie dürfen in sämtliche Beiträge des Blogs eingreifen. Auch in die, der eigenen Rollen. Für diejenigen, die noch die alte Level-Hierarchie gewohnt sind, mag es merkwürdig sein, Herausgebern und Administratoren das Bearbeiten von Beiträgen zu erlauben. Die Hierarchien zu vermeiden war jedenfalls eine wegweisende Entscheidung. Man hat jetzt entweder die Befugnis andere Beiträge zu bearbeiten, oder nicht. Wir versuchen es einfach zu halten.
Benutzer können eine, oder mehrere Rollen haben und individuelle Befugnisse bekommen, die ihnen auch ausserhalb des Contextes ihrer Rolle zugeordnet werden können. In der Standardeinstellung ist zunächst lediglich eine Rolle für jeden Benutzer vorgesehen. Man wählt eine der fünf Rollen für den Benutzer aus und voilá, das war es dann auch schon. Man kann weder mehrere Rollen vergeben, noch individuelle Befugnisse den Benutzern erteilen.
Es ist eine zweckmäßige Entscheidung mit der Intention die Dinge einfach zu halten. Die Möglichkeit weiterführende Rollen und Befugnisse zu verwalten, wird durch ein Plugin zur Verfügung gestellt werden.
Derzeit sind etwa zwanzig Befugnisse definiert. Im Quelltext sind Befugnisse einfach nur Schlüsselwörter, die Benutzern und Rollen zugewiesen werden können.
Hier nun unser komplette Sammlung an Befugnissen.
- switch_themes
- edit_themes
- activate_plugins
- edit_plugins
- edit_users
- edit_files
- manage_options
- moderate_comments
- manage_categories
- manage_links
- upload_files
- import
- unfiltered_html
- edit_posts
- edit_others_posts
- edit_published_posts
- publish_posts
- edit_pages
- read
Um mit dem bisherigen Benutzerlevel-System kompatibel zu sein, haben wir Befugnisse, die mit den früheren Levels korrespondieren: level_0, level_1, … , level_10.
Ein registrierter Leser hat die level_0 Befugnisse.
Ein Mitarbeiter hat die von level_0 und level_1.
Der Autor wiederum hat die Befugnisse der level_0, level_1, und level_2.
Ein Herausgeber ist mit den Befugnissen von level_0 bis level_7 ausgestattet und
die Befugnisse des Administrators reichen von level_0 bis level_10.
Beim Upgrade von früheren WP-Versionen bekommen alle Benutzer Rollen, die ihren früheren Benutzerleveln entsprechen. Ein Level-7 Benutzer bekommt beispielsweise die Rolle eines Herausgebers.
Für Plugin Autoren ist ein API erhältlich, um Rollen und Befugnisse abrufen und verändern zu können. Ein Plugin kann eine neue Befugnis mit dem Namen “do_foo” herstellen, die dem Administrator mit dem folgenden Code zugeordnet wird:
$role = get_role('administrator');
$role->add_cap('do_foo');
Um herauszufinden, ob der derzeitige Benutzer überhaupt diese Befugnis besitzt, können sich Plugins der current_user_can() Funktion bedienen:
if ( current_user_can('do_foo') ) ...
Um die Befugnisse einer bestimmten Benutzer-ID herauszufinden erstellt man ein WP_User Objekt:
$user_id = 1;
$user = new WP_User($user_id);
if ( $user->has_cap('do_foo') ) ...
Wenn eine völlig neue Rolle erstellt werden soll, kann man das mit add_role() und add_cap() realisieren.
$role = add_role('foo_doer', 'Foo Doer');
$role->add_cap('do_foo');
$role->add_cap('do_bar');
Soviel zu den Grundlagen. Für die komplette API gehe zu der Datei capabilities.php
Am meisten wird bei der API current_user_can() benutzt. Wann immer du bestimmen möchtest, was der angemeldete Benutzer machen darf, benutze current_user_can().
Für weitere Informationen zu den Rollen und Befugnissen, gehe zu Owens Übersicht. Wenn Du ein Plugin Autor bist und Fragen zur API und mehr hast, besuche die Hackers List und wenn Du ein Benutzer bist, der sich gerade fragt, was das alles zu bedeuten hat, besuche die Support Foren.
