 Ja, ich werde auch direkt mal kurz diesen komischen Begriff vielleicht aufklären. Also erst einmal, ich habe, das ist mein erster Talk, den ich in Deutsch gebe. Und diesen Talk habe ich auch schon wie heute Morgen auch der Thorsten bisher nur in Englisch gegeben. Deswegen bitte ich zu entschuldigen, wenn zu viele Anglesismen benutzt werden. Ich habe aber auch extra die Slides, ja, die Folien, habe ich alle übersetzt. Ja klar, aber trotzdem, ich versuche jetzt mich strick daran zu halten. Und es geht darum, wie man Berechtigungen, was im WordPress Core auch eben dann Capabilities heißt in Englisch, wie man die in Plugins gewinnbringend einsetzt und dann auch, wie man als darauf basierend, als Entwickler, der an einem Projekt arbeitet, solche Plugins für die eigenen Bedürfnisse anpassen zu können. Ich werde auch jetzt genauer dann darauf eingehen, was es ist. Das Ganze ist, ja, es ist jetzt der letzte Vortrag hier heute vor den Aktivitäten. Es ist nochmal so ein bisschen komplexer teilweise, wenn das irgendwo vielleicht zu schnell ist, oder so, dann ich bin die ganze Zeit noch hier und würde mich auch gerne noch weiter darüber unterhalten, wenn jemand noch Fragen hat später. Und die Slides wird es auch, die Folien wird es auch online geben. Erst einmal, was sind die, was sind Berechtigungen? Berechtigungen beschreiben in WordPress im Prinzip die Aktion, die ein bestimmter Nutzer durchführen darf oder eben nicht. Es gibt dann, es gibt für jede Aktion, praktisch jede Aktion, die man durchführen kann in WordPress, wird das geprüft. Zum Beispiel, es wird geprüft, sobald man den Update-Button bei einem Beitrag klickt, wird geprüft, darf der Nutzer diesen Beitrag bearbeiten oder nicht. Wenn nicht, dann kommt eine Fehlermeldung, du darfst das nicht oder so. Oder cheating, ja. Und ja, die Rollen, die Benutzerrollen, das ist eher der bekanntere Teil davon, weil die eben auch im Admin-Bereich öffentlich sichtbar sind für jeden Benutzer. Das sind eben die bekannten Rollen, die wir zum Beispiel Administrator, Redakteur, Autor, Mitarbeiter und Abonnent. Das sind eben die Rollen, die sollten ja die meisten hier, mit den meisten sind wir wahrscheinlich vertraut. Und Rollen sind im Prinzip eine Bündelung von mehreren Berechtigungen. Und sobald ein Nutzer dann eine dieser Rollen hat, hat er auch gleichzeitig alle diese Berechtigungen. Ich habe jetzt hier mal eine kleine Liste von typischen WordPress-Berechtigungen, die es da gibt. Die sind natürlich alle in Englisch. Also es gibt zum Beispiel Edit-Posts, um generell Beiträge zu bearbeiten, Upload Files, um Mediendateien hochzuladen, Manage Categories, um Kategorien zu verwalten, Options, etc. Die meisten sind relativ selbsterklärend. Es ist aber auch möglich, eben eigene Berechtigungen einzufügen. Wir nehmen jetzt mal an, wir würden vielleicht ein Plug-in schreiben, was Tutorials einem ermöglicht, zu veröffentlichen mit bestimmten Verhalten. Und dazu könnten wir zum Beispiel eigene Berechtigungen einführen. Solche eigenen Berechtigungen sollte man als Plug-in-Autor immer mit einem Prefix ausstatten, damit die möglichst einzigartig sind und nicht mit irgendwelchen anderen Plug-ins später Konflikte vorwerfen können, aufwerfen. Deswegen könnte man dann zum Beispiel sagen, wir brauchen eine Read CT Tutorials Capability. Sagen wir mal unser Plug-in heißt Capability Tutorials. Deswegen nehme ich jetzt einfach mal CT als Prefix. Wir könnten Read CT Tutorials dann haben, um zu prüfen, darf ein Benutzer Tutorials ansehen, oder Edit CT Tutorials, ob man dann auf der Benutzeränderung machen darf, oder auch Manage CT Options, ob der Benutzer die bestimmten Einstellungen, die dann diese Tutorials betreffen, machen darf oder nicht. Also warum, was bringt das überhaupt denn dann auf solche Berechtigungen zu achten und die auch eben in seinem Plug-in Code zu verwenden? Zum einen ist es eben Verbesserung der Security, also man sollte eben darauf dafür sorgen, dass niemand auf etwas Zugriff hat, worauf er keinen Zugriff haben soll. Andererseits aber auch eben gleichzeitig bringt es Usability, weil eben viele Funktionen, die wir standardmäßig zum Beispiel im Atmen haben, also viele manche Leute brauchen manche dieser Funktionen nicht. Ich denke jetzt gerade vor allen Dingen sowas wie dieser Werkzeugebereich, der wird ja sehr selten eingesetzt von normalen Nutzern, ist aber trotzdem immer da und das wäre zum Beispiel so ein Beispiel, wo man eigentlich mit genaueren Berechtigungen arbeiten könnte. Und auch ein großer Punkt, wo ich mich hier darauf viel beziehen werde, ist Customizability. Also man kann dadurch, dass man in seinen eigenen Plug-ins sehr Feintuning vorgeht, um die eigenen Berechtigungen einzubringen, ermöglicht man anderen Entwicklern diese auch anzupassen und eben zu sagen, um zum Beispiel dann noch genauer vorzugehen, wenn jemand bestimmte Dinge noch für ein eigenes Customprojekt anpassen will. Ein Beispiel ist hier zum Beispiel, ist hier auch in WordPress selbst, ist es im Moment etwa nicht wirklich möglich, jemanden zu erlauben, Widgets und Menüs zu bearbeiten, aber nicht das Team wechseln zu dürfen. Das ist zum Beispiel etwas, was, denke ich, viele schon mal gebraucht haben, aber es geht nicht. Und weil an dieser Stelle WordPress Core selbst nicht granular genug ist mit den Capabilities, mit den Berechtigungen. Bevor wir jetzt da genauer darauf eingehen, gucken wir jetzt einmal intern an, wie das alles funktioniert. Das ist jetzt vielleicht etwas kompliziert erstmal. Also es ist so, dass die verfügbaren Rollen, die es auf einer Website gibt, die intern in der Options-Datenbank-Tabelle gespeichert und die Berechtigungen, die dann zu jeder Rolle gehören, sind ebenfalls Teil dieses Arrays. Das sieht dann zum Beispiel so aus, ich habe hier jetzt mal dieses Array. Da sieht man hier oben die Administrator, das ist jetzt erstmal die Administrator-Rolle und dann alle Capabilities, die dazu gehören. Die Editor, also es ist ja dann Redakteur, Autor, Contributor, Mitarbeiter und Abonnent. Der Abonnent hat halt nur die Read Capability, was in Prinzip so viel heißt wie gar nichts. Also der darf nur sein eigenes Profil bearbeiten und eben die Inhalte lesen. Bei genauer Betrachtung von dieser Liste hier fällt ja auf, dass also normalerweise, wir kennen das ja alle so, dass diese Rollen alle hierarchisch aufgebaut sind. Also der Administrator darf mehr als der Redakteur, der Redakteur darf mehr als der Autor und so weiter. Das ist aber nur im Prinzip, das ist aber nur einfach von WordPress so aufgesetzt. Man könnte auch anders laufen, weil eben die Capabilities einfach nur Teil dieses Array sind und sie werden nicht irgendwie aufbauend gehandhabt. Es ist nämlich so, dass ja zum Beispiel der, wenn man jetzt hier guckt, die, sagen wir hier, die Edit Post Berechtigung, die hat der Contributor, aber der Autor hat die einfach auch und nur so ist, erzeugt man den Eindruck, diese Rollen werden hierarchisch strukturiert. Man könnte jetzt aber auch hier die Edit Post Capability theoretisch rausnehmen, dann würde es so sein, dass plötzlich der Contributor doch an einer Stelle mehr machen darf als der Autor. Also es muss nicht hierarchisch sein, es ist nur standardmäßig eben so gedacht. Rollen, die für Pro Benutzer werden dann in der Usermeter-Datenbank-Tabelle gespeichert, für jeden Benutzer. Das sieht dann im Standardmäßig zum Beispiel so aus, das ist nur ein ganz simples Area, da steht jetzt einfach nur, wenn Benutzer ein Redakteur ist, dann steht da einfach nur diese Editor-Rolle drin. Es könnten theoretisch aber auch Berechtigungen in diesem Area mit drin sein, das kann man machen, wird in der Regel nicht gemacht, weil es eben schnell chaotisch werden würde. Also das heißt, theoretisch bräuchte man noch nicht mal Rollen. Man könnte auch einfach alle Berechtigungen direkt für jeden Benutzer in dieses Area schreiben, aber dann wäre es eben deutlich komplizierter, da irgendwie noch nicht den Überblick zu verlieren, also da wäre es deutlich einfacher, den Überblick zu verlieren. Und auch technisch gesehen, da das hier ein Area ist, sollte es eben wichtig zu wissen, ein Benutzer kann theoretisch mehrere Rollen haben. WordPress bietet keine Oberfläche dafür anders zu managen, aber es gibt Plugins, die das tun und das ist auch kein großer Heckaufwand, der da nötig ist, weil es eben von Haus aus eigentlich unterstützt ist anhand dessen, dass es ein Area ist, wo mehrere Rollen drin enthalten sehen können. So, jetzt gucken wir uns das mal an, wie das dann für Plugin-Entwickler aussieht. Man sollte ganz wichtig, man sollte immer auf Berechtigungen überprüfen. Die Rollen sind halt nur intern, das wird zuständig zu sagen, diese Benutzer haben diese Berechtigungen, man soll aber nicht prüfen, welche Rolle ein Nutzer hat. Es gibt auch in WordPress gar keine intuitiv benutzbare Funktion dafür und das ist auch eben so gewollt, weil man soll nicht gucken, wenn das ein Administrator ist, kann er das. Nein, man soll gucken, wenn diese Person Beiträge bearbeiten kann, immer mit Berechtigungen arbeiten, nicht mit Rollen. Auch weiß dahin, wenn man als Plugin-Entwickler sollte Berechtigungen niemals in der Datenbank angepasst werden. Man sollte auf gar keinen Fall Berechtigungen entfernen, weil das alle möglichen unvorhergesehenen Dinge vorher nach sich ziehen kann. Man sollte aber auch keine eigenen Berechtigungen in der Datenbank einfach irgendeine existierenden Rolle hinzufügen. Es sei denn, wenn man in der Datenbank integriert eine komplett neue Rolle, wenn jetzt zum Beispiel gehen wir wieder zurück zu dem Tutorial Plugin, wenn wir da dann eine Rolle einführen würden für ein Tutorial Manager oder so was, den würde man ja in der Datenbank speichern, das ist auch im Prinzip die einzige Möglichkeit, die einzige Standardmessigkeit mit Rollen in WordPress umzugehen und da würde man dann diese Capabilities dieser Rolle eben zuschreiben. Wie man dann bei existierenden Rollen eigene Capabilities, eigene Berechtigungen gewährt, dazu kommen wir dann noch gleich. Ganz wichtig, wie ich auch schon kurz erwähnt habe, eigene Berechtigungen sollte man überall verwenden in seinem Plugin Code, anstatt sich einfach auf die bestehenden Core Berechtigungen zu verlassen. Wenn man zum Beispiel ein Einstellungsbildschirm hat, dann sollte man dazu eine eigene Capability, so was wie Managed CT Options in dem Beispielfall hier zum Beispiel verwenden. Man sollte nicht einfach sagen, ich nehme einfach das Managed Options und würde nämlich dann heißen, dass es niemals möglich wäre, jemanden zu sagen, jemand darf diesem Bild schon bearbeiten, aber die anderen von WordPress Core nicht oder so, man kann da dann gar keine Abstufungen mehr machen, wenn man einfach die Capability von WordPress Core benutzt. Wie prüft man auf Berechtigungen? Die wirklich essentielle Funktion dazu ist currentUserCann und eine Capability ist, wie auch eben schon gezeigt, es ist im Prinzip wirklich nur ein String. Also einfach nur ein Text wie zum Beispiel diese EditPost oder so, das kann man dann diese Funktion übergeben und im Endeffekt bekommt man dann true oder false, ganz simpel zurück, die da einem dann sagt, ja, das Lender benutzt ja kann das machen oder nicht. Man achte darauf, hier steht currentUserCann und das ist auch die Funktion, die man meistens benutzt, weil es geht ja wirklich in den meisten Fällen darum zu gucken, ob der aktuelle Nutzer etwas kann. Es gibt aber auch noch zusätzlich, diese Funktion, die dann das Gleiche für einen beliebigen Nutzer macht, der nicht unbedingt der aktuelle Nutzer ist. Berechtigungen, wie die dann da gehandelt werden, dazu kommen wir dann im Gleich, die werden entweder von WordPress gehandhabt oder eben beeignen, muss man sich selber um sie kümmern. Man kann aber natürlich auch die von WordPress anpassen. Jetzt wird es langsam tricky. Also es gibt zwei Arten von Berechtigungen. Es gibt primitive Berechtigungen und meta Berechtigungen. Die primitiven Berechtigungen, das sind im Prinzip die Oberkategorien, das sind allgemeine Berechtigungen, die bestehen meistens hier aus einem Verb und einem Plural String und wie zum Beispiel Edit Posts oder Activate Plugins, das sind die Berechtigungen, die man auch typischerweise meistens kennt oder benutzt. Man kann die eben entweder in der Datenbank gespeichert, so wie ich eben gezeigt habe oder man kann sie dynamisch durch einen Filter gewähren. Da würde ich gleich noch darauf ein. Jetzt aber erstmal zu den Metaberechtigungen. Das ist der Teil, den vielen Leuten nicht noch nicht so bekannt ist. Das sind Berechtigungen, die sich immer auf irgendeine spezifische Untersache beziehen. Also anstatt Edit Posts der generellen Berechtigung würde man hier, hat man hier eine Metaberechtigung, die heißt Edit Postsingular und dann übergibt man an diese CurrentUserKennfunktion auch noch die PostID. Das heißt also, in dem ersten Beispiel hier, ich prüfe, kann der aktuelle Nutzer den Post mit dieser PostID, die man dann da übergibt, bearbeiten. Oder kann der Nutzer genau dieses Plug-in mit diesem Plug-in Slug aktivieren. Im Prinzip werden dann diese Metaberechtigungen, die sind nirgendwo direkt gespeichert, die werden auch nicht, die werden mit das Filter-Ausnahms-Map-Metakap, die werden im Prinzip auf primitive Berechtigungen gemapped. Also man hat gespeichert immer nur die primitiven Berechtigungen, die sind in der Datenbank oder eben dynamisch und aber man sollte, man hat eben oft den Fall, dass man auch auf Metaberechtigungen prüft. Es ist eben so, wenn es darum geht, einen Beitrag zu bearbeiten, sollte man darauf prüfen, mit einer Singular-Capability, darauf prüfen, genau diesen Beitrag zu bearbeiten. Und nicht generell prüfen, kann der überhaupt generell irgendwie Beitrag bearbeiten. Dann gibt es noch zwei ganz spezielle Berechtigungen, eben, und die heißen exist und do not allow. Exist ist eine Berechtigung, die automatisch, die ist eben so gehandhabt, sobald man das prüft, dann gibt es immer true zurück. Das macht natürlich erst mal keinen Sinn. Das ist aber dafür da, wenn man zum Beispiel eine solche Metaberechtigung mapen will, so, dass das jeder machen kann. In vielen Fällen macht das keinen Sinn. Man will ja nicht, dass jeder alle Beiträge bearbeiten kann. Aber es ist eben möglich, so was zu machen. Und do not allow ist genau das Gegenteil. Das heißt, sobald man eine, wenn man zum Beispiel prüft, können die User kennen, do not allow, wird immer false zurückgeben. Und auch das ist dafür da, dass man zum Beispiel eine Metaberechtigung auflösen kann in irgendwas wie do not allow und das weiß WordPress direkt, okay, das kann keiner machen. Noch mal kurz zusammenfassend hier die Namenskonvention. Das habe ich hier kurz schon erwähnt. Man sollte immer das Verb und ein Plural String für die primitiven Berechtigungen benutzen, die allgemeinen Berechtigungen und dann oft einfach genau den gleichen, genau die gleiche, den gleichen Namen, aber mit einem Singular, mit der Singularform des Nomans am Ende für Metaberechtigungen. Also edit posts, edit posts, activate plug-in, Singular, etc. So intern sieht das dann wieder so, wie das dann abläuft, wenn man einmal eine Capability überprüft, eine Berechtigung überprüft. Man ruft erst currentUserCane auf. Danach wird eben, wird diese Funktion MapMetalCap aufgerufen und wenn da irgendwo eine Clause eine irgendwo eine IfClause oder drin ist eine spezielle Capability, dann weiß man, okay, das ist jetzt eine Metacapability oder Metaberechtigungen und die wird dann mithilfe dieser Funktion oder auch dem Filter, der dann eben Plug-ins erlaubt, das anzupassen, wird dann auf mehrere, ein oder mehrere primitive Berechtigungen aufgelöst oder gemapped oder abgebildet. Im Endeffekt wird danach geprüft, ob der Nutzer diese bzw. danach wird erst mal geguckt, dann werden die primitive Berechtigung aus der Datenbank geholt und noch durch diesen Filter hergelaufen, sodass man dann als Plug-inentwickler auch dynamisch das, was in der Datenbank ist, anpassen kann. Man kann zum Beispiel einfach dynamisch sagen, ich nehme jetzt die Capability weg oder ich gebe noch die andere dazu. In der Regel gibt man meistens zusätzliche hinzu. Zum Beispiel würde man, wenn man jetzt ein Plug-in hinzufügt mit seinen eigenen primitiven Capabilities, wie gesagt, nicht in die Datenbank, da sollte man an diesem Filter verwenden und zumindest in der Standardausführung und sich dann auf irgendwelche existierenden Berechtigungen in der Datenbank berufen. Man könnte zum Beispiel sagen, der Benutzer soll einfach erst mal standardmäßig mein Custom Managed CT Options kriegen, wenn er schon Managed Options hat. Das wäre dann ein guter Fallback. Es ändert erst mal nichts an der Plug-in Funktionalität, hätte man einfach direkt Managed Options benutzt. Es erlaubt aber eben später anderen Leuten das anzupassen und das ist wirklich der große Vorteil daran. Sobald man dann am Ende eben alle primitiven Berechtigungen des Nutzers, die der Nutzer hat, eben wirklich durch den Filter und die Datenbank hat, wird geprüft, dass alle Capabilities, die dann durch Metacap zurückgegeben wurden, vorhanden sind. Sobald der Benutzer eine dieser Berechtigungen nicht hat, schlägt der ganze Check fehl und der Benutzer darf das nicht machen, diese Aufgabe. Ansonsten ist die Prüfung erfolgreich. Darf man natürlich nicht do not allow enthalten sein. Sobald irgendwo do not allow enthalten ist, ist direkt fehlgeschlagen. Wie macht man das jetzt konkret in einem Plug-in? Dieses Plug-in, wovon ich jetzt gerade mal geredet hab, das hab ich auch mal implementiert. Capability Tutorials, das flügt eben so einen sehr simplen Tutorial-Post-Type hinzu und einen kleinen Einstellungsbildschirm mit ein paar Optionen. Das ist jetzt nicht sonderlich Benutzerfreundliche. Man kann hier eben ein paar Eigenschaften des Beitrags des Post-Types anpassen. Es gibt hier eben den Felder für ReWrite-Slug, die Post-Type Properties, ob das Archive hat, das sind eben die, wenn ihr Register-Post-Type kennt, dann sind das im Prinzip Parameter für diese Funktion. Ja, nochmal zur Erinnerung. Current-User-Kenn wird dann benutzt, um Capabilities zu überprüfen. Und das erste, was man in so einem Plug-in oft macht, ist die Einstellungsseite hinzufügen. Hier ist, das ist so ein spezieller Fall, wo eben sogar eine Capability erforderlich ist, die dann Wordpress-Intern verwendet, die dann im Wordpress-Intern aufruft mit Hilfe Current-User-Kenn. Also der vierte Parameter von dieser Funktion, da gebe ich über, gebe ich in dem Fall Manage-CT-Options. Das heißt, diese Sub-Menu-Page kann nur jemand aufrufen, der die Manage-CT-Options-Capability hat. Bei der Registrierung eines Post-Types sollten ebenfalls eigene Berechtigungen angegeben werden. Das würde jetzt ein bisschen hier den Rahmen sprengen, genau darauf einzugehen. Aber dieses Plug-in macht das auch. Also wer da Interesse hat, kann sich das später auch noch mal gerne angucken. Oder auch Fragen dazu stellen. Ja, ich gucke, wir gucken das jetzt mal an, wenn ihr die Funktion as Settings fehlt, wenn ihr euch bekannt ist, die fügt eben die Felder in einem Einstellungsbildschirm hinzu. Das sieht aus, wenn man es ganz simpel macht. Man kann aber auch Berechtigungen zufügen. Also Berechtigungsüberprüfungen. Man könnte jetzt für jedes einzelne Einstellung auch eben sagen, ich prüfe jetzt, ob der Nutzer diese spezielle Einstellung bearbeiten darf. Dazu würde man jetzt hier eben eine Meta-Berechtigung benutzen. Also wieder mit einem Singular-Nomen da, Manage-CT-Option. Und als extra Parameter übergibt man dann einfach den Schlag, den Bezeichner der jeweiligen Option, also CT Real Rights Work oder CT Reports oder CT Has Archive. Es ist hier wichtig, darauf zu achten, dass man das, wenn man das an dieser Stelle macht, noch auch an der Stelle machen muss, wo diese Settings dann validiert werden. Das gibt es dann aber auch, das ist auch im Plug-In Code ersichtlich. Solche Checks wie hier sollte man nach Bedarf natürlich verwenden. Der untere Fall muss jetzt nicht unbedingt so gemacht werden. Wenn man denkt, es macht wirklich überhaupt keinen Sinn, diese einzelnen Felder gesondert verfügbar zu machen, dann reicht es auch so wie oben zu machen. Man sollte sich aber im Klaren darüber sein, dass vielleicht andere Leute viele genauere Berechtigungen benötigen, als man selbst erst mal denkt. Sobald wir jetzt hier diese Berechtigungen erstmal hierfür das für die Menuseite, sobald wir da unsere eigene Berechtigungen vergeben haben und hier dann auch unsere eigenen Berechtigungen für die einzelnen Optionen vergeben haben, das sieht dann so aus. Das ist natürlich, weil wir die Berechtigungen noch niemandem gewährt haben. Wir haben jetzt die erstmal abgeprüft, aber es gibt noch, es ist noch keine Logik da, die die dann wirklich einen Benutzer gewährt. Erstmal jetzt die primitive Berechtigung, die sich dann, die hieß ja bei uns, Managed CT Options, plural wieder. Dazu kann man, die kann man jetzt eben gewähren, indem wir den User Hascap Filter benutzen. Dabei ist der erste Parameter, der Area von allen Berechtigungen, die der Nutzer hat. Und der zweite Parameter ist dann das Area von allen Berechtigungen, die im Moment in der aktuellen Check überprüft werden. Es ist normalerweise, theoretisch bräuchte man eigentlich nur den ersten Parameter, weil man einfach prüft, hat der Nutzer die Capability, in dem Fall gibt ihm auch diese Capability. Aber dieser Filter wird extrem oft getriggert sobald, das heißt also für jeden Capability Check von irgendwelchen Plugins, da passieren ja pro Request im Atmenbereich, vor allen Dingen passieren da wahrscheinlich 100, mindestens 100 Aufrufe, vielleicht sogar. Und deswegen sollte man sobald die Logik, die man in diesem Filter packt, nicht mehr trivial oder sehr irrelevant für die Performance ist, sollte man dann auch sagen, man passt die Capabilities dann nur an, wenn die auch tatsächlich gerade abgefragt werden. Ansonsten ist das einfach redundant sowieso eigentlich. Also ich gehe jetzt mal hier, in dem Fall sagen wir jetzt, was ich eben schon ins Beispiel genannt hab, geben einem Nutzer die unsere Managed CT Options Capability so fern der Nutzer auch Managed Options hat. In dem Fall ist es wirklich ein sehr simpler Check, deswegen überprüfe ich jetzt nicht ob diese Managed CT Options gerade überhaupt geprüft wird. Man könnte aber eben das Ganze auch noch in so einen Weitere If Gloss Wrappen und dann den zweiten Parameter, der jetzt oben gar nicht übergeben ist, weil man will nicht brauchen. Darauf könnte man dann eingehen. So, jetzt haben wir diese primitive Berechtigung gewährt. Das heißt, wir können es auf die Seite zugreifen. Die sieht es aber so aus. Da sind unsere Einstellungen nicht da und das ist weil wir Meterberechtigungen eingefügt haben, die da überprüft werden für die einzelnen Settings Felder. Die hier müssen wir natürlich und das sind Meterberechtigungen. Das heißt, die müssen in irgendwelche primitive Berechtigungen aufgelöst werden. Dazu wird dann der Filter Metacap verwendet. Der standardmäßig lässt er einfach die überprüfte Berechtigungen, lässt er einfach durchlaufen. So fern da nicht irgendeine spezielle Behandlung enthalten ist. Also in unserem Fall haben wir verschiedene Managed CT Option Aufrufe, Singular, mit der speziellen Option. Und der ganz simple Fall, in dem wir jetzt erstmal einen Plug-in erstmal verwenden, sollte in den meisten Fällen ist einfach, ich mape das auf die generelle primitive Berechtigung. Also sobald jemand für eine spezielle Option Managed CT Option überprüft, sagt einfach der braucht nur Managed CT Options haben, dann kann er die Option bearbeiten. Das sind jetzt wirklich die Basis Implementierung, die man dann in einem Plug-in anwenden sollte erstmal. Außer man hat da direkt konkrete Pläne mit. So, sobald wir diesen Code hier eingebaut haben, sind dann die Optionen auch sichtbar. Ja, was soll das alles jetzt? Bisher haben wir jetzt überall diese Capability Checks eingebaut und sie gewährt. Wir hätten aber auch einfach Managed Options benutzen können und das war's. Also von das, was es schon in Wordpress ist, aber eben wie gesagt durch die Verwendung von eigenen Berechtigungen und auch die vor allen Dingen auch die Berechtigung von, die Nutzung von diesen Meta Berechtigungen für jedes einzelne Feld zum Beispiel erlaubt es eben wirklich extrem granulares Handling von diesen Berechtigungen. Für andere Leute, selbst wenn das Plug in an sich das gar nicht braucht erstmal, dann könnte es könnte jemand in einem Kundenprojekt zum Beispiel da bestimmte Dinge verhalten wollen, dass man sagt der Kunde soll nicht mehr das und das Feld bearbeiten können, das soll nur noch ich machen können oder sowas. Und darauf gehe ich jetzt auch noch kurz ein, wie man das dann als ein anderer Entwickler manipulieren könnte. Also ein Beispiel hier wäre dass man den Standardmäßig haben wir jetzt eben gesagt Managed City Options das bekommt jetzt jeder der Managed Options hat durch den User Hascap Filter dynamisch gewährt dann würden eben auch noch zum Beispiel andere Capabilities die wir jetzt hier für den Tutorial Post Type hinzufügen würden dann auch noch davon abgedeckt sein. Man könnte aber zum Beispiel dann sagen, ich möchte das nicht ich möchte meine eigene Rolle haben die sich nur darum dreht, diese Tutorials zu verwalten. Dann diese Rolle hinzufügen alle die Capabilities direkt in diese Rolle dieser Rolle zu gewähren und dann unseren typischen alten Plugin Filter zu entfernen das heißt dann danach kann niemand mehr irgendwas von diesen Sachen machen die für unser Plugins zuständig sind das ist dann alles nur noch für diesen Tutorial Manager möglich. Eine andere Möglichkeit die sich jetzt speziell die Meta Capabilities bezieht während zum Beispiel man würde, was ich eben schon angesprochen hat, man könnte sagen ich möchte, dass diese CT Rewrites lag, das war ja eine von den Optionen, da könnte man dann sagen ich möchte nicht ich möchte, dass das nur noch von einem Netzwerk ein Administrator beinahe in Multisites zum Beispiel bearbeitet werden kann dazu würde man sich dann in Map Meta Cap rein hucken und prüfen wird, sobald gerade die Managed CT Option Capability abgefragt wird, da weiß man, okay da muss ich jetzt gucken und da kann man dann mithilfe des Arcs Arrays, was da als letzten Parameter übergeben wird, das sind im Prinzip alle Argumente die zusätzlich noch an Current User kennen bei dem Überprüfung übergeben worden sind da kann man eben gucken, ist das die Option die spezielle Option CT Rewrites lag und falls ja, und sofern es dann auch noch in der Multisite ist muss der Nutzer auch die Managed Network Options Capability haben da man dann eben beide Berechtigungen haben muss und Managed Network Options nur für den Netzwerk Administrator verfügbar ist, kann dann ab diesem Zeitpunkt plötzlich die Option eben nur noch der Netzwerk Administrator bearbeiten die anderen sind aber noch immer weiterhin verfügbar also es würde dann so aussehen das obere Feld, was da eben noch da war ist dann einfach weg und so das war jetzt eben ein Beispiel, wie man wirklich extremes Feintuning da erlaubt und das ist eben vielleicht in diesem Fall hier ein bisschen Overkill aber gerade bei Komplexer und Plug Ins tendieren viele da eben dazu deutlich zu wenige Berechtigungen zu verwenden und ja, und das macht dann eben meine Customisierung, Anpassung sehr schwer. Ich gehe jetzt noch ganz kurz gibt es noch ganz kurz einen kleinen Ausblick auf Multisite, wie das da funktioniert da gibt es eben auch in Multisite gibt es zusätzlich noch den Netzwerk Administrator der manchmal auch als Superadmin bezeichnet wird das scheint erstmal eine zusätzliche Rolle zu sein technisch gesehen ist es aber einfach eigentlich nur eine Option die einfach sagt, alle diese User IDs sind Superadmin das funktioniert komplett anders als andere als die tatsächlichen Rollen die man dann in einer normalen Weblist-Zeit hat obwohl man auch theoretisch diese Option einfach abrufen könnte um zu prüfen ob ein Nutzer etwas machen kann sollte man direkt, sollte man immer auf die Berechtigung prüfen das ist genau das Gleiche, wie das man auch in Single-Zeiten nicht überprüfen soll ist das ein Administrator, man soll überprüfen ist das, kann dieser Nutzer ein Post bearbeiten oder sowas es gibt eben die Funktionen, ist Superadmin unbedingt leider sehr oft verwendet, findet man heute noch sehr oft im WordPress Core daran wird aber gearbeitet, das zu entfernen und bitte verwendet das nicht es gibt Multi-Site Berechtigungen hier im Core schon und die wer, man sollte dann zum Beispiel, wenn man wirklich Dinge überprüft die hier auf die viel für relevant sind dann sollte man entweder mindestens diese Berechtigung benutzen, noch besser aber wenn ihr dann einen eigenen Bereich im Multi-Site irgendwo einfügt wäre es dann natürlich wieder noch besser eure eigenen Berechtigungen zu verwenden es ist halt so, dass der Netzwerk-Administrator, da es eben nur diese Flagg ist, der funktioniert so dass er sowieso erstmal, der hat alle Berechtigungen die man überhaupt abfragen kann also sobald WordPress weiß der aktuelle User ist Netzwerk-Administrator gibt eigentlich jeder capability capability check true zurück es sei denn, man benutzt do not allow das ist die einzige Möglichkeit sogar beim Netzwerk-Administrator etwas zu verwehren ein anderer typischer use case ist, dass man wenn etwas in Multi-Sites wenn man Multi-Site aktiviert hat dass da etwas anders, dass der Zugriff anders funktionieren soll als in Single-Sites zum Beispiel kann ja im WordPress, kann der normalen WordPress-Site der Admin Updates machen aber bei einer Multi-Site kann plötzlich nur noch der Netzwerk-Admin Updates machen und also das, sobald man Multi-Site anschaltet, wird das also verändert und sowas dann eben dynamisch zu verändern das dazu kann man eben auch einen Check verwenden ich habe jetzt hier mal die eine Variante aufgeschrieben, aber wie gesagt wie schon hier markiert, ist das nicht so toll denn hier wird geprüft wenn die Multi wird geprüft, ist das eine Multi-Site und wenn das kein Super-Admin ist dann sagt einfach do not allow aber wie eben erwähnt es sollte lieber Capability-Checks benutzt werden es geht also auch so und eigentlich sieht es sogar noch einfacher aus ein If-Check weniger im Prinzip, eine Überprüfung weniger, man sagt einfach wenn das eine Multi-Site ist, muss der Nutzer auch diese Capability haben damit bleibt man dann wieder bei dem Ansatz einfach nur Capabilities zu überprüfen und diese Capability hat eh nur der Netzwerk-Administrate wie wenn man oben ist Super-Admin überprüfen werde da ist aber eben wie gesagt auf Capability das überprüfen werden soll ja, soll das entfernt werden das Ziel des Ganzen ist eben hier auch, dieser ist Super-Admin Aufruf zu entfernen, damit man irgendwann, wenn das weit genug vorangeschritten ist und auch man genug Dokumentationen für Plug-In-Entwickler etc. veröffentlicht hat dass man dann auf tatsächliche Rollensysteme was dann, was in der normalen Single-Site bei Wordpress existiert auch auf Multi-Site ausdehnen kann das würde dann auch eben erlauben auch im Netzwerk-Admin-Bereich deutlich Fein-Tuning, mehr Fein-Tuning vorzugehen ja, und das war's jetzt erstmal von mir ich hoffe, ich hab euch jetzt nicht so ratlos zurückgelassen und ja, ich bin jetzt auf jeden Fall noch gerne hier für Fragen verfügbar und wenn es vielleicht doch etwas länger dauert dann auch gerne später noch und hier gibt's noch eine ganz kurze für die Leute, die noch mehr sich in das Thema reinwuchsen wollen über ein paar Dinge Super, vielen lieben Dank, Felix ich geh mal davon aus du schickst nachher ein Link zu deinen Slides auch noch über Twitter raus mit dem Hashtag Okay, open mic für eure Fragen Okay, Bernhard, ich komme Also eine Sache, die am Anfang immer schwierig war und die so ganz noch nicht gelöst hab ist Post-Type-Einfüge dafür eigene Capabilities Anlege und sagen will, dass ein Nutzer nur Abonnent ist und diese neue Rolle hat, dann kann er zwar den Menüpunkt sehen, er kann glaube ich auch die Liste der Kassenpost-Type sehen er kann es aber nicht bearbeiten, wenn er nicht auch die Rolle Addic Capability Edit Posts hat ich hab das bis heute nicht verstanden, wo der Fehler ist also wenn ich eine neue Rolle anlege der hat irgendwie Edits wie in deinem Beispiel CT Tutorials und Dread CT Tutorials und so was auch immer kann er trotzdem nicht die Beiträge bearbeiten also diesen Kassenpost-Type Ich weiß, frag mich das kann daran liegen, dass da wird ja sobald man der Post-Type bei dem Post-Type dann gibst du auch die eigenen Capabilities während du den registrierst Genau, in der Register Post-Type gebe ich halt über Capabilities an mit den Metacaps und so weiter und dann weiß ich diese Rolle im Nutzer zu und der sieht dann auch im Backend eben nicht Beiträge und Seiten und sonst was er sieht aber diesen Kassenpost-Type im Menü kann aber eigentlich nichts machen Es gibt ein Argument bei Register Post-Type Metacap, hast du das benutzt? Das hab ich auch mal verwendet das hat irgendwie auch nicht funktioniert Also eigentlich ist es so man kann bei den eigenen Capabilities beim Post-Type angeben einen Singular und Plural-Namen der dann automatisch so verwendet wird dass dann Edit so und so Edit Publish so und so da werden dann die ganzen Fein-Tuning-Capabilities automatisch erstellt Ich weiß nicht ob du das so gemacht hast oder ob du alle manuell eingegeben hast Ich hab beide Warganten versucht das hat irgendwie beides nicht funktioniert Die simpelste Variante mit Post-Types das zu machen ist eigentlich diesen Singular und Plural-String anzugeben und dann Metacap auf True zu setzen dann kümmert er sich eigentlich um alles da kann ich jetzt gar nicht genau nachvollziehen macht dein Pluck-In also dein Beispiel-Pluck-In bei dem Pluck-In hab ich das komplett detailliert ich hab jede Capability die einzeln angegeben also der Pluck-In-Code hat auch an dieser Stelle extrem viele Kommentare weil ich jetzt eben das hier nicht erwähnen konnte also wenn ich das angucken will da hab ich alles genau dokumentiert möglichst genau aber eigentlich mal weil ich hab halt so ein System da gibt es halt Abonnenten die halt 2 zusätzliche Post-Types zu arbeiten können sollen und ich musste denen irgendwie auch Edit-Post geben das heißt sie könnten auch Beiträge bearbeiten ich hab ihnen dann nachhinein wieder gesagt sie dürfen es nicht aber ich krieg das irgendwie nicht hin dass es anders ist vielleicht können wir das nochmal angucken aber normalerweise müsste es so sein man braucht auf jeden Fall nicht Edit-Post wenn man das komplett mit den eigenen Capabilities hat kann ich es grad nicht nachholzen direkt warum es nicht klappt und vielleicht noch zur 2. Frage das Problem ist ja dass die Rollen in der Datenbahn gespeichert werden auch inklusive dem Namen hast du irgendeine clevere Lösung für Übersetzung von Rollennamen also ich hab diese ich glaub ich hab dann letztendlich mit den Members Pluck-In gemacht selbst eine Funktion anbietet aber das ist also die Lösung diese davon werde ich es auch nicht so toll für das eigenen Rollen wird der Namen irgendwo anders registriert wird im Prinzip die Besetzung an einer anderen Stelle registriert und dann dann dynamisch abgerufen das ist tatsächlich ein bisschen kaputt das Problem ist so dass er das nicht an allen Stellen macht also ich glaub in der in der Auswahl macht er das aber ich glaub zum Beispiel nicht im Filter in der Beitragsliste also man dann sagt vielleicht musst du auch ich weiß das jetzt gerade auch an der Stelle nicht genau aber vielleicht musst du dann deine eigene Capability genauso registrieren wie die WordPress Core Rollen registriert sind da gibt's auch es gibt irgendwo konkret diese Text Strings die kommen in WordPress 4 und dann gibt's eine Funktion Translate User Role die dann im Prinzip nur guckt ja okay das hier ist der englische String der jetzt aus der Datenbank guckt kommt und dann gucke ich irgendwo registriert und das wird da intern verwendet ich glaube das müsste man auch irgendwie mit der eigenen Rolle machen können da muss ich aber auch nochmal reingucken sonst noch Fragen? meintest eben dass man also ganz am Anfang des Vortrags dass man die Ansicht die manche Nutzer haben also beispielsweise ein Subscriber dass man einzelne Minutepunkte ausblenden kann mithilfe dieser Capabilities wie kann ich jetzt die Möglichkeit von Plugins also Beispiel Jetpack zeigt für jeden irgendwo neben dem Profil Link auch noch irgendwie so ein Jetpack Menüpunkt kann ich den da einfach ausblenden das kommt halt das kommt immer darauf an wie eben das Plugin selbst entwickelt ist also man kann generell andere Plugins nur anpassen wenn die dann auch genaue Capability checks überall verwenden deswegen habe ich jetzt hier das hauptbeton das eben für andere möglich ist es gibt halt viele Plugins die das leider nicht machen manchmal vielleicht auch gewollt weil die nicht wollen dass man die da weg macht aber ich will jetzt keine Namen nennen aber ja aber das kommt halt in dem speziellen Fall jetzt nicht sagen aber das kommt wirklich darauf an ob Jetpack an dieser Stelle einen speziellen Capability Check hat sobald da einer ist kannst du dann eben zum Beispiel durch User Hascap sagen ne die Capability nehme ich jetzt weg aber das kommt wirklich komplett auf den Einzelfall anderen also muss man einfach in den Queuecode schauen und ansonsten per CSS ja genau aber das ist natürlich nicht da würde man natürlich per URL immer noch hinkommen theoretisch wahrscheinlich ansonsten Felix ist ja noch hier bis Sonntag also dann löchert ihn nutzt die Gelegenheit oh ja dann möchte ich mich ganz herzlich bedanken dafür dass du den Talk heute das erstmal auf Deutsch gehalten also ich denke wir haben alle verstanden was er gesagt hat oder auch wenn die Anglesismen ja dann doch hier unter anderem vorgaben gut dann wünsche ich euch noch viel Spaß und genieße das Red Cam Retreat jetzt mit den Aktivitäten und Abend leckeres Essen wir sehen uns bis dann