WordPress Rollen und Berechtigungen für Entwickler

WordPress bringt eine vollständige Zugriffskontrollliste mit, und kaum jemand nutzt sie. Der Berechtigungsfehler, den wir auf Kundenseiten am häufigsten sehen, ist kein ungepatchtes Plugin, sondern eine Redakteurin mit der Rolle Administrator, weil sie einmal ein Menü umsortieren sollte. Dieser Leitfaden zeigt, was die API für Rollen und Berechtigungen auf Quellcode-Ebene tatsächlich tut: wo die Daten liegen, warum add_role() Ihren zweiten Aufruf stillschweigend ignoriert, worauf eine Prüfung auf einen Rollennamen wirklich hinausläuft und welche Berechtigungen weiter reichen, als ihr Name vermuten lässt.

Mehr zu unseren Sicherheitsleistungen für WordPress finden Sie bei WPPoland.

Eine einzige Änderung erledigt fast die ganze Arbeit: Hören Sie auf, in Ihren Bedingungen Rollen zu nennen, und nennen Sie die Berechtigung, die der Code braucht. Der Rest dieses Leitfadens beschreibt, was das in der Praxis kostet, und es ist die Grundlage der Arbeit jedes WordPress-Entwicklers, der Sicherheit ernst nimmt.

#1. Unterschied zwischen Rolle und Berechtigung in WordPress

Das Rechtesystem von WordPress beruht auf zwei Begriffen, die Sie trennen sollten, bevor Sie irgendeine Zugriffslogik schreiben.

#Berechtigung (cap)

Ein konkretes Recht, eine Sache zu tun. Berechtigungen sind die atomaren Einheiten des Systems. Beispiele: edit_posts, publish_pages, install_plugins, manage_options und edit_theme_options.

Berechtigungen können primitiv sein (direkt in der Rollenzeile gespeichert) oder Meta-Berechtigungen (zur Laufzeit von map_meta_cap() je nach Kontext aufgelöst). So ist edit_post eine Meta-Berechtigung, die zu edit_posts oder edit_others_posts aufgelöst wird, je nachdem, ob der Benutzer der Autor des Beitrags ist.

#Rolle

Eine Sammlung von Berechtigungen unter einem Namen. WordPress speichert das Bündel und wertet die Zeichenkette aus.

Die Standardbündel sind kleiner, als man annimmt. Laut der Dokumentation zu Rollen und Berechtigungen hat Redakteur 26 Berechtigungen und Autor sieben: read, upload_files, edit_posts, edit_published_posts, publish_posts, delete_posts, delete_published_posts. Mitarbeiter hat drei: read, edit_posts, delete_posts. Ein Mitarbeiter kann keine Datei hochladen, und deshalb endet “machen Sie ihn einfach zum Mitarbeiter” in einem Ticket zur Mediathek.

Redakteur ist der interessante Fall. Auf einer Einzelinstallation hat die Rolle unfiltered_html, ein Redakteur kann also ein <script>-Tag im Inhalt speichern. In Multisite wird diese Berechtigung allen außer Super-Admins verweigert, wie map_meta_cap() zeigt:

if ( defined( 'DISALLOW_UNFILTERED_HTML' ) && DISALLOW_UNFILTERED_HTML ) {
    $caps[] = 'do_not_allow';
} elseif ( is_multisite() && ! is_super_admin( $user_id ) ) {
    $caps[] = 'do_not_allow';
} else {
    $caps[] = 'unfiltered_html';
}

Was Redakteur nicht hat: edit_theme_options, list_users, edit_users, manage_options und nichts, was mit Plugins zu tun hat.

#Berechtigungen statt Rollen prüfen

Prüfen Sie Berechtigungen, nie Rollennamen.

// FALSCH - niemals so machen
if ( current_user_can( 'administrator' ) ) { ... }

// RICHTIG - immer Berechtigungen prüfen
if ( current_user_can( 'manage_options' ) ) { ... }

Die erste Zeile ist kein Syntaxfehler, sondern etwas Schlimmeres: Sie liefert genau in dem Fall die richtige Antwort, den Sie getestet haben. Der Grund ist eine Zusammenführung am Ende von WP_User::get_role_caps():

$this->allcaps = array();
foreach ( (array) $this->roles as $role ) {
    $the_role      = $wp_roles->get_role( $role );
    $this->allcaps = array_merge( (array) $this->allcaps, (array) $the_role->capabilities );
}
$this->allcaps = array_merge( (array) $this->allcaps, (array) $this->caps );

$this->caps ist das rohe Benutzer-Meta wp_capabilities, und seine Schlüssel sind Rollennamen. Deshalb landet administrator => true neben echten Berechtigungen in allcaps und besteht die Prüfung aus Versehen. Die Dokumentation zu current_user_can() sagt es so: Die Prüfung auf bestimmte Rollen statt auf eine Berechtigung wird nur teilweise unterstützt und wird nicht empfohlen, weil sie unzuverlässige Ergebnisse liefern kann (eigene Übersetzung).

Drei Arten, wie Sie das trifft, alle drei auf echten Websites gesehen:

1. Sie legen eine eigene Rolle mit manage_options an, damit ein Kunde Ihre Einstellungsseite erreicht. current_user_can('administrator') ist für ihn false, und Ihre eigene Seite liefert genau dem Benutzer einen 403, für den sie gebaut wurde.
2. Eine Berechtigung, die direkt am Benutzerobjekt ohne zugehörige Rolle vergeben wurde, besteht jede Berechtigungsprüfung und fällt bei jeder Rollenprüfung durch.
3. In Multisite schließt WP_User::has_cap() für Super-Admins kurz, bevor es allcaps überhaupt ansieht, und liefert true für alles außer do_not_allow. Dort unterscheidet eine Rollenprüfung gar nichts.

#2. Eigene Rolle in WordPress erstellen

Bevor Sie eine schreiben, prüfen Sie, ob die Plattform sie schon mitbringt. WooCommerce legt bei der Installation shop_manager und customer an, und laut seiner Dokumentation zu Rollen kann der Shop-Manager bereits Produkte, Bestellungen, Gutscheine und Kundenkonten verwalten. Wer einen parallelen “Shop-Manager” baut, dupliziert eine Rolle, die im Release-Zyklus eines anderen gepflegt wird.

Wenn Sie wirklich eine brauchen, sieht das so aus:

add_role(
    'editorial_lead',
    'Redaktionsleitung',
    [
        'read'                 => true,
        'upload_files'         => true,
        'edit_posts'           => true,
        'edit_others_posts'    => true,
        'edit_published_posts' => true,
        'publish_posts'        => true,
        'delete_posts'         => true,
        'moderate_comments'    => true,
    ]
);

Zwei Dinge an diesem Aufruf ergeben sich nicht aus der Signatur.

Er schreibt einmal und ignoriert Sie danach. Das Plugin-Handbuch hält fest, dass die Rolle und ihre Berechtigungen nach dem ersten Aufruf in der Datenbank gespeichert sind und weitere Aufrufe nichts bewirken, auch keine Änderung der Berechtigungsliste (eigene Übersetzung). Sie bearbeiten das Array, deployen, und nichts ändert sich. Jede Änderung der Berechtigungen braucht deshalb eine ausdrückliche Migration:

const EDITORIAL_LEAD_VERSION = 3;

function wppoland_sync_editorial_lead() {
    if ( (int) get_option( 'wppoland_editorial_lead_version' ) === EDITORIAL_LEAD_VERSION ) {
        return;
    }

    remove_role( 'editorial_lead' );
    add_role( 'editorial_lead', 'Redaktionsleitung', [ /* ... */ ] );

    update_option( 'wppoland_editorial_lead_version', EDITORIAL_LEAD_VERSION );
}
register_activation_hook( __FILE__, 'wppoland_sync_editorial_lead' );
add_action( 'admin_init', 'wppoland_sync_editorial_lead' );

Die zweite Registrierung auf admin_init zählt in Multisite und bei Deployments, die nie einen Aktivierungs-Hook auslösen. Die Versionsprüfung hält den Code aus dem heißen Pfad heraus, und das Handbuch warnt, dass bedingungsloses Entfernen und Neuanlegen der Rolle die Performance erheblich verschlechtert.

remove_role() fasst die Benutzer nicht an. Die Funktion entfernt den Schlüssel aus der Optionszeile. Jeder Benutzer, dessen Meta wp_capabilities weiterhin editorial_lead => true enthält, behält diesen Schlüssel, WP_Roles::is_role() liefert dafür aber false, und der Schlüssel wird nie in Berechtigungen aufgelöst. Der Benutzer behält eine Zeichenkette, die nichts gewährt. Weisen Sie die Benutzer vor dem Entfernen einer Rolle neu zu, oder direkt danach.

Wo die Zeile wirklich liegt. WP_Roles::for_site() baut den Schlüssel als $wpdb->get_blog_prefix( $this->site_id ) . 'user_roles'. Auf einer Einzelinstallation mit Standardpräfix ist das wp_user_roles. Auf Unterseite 3 eines Netzwerks ist es wp_3_user_roles, und deshalb ist eine auf einer Unterseite angelegte Rolle auf der nächsten unsichtbar. Wenn Sie Rollen im Code definieren und nie in die Datenbank schreiben wollen, setzen Sie die globale Variable $wp_user_roles in wp-config.php: WordPress nutzt dann diese, und in den Worten der Core-Referenz wird die Rollenoption weder aktualisiert noch verwendet (eigene Übersetzung).

#Rollenbezeichnungen auf mehrsprachigen Websites

Das zweite Argument von add_role() ist die sichtbare Bezeichnung, und WP_Roles::add_role() speichert sie so in der Optionszeile, wie sie ankommt. Wenn Sie sie in __() einpacken, wird die Zeichenkette in der Sprache gespeichert, die bei der Aktivierung aktiv war, nicht in der Sprache dessen, der später den Benutzerbildschirm öffnet. Bei der Anzeige reicht wp_dropdown_roles() die Bezeichnung durch translate_user_role(), das mit dem Kontext User role und der Textdomain default übersetzt. Das deckt die Core-Rollen ab, deren Zeichenketten im WordPress-Katalog stehen, und nicht die Bezeichnung Ihres Plugins. Speichern Sie auf einer mehrsprachigen Website den Slug und die englische Bezeichnung, und bauen Sie keine Logik auf der Bezeichnung auf: Der Slug ist der stabile Bezeichner.

#3. Berechtigungen zu einer bestehenden Rolle hinzufügen

get_role() plus add_cap() ist die kleinste Änderung, wenn eine Standardrolle fast passt:

$role = get_role( 'editor' );
if ( $role ) {
    $role->add_cap( 'edit_theme_options' );
}

Verwenden Sie dieselbe Versionsprüfung wie in Abschnitt 2. WP_Role::add_cap() nimmt genau zwei Parameter, add_cap( $cap, $grant = true ), und der zweite entscheidet, ob die Berechtigung gewährt oder ausdrücklich verweigert wird, nicht, ob die Zeile geschrieben wird. Einen dritten Parameter gibt es hier nicht. Die Form mit drei Argumenten gehört zu WP_Roles::add_cap( $role, $cap, $grant ), einer anderen Klasse, und das ist die Methode, an die WP_Role::add_cap() delegiert. Diese Methode setzt die Berechtigung und ruft update_option() auf, sobald use_db true ist, bei jedem Aufruf. Kein Argument unterdrückt den Schreibvorgang. add_cap() ohne Absicherung auf init bedeutet also bei jeder Anfrage einen Schreibversuch auf die Option.

#Reichweite von edit_theme_options in Block-Themes

Das größere Problem dieser konkreten Zeile ist die Reichweite. edit_theme_options ist der klassische Kniff “der Redakteur soll die Menüs verwalten”, und in einem klassischen Theme tut er ungefähr das: Design mit Widgets, Menüs, Customizer und Header. In einem Block-Theme ist es eine andere Berechtigung. Die Core-Dokumentation nennt sie inzwischen die wichtigste Berechtigung, die WordPress prüft, wenn es entscheidet, ob ein Benutzer im Website-Editor auf Templates zugreifen und sie verwalten darf, und warnt, dass sie nicht ausschließlich auf den Website-Editor beschränkt ist und Zugriff auf weitere themebezogene Verwaltungsfunktionen geben kann (eigene Übersetzung).

Der Redakteur, der ein Menü umsortieren sollte, hat jetzt also den Website-Editor: Templates, Template-Teile, globale Stile und Navigation. Das ist eine weitere Freigabe als switch_themes, das nur Design und Design > Themes freilegt.

Wenn Sie wirklich eine Rolle für den Website-Editor wollen, listet die Dokumentation auf, was nötig ist: edit_theme_options für den Zugriff und das Navigationsmenü, dazu edit_posts, edit_pages und edit_others_posts für die Verwaltung der Templates, read für die Vorschau und upload_files für Medien.

Der Fehlerfall ist hier still, weil der Website-Editor mit der REST-API spricht. Die Endpunkte für Templates und Template-Teile prüfen edit_theme_options; die für Beiträge und Seiten machen ihre eigenen Prüfungen. Eine Rolle, die den Website-Editor öffnen kann, aber kein edit_others_posts hat, bekommt eine Oberfläche, die lädt und dann beim Speichern scheitert. Lesen Sie im Netzwerk-Tab die Antworten 401 und 403, bevor Sie blind Berechtigungen hinzufügen: Der REST-Fehlercode nennt das Recht, das gefehlt hat.

#Bedingte Berechtigungen mit user_has_cap

Manche Regeln passen in keine Rolle, weil sie vom Objekt abhängen, etwa ein Redakteur, der die Beiträge einer bestimmten Kategorie nicht anfassen darf. Dafür gibt es den Filter user_has_cap. WP_User::has_cap() wendet ihn nach map_meta_cap() an, mit vier Argumenten: $allcaps (was der Benutzer hat), $caps (die primitiven Berechtigungen, die die Prüfung verlangt), $args (die angefragte Berechtigung in $args[0], die Benutzer-ID in $args[1] und meist die Objekt-ID in $args[2]) und das Objekt WP_User.

add_filter( 'user_has_cap', function ( $allcaps, $caps, $args, $user ) {
    if ( 'edit_post' !== ( $args[0] ?? '' ) || empty( $args[2] ) ) {
        return $allcaps;
    }
    if ( has_term( 'legal', 'category', $args[2] ) && empty( $allcaps['manage_options'] ) ) {
        foreach ( $caps as $cap ) {
            $allcaps[ $cap ] = false;
        }
    }
    return $allcaps;
}, 10, 4 );

Drei Details im Quellcode entscheiden, ob das funktioniert. Der Filter sieht nur Prüfungen, die die Objekt-ID mitführen, current_user_can( 'edit_posts' ) läuft also durch, ohne dass die Regel greift. Er läuft bei jeder Berechtigungsprüfung, deshalb ist der frühe Ausstieg in der ersten Zeile nicht optional. Und in Multisite erreicht er Super-Admins nicht: has_cap() liefert ihnen true, bevor der Filter angewendet wird, wie Abschnitt 6 zeigt.

#4. WordPress-Rollen zurücksetzen

Die Version dieses Skripts, die im Umlauf ist, ist eine Rechteausweitung aus der Ferne:

// Nicht deployen.
function wppoland_reset_roles() {
    if ( ! isset( $_GET['reset_roles_secret_key'] ) ) return;

    require_once( ABSPATH . 'wp-admin/includes/schema.php' );
    populate_roles();
}
add_action( 'init', 'wppoland_reset_roles' );

isset() prüft, ob der Parameter vorhanden ist, nicht, ob er stimmt. Jeder nicht angemeldete Besucher, der ?reset_roles_secret_key an irgendeine URL der Website hängt, stellt die Standardberechtigungen wieder her. Dazu gehört, dass Redakteur oder Autor alles zurückbekommen, was Sie ihnen absichtlich entzogen haben.

#Rollen mit wp role reset zurücksetzen

wp role reset läuft auf derselben Core-Funktion und ist über den Shell-Zugang authentifiziert:

wp role reset --all
wp role reset editor

Der Befehl tut außerdem mehr als populate_roles() allein, und der Unterschied zählt beim Debuggen. populate_roles() ruft populate_roles_160() bis populate_roles_300() auf, und diese Funktionen rufen nur add_role() und add_cap() auf. Ein remove_cap() kommt darin nicht vor. Direkt aufgerufen stellt die Funktion entfernte Berechtigungen wieder her und lässt alle stehen, die ein Plugin hinzugefügt hat. WP-CLI vergleicht zusätzlich mit einer sauberen Installation, und deshalb liest sich die Ausgabe so:

Restored 1 capability to and removed 0 capabilities from 'administrator' role.

Eigene Rollen bleiben auf beiden Wegen unberührt. Wenn das Problem der Website eine schlecht gebaute eigene Rolle ist, behebt ein Reset es nicht.

#Rollen vor dem Zurücksetzen mit WP-CLI prüfen

Der Zustand, den Sie debuggen, ist eine Optionszeile:

wp option get wp_user_roles --format=json | jq '.editor.capabilities'
wp cap list editor
wp user list --field=user_login --role=administrator

Der letzte Befehl lohnt sich auf jeder Website, die Sie übernehmen. Eine Zahl von Administratoren, die Sie überrascht, ist der Befund.

#5. WordPress-Rollen absichern

#A. Administratorkonten in WordPress prüfen

Minimale Rechte sind keine neue Rolle, sondern eine kürzere Liste von Administratoren. Führen Sie wp user list --role=administrator auf den Websites aus, die Sie betreuen. Agenturkonten, ein Freelancer, der gegangen ist, und der Support-Zugang eines Plugins von vor zwei Jahren sind die üblichen Bewohner.

Zum klassischen Rat, den Benutzer nicht ‘admin’ zu nennen: Der Installer fragt seit WordPress 3.0 nach einem Benutzernamen, die verbleibende Lücke ist also die Enumeration. Der REST-Endpunkt für Benutzer liefert ohne Authentifizierung id, name, url, description, link, slug und avatar_urls. roles und capabilities gehören zum Kontext edit und werden nicht ausgegeben, aber slug ist der user_nicename, den WordPress aus dem Login ableitet, sofern niemand ihn ändert. Das ist eine Liste von Benutzernamen, kein Einbruch, und das Login-Formular per Rate Limiting zu drosseln ist die Maßnahme mit dem größeren Gewicht.

#B. Dateibearbeitung mit DISALLOW_FILE_EDIT deaktivieren

edit_themes dem Administrator zu entziehen ist eine Änderung an Berechtigungen, die jemand rückgängig machen kann. Eine Konstante in wp-config.php wird innerhalb von map_meta_cap() geprüft und lässt sich nicht durch eine Freigabe überstimmen:

define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_EDIT bildet edit_files, edit_plugins und edit_themes auf do_not_allow ab. DISALLOW_FILE_MODS geht weiter, sperrt die Installation und Aktualisierung von Plugins und Themes im Dashboard und deaktiviert als Nebeneffekt den Dateieditor. Auf einer Website, die aus Git deployt wird, ist DISALLOW_FILE_MODS die ehrliche Einstellung, weil Updates über die Deployment-Pipeline kommen.

DISALLOW_UNFILTERED_HTML funktioniert genauso und lohnt sich auf jeder Redaktionswebsite, auf der Redakteure keine Script-Tags einfügen müssen.

#C. Meta-Berechtigungen bei eigenen Inhaltstypen abbilden

register_post_type() setzt map_meta_cap standardmäßig auf null, nicht auf false. WP_Post_Type::set_props() macht aus diesem null ein true, wenn capabilities leer ist und capability_type post oder page lautet, aus Kompatibilität mit dem Verhalten von 3.0 (Core-Ticket #14122), und fällt in jedem anderen Fall auf false zurück. Ein eigener capability_type wie unten landet also bei false, wenn Sie nichts angeben. Geben Sie beide Argumente an:

register_post_type( 'book', [
    'capability_type' => [ 'book', 'books' ],
    'map_meta_cap'    => true,
] );

Die Array-Form ist keine Dekoration. Bei einer einfachen Zeichenkette hängt WordPress ein s an, um den Plural zu bilden, was für story zu storys führt. Die Referenz zu register_post_type() nennt das Array als den Weg, einen abweichenden Plural zu übergeben.

capability_type => 'book' erzeugt die Meta-Berechtigungen edit_book, read_book, delete_book und die primitiven edit_books, edit_others_books, delete_books, publish_books, read_private_books. Sechs weitere, read, delete_private_books, delete_published_books, delete_others_books, edit_private_books und edit_published_books, entstehen nur, wenn map_meta_cap true ist, weil nur map_meta_cap() sie verwendet. Das ist der Daseinszweck des Flags. Ohne es löst map_meta_cap() die Meta-Berechtigung edit_book zur Zeichenkette edit_book selbst auf, ohne zu prüfen, wer der Autor ist oder ob das Buch veröffentlicht ist. Wer diese Berechtigung hat, bearbeitet also die Bücher aller.

Ein weiterer Standardwert, auf den Sie achten sollten: create_posts wird auf edit_books abgebildet, wenn Sie es nicht festlegen. Wenn Sie eine Rolle wollen, die bestehende Bücher bearbeitet, aber nie eines anlegt, müssen Sie das im Array capabilities angeben.

#D. Wo current_user_can in Handlern und REST-Routen prüfen

Die Prüfung gehört zur Operation, nicht ins Menü. add_menu_page() nimmt eine Berechtigung entgegen und blendet damit einen Link aus, schützt aber nicht den Handler. Jeder admin-post-Handler, jeder AJAX-Callback und jede REST-Route braucht ein eigenes current_user_can(), und REST-Routen brauchen es im permission_callback, nicht im Handler. Seit WordPress 5.5 protokolliert register_rest_route() einen Hinweis über _doing_it_wrong(), wenn permission_callback fehlt, und für eine wirklich öffentliche Route ist __return_true der dokumentierte Wert.

Bei allem, was auf ein bestimmtes Objekt wirkt, übergeben Sie das Objekt: current_user_can( 'edit_post', $post_id ) läuft über map_meta_cap() und löst den Besitz auf. current_user_can( 'edit_posts' ) tut das nicht und beantwortet eine Frage zum Inhaltstyp statt zu diesem Beitrag.

#E. Zugriffsaudit und Trennung der Umgebungen

Ein Audit-Log, das Anmeldungen, Rollenänderungen und sensible Aktionen erfasst, zeigt Ihnen, wer wann was vergeben hat. Plugins wie WP Activity Log übernehmen diese Aufgabe, und Sie können es auch mit den Hooks von WordPress umsetzen.

Rollen in Entwicklung, Staging und Produktion werden getrennt geprüft. Eine Rolle, die in der Entwicklung mit zusätzlichen Rechten zum Debuggen sinnvoll ist, kann in der Produktion gefährlich sein.

#6. WordPress-Berechtigungen in Multisite und Plugins

#Netzwerkberechtigungen in Multisite

In WordPress-Multisite-Installationen wirken Berechtigungen auf zwei Ebenen: einzelne Website und Netzwerk. Laut der Dokumentation zu Rollen und Berechtigungen gibt es diese zehn nur für den Super-Admin: create_sites, delete_sites, manage_network, manage_sites, manage_network_users, manage_network_plugins, manage_network_themes, manage_network_options, upgrade_network und setup_network.

Der überraschende Teil geht in die andere Richtung. Der Administrator einer Unterseite verliert Berechtigungen, die er auf einer Einzelinstallation hat. Dieselbe Dokumentation führt update_core, update_plugins, update_themes, install_plugins, install_themes, delete_themes, delete_plugins, edit_plugins, edit_themes, edit_files, edit_users, add_users, create_users, delete_users und unfiltered_html als Berechtigungen auf, die in Multisite nur der Super-Admin hat. Sie werden nicht aus der Rollenzeile entfernt: map_meta_cap() macht sie mit der Bedingung is_multisite() && ! is_super_admin( $user_id ) zu do_not_allow, derselben, die Sie in Abschnitt 1 bei unfiltered_html gesehen haben. Deshalb ändert install_plugins in der Rolle Administrator einer Unterseite nichts.

WP_User::has_cap() bedient den Super-Admin, bevor es allcaps abfragt und bevor es den Filter user_has_cap anwendet: Enthält das Ergebnis von map_meta_cap() kein do_not_allow, liefert es true. Um einem Super-Admin etwas zu entziehen, müssen Sie map_meta_cap filtern und do_not_allow hinzufügen, nicht user_has_cap.

Um ein Recht auf einer anderen Website des Netzwerks zu prüfen, hat WordPress 6.7 current_user_can_for_site( $site_id, $capability ) eingeführt. Die Funktion ersetzt current_user_can_for_blog(), das jetzt in deprecated.php liegt. Das Plugin-Handbuch zeigt noch den alten Namen.

#Berechtigungen von WooCommerce, BuddyPress und bbPress

Plugins wie WooCommerce, BuddyPress und bbPress fügen dem System eigene Berechtigungen hinzu. Wenn Sie die Rollenarchitektur für eine Website mit diesen Plugins planen, müssen Sie sowohl die nativen Berechtigungen von WordPress als auch die von den Plugins hinzugefügten berücksichtigen.

#Members und User Role Editor zur Rollenverwaltung

Die Plugins Members und User Role Editor bieten grafische Oberflächen zur Verwaltung von Rollen und Berechtigungen. Für professionelle Entwicklung ist es trotzdem besser, Rollen über versionierten Code zu verwalten, damit Rechteänderungen dieselbe Prüfung durchlaufen wie jede andere Änderung.

#Zusammenfassung

Rollen sind Speicher. Berechtigungen sind die Entscheidung. Alles oben folgt aus dieser Trennung:

• Prüfen Sie Berechtigungen, nie Rollennamen: current_user_can('administrator') wird über eine Zusammenführung von Benutzer-Meta-Schlüsseln aufgelöst und liefert false für jede eigene Rolle, die Sie anlegen.
• Behandeln Sie add_role() und add_cap() als Migrationen gegen eine Datenbankzeile, mit Versionsprüfung, nicht als Konfiguration, die Sie bearbeiten und neu deployen.
• Lesen Sie die tatsächliche Reichweite einer Berechtigung, bevor Sie sie vergeben. edit_theme_options bedeutet in einem Block-Theme den Website-Editor, nicht nur den Menübildschirm.
• Stellen Sie mit wp role reset --all wieder her, nie mit einem nicht authentifizierten Abfrageparameter, und denken Sie daran, dass eigene Rollen dabei unberührt bleiben.
• Setzen Sie map_meta_cap => true bei jedem eigenen Inhaltstyp, der mehr als einen Autor hat.

Sehen Sie sich auch unsere Leistungen zur WordPress-Wartung an, damit Ihre Website sicher und optimiert bleibt.