Abonnenten die Bearbeitung ihrer Kommentare erlauben

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 🙂

 

 

Bilder in Mediathek auf aktuellen Nutzer beschränken

Letzte Woche hatte ich euch ja in einem Artikel beschrieben, wie ich in einem Custom Post Type “Portrait”, einem Nutzer ermöglicht habe, ein einzelnes Portrait bearbeiten zu können. Hierzu wurde auch eine eigene Rolle angelegt, mit der man die Berechtigungen besser steuern kann.

Nun gab es aber in diesem Projekt auch die Anforderung, dass ein Nutzer Bilder hochladen kann. Dabei gab es nun aber ein Problem. Wenn ich einem Nutzer erlaube, Bilder über die Mediathek hochzuladen, dann kann er auch die Bilder aller anderen Nutzer sehen. Das ist natürlich sehr unschön, gerade dann, wenn die Mediathek mit der Zeit sehr groß wird.

Nutzern den Upload von Bildern erlauben

Zuerst einmal musste ich natĂĽrlich der neuen Nutzerrolle generell das Recht einräumen, Bilder hochzuladen (ihr könnt aber natĂĽrlich auch eine bestehende Rolle wie “Abonnent” verändern):

Weiterlesen →

Eigene Rollen in der Autor-Box eines Custom Post Type anzeigen

Heute möchte ich euch einen kleinen Codeschnippsel an die Hand geben, der mir in der vergangenen Woche bei einem Problem mit den Berechtigungen geholfen hat. In einem Projekt sollte es Benutzern mit einer bestimmten Rolle ermöglicht werden, Seiten eines Custom Post Types zu bearbeiten. Die Einschränkung war hier allerdings, dass sie nur eigene Seiten des Custom Post Types bearbeiten dürfen.

Author-Box fĂĽr Custom Post Type aktivieren

Eigentlich sollte das ja ganz einfach sein – dachte ich zumindest. Zuerst einmal muss man natĂĽrlich die Autor-Box fĂĽr den Custom Post Type aktivieren. Nehmen wir einfach mal eine Portrait Seite als Beispiel. Dies geschieht bei der Registrierung des selbigen:

Weiterlesen →

Einrichtung von Elasticsearch in WordPress mit ElasticPress und Heroku

Am Donnerstag hatten wir unser erste WP Meetup Berlin in neuer Location. Dort habe ich einen kleinen Talk zum Thema Elasticsearch gehalten. Heute möchte ich euch zeigen, wie ihr Elasticsearch mit eurem Blog verwenden könnt. Es soll hierbei vor allem darum gehen, wie ihr schnell und kostenfrei eine Umgebung aufsetzen könnt, um mit Elasticsearch erste Experimente zu machen.

1. Installation eines Elasticsearch Servers

Wie ich in meinem Vortrag erläutert habe, handelt es sich bei Elasticsearch um einen “Suchserver”. Vergleichbar ist das mit einem MySQL Datenbankserver, den ihr ja ebenfalls fĂĽr eine WordPress Installation benötigt und der irgendwo installiert und erreichbar sein muss.

Elasticsearch ist in Java programmiert und damit wird es nicht ohne weiteres möglich sein, diesen auf eurem Server zu installieren (sofern ihr überhaupt einen eigenen Server habt). Obwohl ich Elasticsearch direkt auf meinem Server installieren könnte, habe ich mich dagegen entschieden. Ich möchte ungern Java installieren und mich dann durch die Installation kämpfen.

Weiterlesen →

Child Plugins: Zusammenfassung der Themenreihe

In sechs Beiträgen haben ich euch in den vergangenen Wochen die Möglichkeiten aufgezeigt, wie man ein Plugin anpassen kann. Heute möchte ich die Reihe mit einer kleinen Zusammenfassung beenden.

Empfohlene Vorgehensweise bei der Anpassung

Jeder der vorangegangenen Artikel hat versucht, eine einzelne Möglichkeit zu beschreiben. Wer sich nun fragt, wie man am besten vorgehen sollte, hier meine persönliche Vorgehensweise bei der Anpassung von Plugins.

Weiterlesen →