Cette série de tutoriels en quatre parties traite des utilisateurs, des rôles et des fonctionnalités de WordPress. La série couvrira l'architecture et la conception des rôles d'utilisateur dans WordPress; souligner les fonctions les plus importantes pour interagir avec les utilisateurs et gérer les rôles et les fonctionnalités; et dans le dernier tutoriel, nous allons construire un exemple réel qui démontre l'utilité de cette API.
Dans cette première partie, nous allons passer en revue les bases et le fonctionnement interne du système d’utilisateurs, de rôles et de capacités de WordPress. Aucune fonction ou code ne sera couvert dans cette partie. Vous pouvez donc passer à la suivante si vous souhaitez uniquement écrire du code qui interagit avec ce système. Cependant, je vous recommande fortement de commencer par cela pour vous faire une idée de base des utilisateurs et des rôles dans WordPress..
Après la version 2.0, WordPress a introduit un nouveau système de rôles et de fonctionnalités qui remplace l'ancien système de niveau utilisateur. L'ancien système ne sera pas discuté; il est maintenant totalement obsolète (depuis la version 3.0) et ne devrait plus être utilisé.
Le nouveau système est plus avancé et plus flexible. Il est maintenant possible de créer des autorisations personnalisées et de les affecter par utilisateur. Cette mise à jour a permis de corriger les faiblesses de l'ancien modèle et de permettre aux développeurs de créer des plugins et des thèmes plus puissants et personnalisés..
WordPress conserve les données des utilisateurs dans deux tableaux: wp_users
et wp_usermeta
(Je vais supposer pendant toute cette série que votre configuration WordPress utilise la valeur par défaut wp_
préfixe). La deuxième table est créée pour étendre la première et permet aux développeurs d'attacher des données supplémentaires à chaque utilisateur..
S'il n'y avait qu'une seule table, vous ne pourrez pas attacher plus de données aux utilisateurs, soit vous devrez conserver toutes ces données sérialisées dans une ligne de colonne, ce qui ne convient pas vraiment aux performances et à l'évolutivité. (Imaginez 50 plugins où chacun ajoute 2 ou 3 champs supplémentaires par utilisateur.)
Vous trouverez ci-dessous un schéma du schéma des deux tables. Les tables sont liées entre elles par une relation "un à plusieurs". En fait, vous pouvez avoir autant de lignes que vous le souhaitez dans la liste. wp_usermeta
avec le même identifiant d'utilisateur
(qui est la clé étrangère pour cette relation et représente la colonne ID dans wp_users
)
Si nous examinons le schéma de ces deux tables, nous pouvons en conclure que wp_users
est utilisé pour stocker une quantité limitée et finie de données sur chaque utilisateur. Certains d'entre eux sont requis et principalement utilisés par le noyau WordPress, des thèmes ou des plugins tels que l'identifiant, le mot de passe, l'adresse e-mail et le joli nom (ou pseudo). Mais ce n'est pas le cas pour le user_url
domaine, par exemple. Ce champ pourrait rentrer dans le wp_usermeta
table car ce n'est pas nécessaire.
Certains champs obligatoires sont stockés dans le wp_usermeta
comme le surnom. En fait, je ne suis au courant que de celui-ci. Cependant, certaines informations critiques, telles que les capacités utilisateur, le niveau utilisateur et le mode SSL, sont stockées dans la mémoire. wp_usermeta
table aussi. Cela le rend non moins important que le wp_users
table (surtout lorsque les permissions et la sécurité sont une préoccupation majeure).
Cela étant dit, vous devez faire attention lorsque vous traitez avec les deux tables. Je vous recommande de vous en tenir aux fonctions WordPress pour interagir avec les utilisateurs et le système de fonctionnalités.
Comme tout autre système de gestion de contenu, WordPress dispose d’un système d’autorisation permettant de définir et de limiter les privilèges de chaque utilisateur. Dans cette section, je vais expliquer le concept des rôles et des capacités dans WordPress. Donc, si vous avez eu du mal avec l'explication du Codex, j'espère que celle-ci sera plus claire car j'aborde le concept différemment.
Oubliez les rôles. Supposons pendant quelques minutes qu'ils n'existent pas.
Prenons le scénario suivant: vous avez un blog WordPress que vous avez récemment configuré et vous en êtes l'administrateur. (Vous disposez donc de toute la puissance possible.) Vous avez décidé d'ajouter un nouvel utilisateur à votre blog pour contribuer à certains articles. Vous avez également pensé qu'il serait juste de lui permettre de commenter et de personnaliser son nom d'affichage..
Vous trouverez ci-dessous une photo de notre utilisateur avec les fonctionnalités que vous lui avez attribuées..
Donc, c'est aussi simple que cela. Vous attribuez des fonctionnalités aux utilisateurs. Vous êtes libre de nommer ces capacités. Par exemple, vous pouvez nommer "write_new_post" comme slug pour écrire un nouveau message..
Dans votre blog, vous aurez une liste de fonctionnalités, chacune conférant un pouvoir spécial et limité aux utilisateurs qui en disposent. Chaque utilisateur peut avoir un nombre limité de fonctionnalités. Un utilisateur qui a toutes les capacités est un administrateur puisqu'il peut pratiquement tout faire. Considérez-le comme un système de permission. Les fonctionnalités sont des autorisations que vous accordez aux utilisateurs..
Mais pourquoi les capacités sont-elles importantes? Eh bien, vous êtes le seul responsable de cela. Par exemple, dans le cas où vous construisez votre propre plugin (ou thème), vous pouvez créer votre propre "access_control_panel
"capacité et l'assigner à un certain nombre d'utilisateurs.
Lorsqu'un utilisateur demande votre "Panneau de configuration", vous devez vérifier qu'il dispose du "access_control_panel
"capacité avant d'afficher la page du Panneau de configuration. Vous pouvez également vérifier la capacité avant d'exécuter un bloc de code particulier pour vous assurer que l'utilisateur dispose des privilèges requis..
WordPress est livré avec un nombre par défaut de fonctionnalités nécessaires à son fonctionnement. Vous pouvez également utiliser ces fonctionnalités, mais veillez à ne pas les supprimer. Vous pouvez certainement créer vos propres capacités personnalisées.
Alors maintenant, nous savons ce que sont les capacités. Prenons un autre scénario où vous avez beaucoup d'utilisateurs. Vous souhaitez séparer ces utilisateurs en deux groupes: les utilisateurs puissants et les utilisateurs moins puissants. Chaque groupe d'utilisateurs aura des capacités spéciales.
Pour ce faire, vous devez attribuer ces fonctionnalités à chaque utilisateur, ce qui peut être frustrant et improductif. Les rôles sont faits exactement pour cela, ils sont ce que les utilisateurs sont regroupés par.
Ainsi, au lieu d’attribuer des fonctionnalités aux utilisateurs, vous leur affectez des rôles; et ensuite vous attribuez les rôles aux utilisateurs. Il est toutefois possible d'attribuer des fonctionnalités directement aux utilisateurs. Un rôle peut être créé pour un ou plusieurs utilisateurs. et un utilisateur ne peut avoir aucun, un ou plusieurs rôles.
Donc, la réalité est beaucoup plus comme ça.
Il est important de noter ici que vous devez rechercher une fonctionnalité utilisateur et non un rôle d'utilisateur avant d'exécuter du code nécessitant une autorisation. Ne supposez jamais qu'un rôle a une capacité spécifique car elle peut être modifiée par un autre plugin ou thème.
Certaines actions nécessitent plusieurs capacités. Par exemple, pour éditer un article de blog, vous avez besoin du 'edit_post
' aptitude. Mais que se passe-t-il si ce blog a été créé par un autre utilisateur? Vous aurez alors besoin duedit_other_posts
«capacité aussi. Vous devez donc vérifier les deux avant de permettre à l'utilisateur de modifier le message..
C'est là que les méta capacités entrent en jeu. WordPress a un map_meta_cap ()
fonction qui renvoie un tableau des capacités requises pour exécuter une capacité particulière.
Revenons donc à l'exemple précédent. Supposons que nous avons un utilisateur avec un ID de 3 et que nous voulons vérifier si cet utilisateur peut éditer un article de blog avec un ID de 5. Cet article de blog est publié par un autre utilisateur avec un ID de 6..
Dans ce cas, la map_meta_cap ()
function retournera un tableau avec les capacités suivantes: edit_post
, edit_published_posts
, et edit_other_posts
. Pour créer ce tableau, le map_meta_cap ()
la fonction doit faire des vérifications basées sur l'utilisateur et le post.
Les fonctionnalités par défaut vérifiées par la fonction sont 'Supprimer l'utilisateur
','Modifier l'utilisateur
','remove_user
','promouvoir_user
','Supprimer le message
','delete_page
','edit_post
','modifier la page
','read_post
', ou 'read_page
'. Il est toutefois possible d’augmenter le vôtre en accrochant lemap_meta_cap
'filtre.
Il s’agissait donc, en un mot, des utilisateurs et du système de permissions de WordPress. J'ai essayé de le garder aussi simple et minimaliste que possible; et j'ai évité d'inclure un code pour cette raison. Dans la prochaine partie, nous examinerons un large éventail de fonctions fournies par WordPress pour interagir avec ce système..