Kylaloo

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.

Die Tage werden kürzer, die Nächte kälter und kein Urlaub weit und breit.

Es gibt da etwas, was ich schon immer mal machen wollte, aber schon auf halber Strecke immer wieder auf die lange Bank geschoben habe. Und ich bin mir ziemlich sicher, dass es jedem herumbosselnden User genauso durch den Kopf gegangen sein muß, seitdem er WordPress benutzt.

Tja, und jetzt ist es passiert.

Die Rede ist hier von einer kompletten deutschsprachigen WordPress-Installation. Eine ohne wenn und aber. Ich habe WordPress für meinen typischen deutschen User einmal zusammengestellt und all das eingebaut, was mir dabei irgendwie wichtig erschien. Es ist mein bescheidener Versuch, den Installationsvorgang einer deutschen WordPress Version (1.5.2) soweit, wie es mir möglich ist, zu automatisieren.

Herausgekommen ist dabei ein Komplettpaket für alle, die entweder zu faul, zu gestresst, oder schlicht zu unbeholfen sind, sich WordPress selbst vernünftig zu installieren und ins Deutsche zu übertragen. Aber keine falschen Hoffnungen: Das Ergebnis ist hier keine aufgeblasene Pimp-, sondern vielmehr eine möglichst fehlerfreie und saubere PureVersion.

Das habe ich gemacht:

• Die Installationsrutine übersetzt (auch die Fehlermeldungen).
• Das Standardtemplate (de) überarbeitet, eingebaut und aktiviert.
• Die deutsche Sprachdatei aktualisiert und eingebettet.
• Die wichtigsten Plugins sind assimiliert und an Ort und Stelle aktiviert.
• Die leidigen Probleme mit dem amerikanischen Datumsformat sind beseitigt.
• Die WordPress Dokumente sind übersetzt und verlinkt.
• Der erste Artikel und der erste Kommentar sind übersetzt.
• Eine (leere) .htaccess Datei der Installation hinzugefügt.
• Deutschsprachige Bestätigungsmail nach der Einrichtung.

Viel muß der Benutzer jetzt nicht mehr tun, damit WordPress zum Leben erweckt werden kann. Nur zwei, drei dumme Dinge bleiben knifflig.

1. Er muß eine Datenbank auf dem Server einrichten und die dazu gehörenden Daten korrekt in die wp-config.php eingeben. Ich bin mir aber ziemlich sicher, dass ihm sein Hoster dabei gerne helfen wird, sodass das halbwegs angenehm über die Bühne gehen kann.
2. Er muß verstehen, wie man die Dateien mit einem FTP Programm auf den Server bringt. Auch hier müsste ihm der Hoster gutgelaunt mit Rat und Tat zur Seite stehen, denn das ist ja schließlich sein Job.
3. Um wenigstens Bilder im Internetcafé hochladen zu können, muß er herausfinden, was “Rechte” sind und wie man sie vergibt. Das gerade erwähnte FTP Programm sollte in der Lage sein, diese Rechte unkompliziert zu vergeben. Wenn nicht, dann wird es Zeit, sich nach einem besseren umzuschauen.

Also gut, kommen wir endlich zur Installation der deutschen WP-Edition. Sie wird grundsätzlich genauso installiert, wie die internationale Version und das kann man einer unkomplizierten Anleitung entnehmen, die bei der deutschen WordPress Community zu finden ist. Das schöne daran: Bei Problemen kann man gerne im Forum vorbeischauen.

Wo wir gerade dabei sind: Ohne die inzwischen tagtäglichen Arbeit aller Mitglieder im Portal und der Dokumentation, wäre dieses Paket sowieso nie denkbar gewesen. Mal eine Zahl als Beispiel: Die Sprachdatei hat die sagenhafte Dimension von 931 Zeichenketten, die alle peinlich genau von Hand übersetzt werden mussten. (Hallo Annette) Wir sammeln und aktualisieren noch heute, die kleinsten Fehlerchen und diverse Formulierungen.

Wie üblich bei solchen Sachen, kann es auch mal sein, dass im ganzen Durcheinander etwas übersehen wurde. Wer etwas erwähnenswertes findet und dazu noch einen sonnigen Tag erwischt hat, sollte sich nicht scheuen, mit mir umgehend Kontakt auzufnehmen. Gut gelaunt fomulierte Fehlermeldungen tun nämlich nur halb so weh, wie besserwisserische, die so auffallend gerne mit ungemütlichem kalten Regen zusammenfallen.

Apropos Kritik.

Die Installation, sowie der Gebrauch und Einsatz geschieht hübsch auf eigene Gefahr.

Im Zeitalter der überzüchteten Glamour-Plugins wollte ich an dieser Stelle einmal erwähnen, welche Helfer für mich die wichtigsten sind. Sie wirken langweilig, verrichten klaglos im Hintergrund ihren Dienst und können meistens nichtmal irgendwo eingestellt werden. Also die klassischen Arbeiterplugins, wenn man so will.

Für mich mit Abstand am wichtigsten, ist Papa Scotts Umlaut Plugin. Die meisten User glauben nämlich auch heute noch, dass Wordpress die Umlaute im Titel, selbstverständlich genauso, wie wir, durch Zweierkombinationen ersetzt. Also dass es aus einem ä, ö, ü und ß ein ae, oe, ue und ss macht. Dem ist aber nicht so. Wordpress radiert hier lediglich die Pünktchen weg und übersetzt das scharfe “s” mit einem weichen.

Ein Fehler? Nicht ganz. Es ist eine Konvention. Die Amis machen das eben so.

Eine Kuh macht muh. Viele Kuhe machen Muhe.

Hat man dieses Plugin aber gluücklich aktiviert, dann gilt auch in WordPress ab sofort wieder unsere gewohnte Umschreibung. Haken: Kann man die sog. schönen URLs nicht benutzen, dann macht dieses Plugin auch keinen Sinn, denn dann setzt WordPress in den Titel sowieso nur eine kryptische Zahlenkombination.

[Update:]
Gerade eine vielversprechende Steigerung des Plugins über das Forum entdeckt.

Kryptische Zahlenkolonnen kennt man auch von Spam und da sind wir auch schon bei meinem zweitliebsten Pluginkind dem Spam-Nuker von Chris Davis. Das besondere daran ist, dass dieses Werkzeug Spam sichtbar macht (und damit auch löschbar), den wir sonst nicht sehen können. Das liegt daran, dass WordPress merkwürdigerweise Kommentare, die mit dem Attribut Spam gekennzeichnet wurden, zwar von der Bildfläche verschwinden lässt, aber eben nicht löscht. Diese Kommentare lungern dann ziemlich nutzlos in der Datenbank herum. Ich weiß nicht mehr so genau, warum das so ist, habe aber dieses Phänomen schon einmal ausführlich beschrieben. Dieses Plugin habe ich derartig lieb gewonnen, dass ich es nicht nur übersetzt, sondern auch etwas Benutzerfreundlicher umgestellt und aufgeräumt habe.

Die Diskussion über das nofollow Attribut ist kaum abgeebbt, da weiß schon kein Mensch mehr, was das überhaupt ist. Es geht um die vermeintliche Bekämpfung von Spam bei den Suchmaschinen. Man ging davon aus, dass ein Spammer daran interessiert ist, einen möglichst hohen Pagerank bei Google zu erhalten. Man dachte weiter und sah, dass Spamkommentare in Weblogs genau diesen Pagerank in die Höhe treiben könnten.

Hier greift nun das Attribut nofollow, das bei WorfPress, seit der Version 1.5 standardmäßig fest im Programm verankert ist und an jeden Link in den Kommentaren angepappt wird. Trifft also eine Suchmaschine auf dieses Attribut, dann wird der dazugehörige Link als Ranksteigerer ignoriert. Da grundsätzlich alle Links in den Kommentaren davon betroffen sind, werden also auch die “guten” Links gebrandmarkt.

Die Erfahrung hat mittlerweile gezeigt, dass sich die Spammer einen Teufel darum scheren, ob sie ignoriert werden, oder nicht. Die verschicken ihren Müll so oder so. Wirklich erstaunt hat das natürlich niemand, aber es stört auch keinen mehr, dass die guten Kommentare weiterhin nicht so gewürdigt werden, wie es sich eigentlich gehört. Andere mögen diesen Fauxpas stumpf vor sich hin vergessen, genau so, wie sich das die Suchmaschinenbetreiber händereibend wünschen. Mein geliebtes do-follow-Plugin bleibt jedenfalls installiert und ich werde weiterhin jeden Kommentarlink beklatschen, dem es dieses Attribut erfolgreich entzogen hat.

Ich habe mehrere Gründe, warum ich Olafs Update Monitor bei mir einsetze. Zum einen bleibe ich stets auf dem Laufenden, wenn sich bei WordPress etwas neues tut und zum anderen bin ich auch maßlos stolz darauf, was unsere Community alles auf die Beine stellt. Ich bin mir sicher, dass wir da noch mit mancher Überraschung daherkommen werden.