So langsam entwickelt sich das Thema Berechtigung ja zu einer kleinen Artikelreihe đ Heute habe ich erneut ein hoffentlich spannendes Kapitel dazu im Angebot. In dem Projekt, das schon bei den letzten beiden Artikeln als Grundlage diente, gab es nun die Anforderung, dass Nutzer mit der Rolle „Abonnent“ die Möglichkeit haben sollten, ihr Kommentare zu bearbeiten oder zu löschen.
Berechtigung zum Bearbeiten von Kommentaren vergeben
Ein kurzer Blick in den CODEX und die passende Rolle war gefunden. Das HinzufĂŒgen einer Berechtigung zu einem Nutzer kann man nun entweder mit einem fertigen Plugin wie Members tun, oder aber mit wenig Code:
$subscriber = get_role( 'subscriber' ); $subscriber->add_cap( 'edit_comment' );
Das sollte eigentlich schon alles sein. Leider funktioniert es aber nicht. Der Nutzer sieht nach dem Einloggen weder den MenĂŒpunkt zum Bearbeiten, noch kann er direkt auf die Kommentare zugreifen und diese bearbeiten. Es wĂ€re auch keine ganz optimale Lösung, da der Nutzer hierdurch die Kommentare aller Nutzer bearbeiten könnte.
Offenes Core Trac Ticket
Wie schon so oft zuvor, gab es auch zu diesem Problem ein Ticket im Bugtracker von WordPress.org das in diesemÂ ĂŒber 6 Jahre alt ist. Es gab hier aber lange keinen echten Fortschritt mehr. Um das Problem also zu lösen, habe ich mich erst einmal in den Core begeben um festzustellen, wo genau das Problem liegt. Es sind im Grunde zwei Probleme, die beide auf eine falsche ĂberprĂŒfung der Berechtigung beruhen.
Sowohl fĂŒr den Eintrag in die Navigation, als auch auf der Listenansicht der Kommentare wird nicht geprĂŒft, ob der Nutzer Kommentare moderieren oder bearbeiten kann. Es wird vielmehr geprĂŒft, ob er BeitrĂ€ge bearbeiten darf. Na, erinnert das jetzt den ein oder anderen an das Problem von letzter Woche?
Core Patch erstellt und Fehler vorĂŒbergehend behoben
Ich konnte den Fehler eigentlich recht schnell lösen und habe natĂŒrlich gleich einen Patch dafĂŒr eingereicht. Ich hoffe mal, dass er spĂ€testens mit WordPress 4.7 umgesetzt wird. Vielleicht ja schon mit 4.6.1, wobei das vielleicht zu optimistisch ist.
Bis er Patch online geht musste ich das Problem aber natĂŒrlich auch kurzfristig lösen. Und da ich ja niemals im Core etwas Ă€ndern wĂŒrde, bin ich zu einer anderen Lösung gekommen. Das Ganze habe ich euch natĂŒrlich wieder fertig verpackt in einem kleinem Plugin in einem GIST veröffentlicht.
Der Code ist etwas umfangreicher und daher möchte ich ihn hier jetzt nicht im Detail erklĂ€ren. Es ist ja ohnehin hoffentlich nur ein temporĂ€rer Fix, bis das im Core korrekt gelöst worden ist. Bis dahin könnt ihr das Plugin aber gerne mal testen und mir Feedback geben, wenn ihr ĂnderungswĂŒnsche habt.
Fazit
So langsam blicke ich wirklich durch, was das Berechtigungssystem von WordPress im Detail angeht. Manches davon ist im ersten Moment nicht ganz logisch. Und wenn einen ein komisches GefĂŒhl beschleicht, dass etwas falsch ist, dann lohnt sich ein Blick in den Bugtracker, denn oft ging es auch schon anderen so. Ich hoffe also, dass der Bug schon bald behoben wird. Und natĂŒrlich, dass ich mit diesem kleinen Hilfsplugin auch wieder dem ein oder anderen von euch weiterhelfen konnte đ
Hi Bernhard,
haha, ich bin gestern auch ĂŒber Deinen Patch gestolpert, als ich im API Forum mit dieser Anfrage gearbeitet hatte: https://github.com/WP-API/WP-API/issues/2663
Da Du Dich ja jetzt schon ziemlich in die Kommentar-Berechtigungen eingefressen hast: WeiĂt Du, warum die API derzeit nicht nur auf edit_comment aber auch auf manage_comments prĂŒft, bevor ein User ĂŒber die API einen Kommentar editieren kann? WĂŒrde mir grad gut weiterhelfen.
Vielen Dank đ
Hallo David,
ich habe mich bisher leider nicht mit Berechtigungen in Verbindung mit der API beschĂ€ftigt. PrĂŒft denn der Core die Berechtigung oder die API? Falls es der Core ist, dann sollte sich das Problem ja fĂŒr beide mit dem Patch lösen lassen. Falls es die API prĂŒft, dann muss wohl hier ebenfalls ein Patch geschrieben werden. Hast du vielleicht mal einen Direktlink zu der Stelle, an der es in der API geprĂŒft wird?
Hi Bernhard,
ich dachte nur, vielleicht hÀttest Du gerade im Kopf im Core benötigt man eben beide Berechtigungen wg. X oder Y.
Der Direktlink wÀre: https://github.com/WP-API/WP-API/blob/develop/lib/endpoints/class-wp-rest-comments-controller.php#L1167
Die API muss letztlich die Berechtigungen aus dem Core reproduzieren. Ich hatte gestern in den Core gesehen und war eben unsicher, ob das derzeit der Fall ist.
Also der Code aus der API macht echt keinen Sinn. Man könnte das natĂŒrlich auch wieder mit einem Filter gegen „user_has_cap“ bzw. „map_meta_cap“ ĂŒberschreiben, aber es mach wohl mehr Sinn, einen PR zu machen, der die „moderate_comments“ ĂberprĂŒfung entfernt.
Ja, so sehe ich das eigentlich auch. Werde dann heute erstmal einen Issue eröffnen und dann mal sehen. Danke đ