Share
Tout au long de cette série, nous avons examiné comment WordPress peut servir de base au développement d’applications Web..
Le problème est que, jusqu'à présent, nous n'avons pas vraiment examiné les fonctionnalités de WordPress qui contribuent réellement à construire des applications web. Au lieu de cela, nous avons passé du temps à examiner la manière dont WordPress sert de base plutôt que de cadre, et nous avons examiné la manière dont WordPress est organisé par rapport à la plupart des cadres modernes disponibles..
Plus précisément, nous avons examiné le modèle de conception piloté par les événements par opposition au modèle de conception populaire modèle-vue-contrôleur (et ses variantes), et son apparence dans le contexte de WordPress..
Ainsi, nous avons repensé l’architecture d’application et sa structure dans le contexte de WordPress afin de nous aider à obtenir un meilleur modèle conceptuel de la façon dont les choses s’intègrent dans WordPress et sur la manière de tirer parti du système de hook, c’est-à-dire des actions. et filtres - et leur impact sur divers points du cycle de vie d'une page WordPress.
Bien que cela mérite un peu plus de discussion, nous devons examiner les fonctionnalités prêtes à l'emploi proposées par WordPress afin de bien comprendre les fonctionnalités et les API avec lesquelles nous devons travailler avant de jeter un coup d'œil sur Comment travailler avec eux.
Au cours des prochains articles, nous allons faire exactement cela.
Lorsque vous pensez aux composants d’une application Web, vous pensez probablement à un certain nombre de choses. En d'autres termes, outre l'architecture habituelle de la base de données, de l'intergiciel et de la couche de présentation, il existe également les fonctionnalités suivantes:
Bien que cette liste ne soit en aucun cas exhaustive, elle ne tient pas compte des éléments essentiels à la création d’une application Web standard (bien sûr, s’il manque des points, n’hésitez pas à les mentionner dans les commentaires)..
Et non - ce n'est pas normatif. Parfois, les applications Web ne gèrent pas les utilisateurs, parfois les utilisateurs n'ont pas de rôles, vous n'aurez peut-être pas besoin de mettre en cache, etc..
Mais l’important n’est pas de plaider pour tout les choses dont vous avez besoin. Au lieu de cela, il s'agit de faire un cas pour les choses qui sont disponibles devrait tu as besoin d'eux.
Cela dit, examinons ce que WordPress propose en matière de gestion des utilisateurs, d’autorisations, de fonctionnalité de messagerie et de gestion de session..
Quiconque a utilisé WordPress - même s'il s'agit uniquement de blogs ou d'une gestion de contenu de base - est familiarisé avec le système utilisateur de base. En d'autres termes, vous créez un nom d'utilisateur, un mot de passe, puis remplissez votre profil autant que vous le souhaitez..
En outre, les développeurs plus expérimentés connaissent bien les idées de rôles et de capacités. Je me risquerais même à dire que ceux qui utilisent WordPress connaissent bien le système même s'ils n'ont jamais vraiment jeté un coup d'œil au Codex ni écrit avec du code utilisateur..
Mais l’idée générale est très simple: les utilisateurs représentent un profil individuel pour un compte dans WordPress. Leur rôle est indiqué par ce qui leur a été attribué lors de la création du compte..
Ces rôles incluent:
Encore une fois, la plupart d’entre nous qui avons travaillé avec WordPress connaissons bien ces rôles, non? Mais comment les capacités s'intègrent-elles dans l'image??
En termes simples, ce sont les capacités qui accordent aux utilisateurs certaines autorisations dans l’application WordPress, ainsi que ce qui les restreint à partir de certaines zones de l’application. Ceci est relativement bien documenté dans le Codex.
Mais voici le problème: si vous construisez une application sur WordPress, les API disponibles permettent de verrouiller les utilisateurs en dehors des zones personnalisées que vous avez créées en fonction de leurs rôles et de leurs fonctionnalités..
Tout d’abord, supposons qu’à un moment donné, lorsque vous travaillez sur votre application Web, vous souhaitez pouvoir donner à l’utilisateur la possibilité de s’inscrire ou de s’inscrire à partir d’un formulaire d’inscription personnalisé (par opposition à la méthode standard de création du compte d’utilisateur dans le backend comme indiqué ci-dessus).
Cela peut être fait en créant un modèle avec un formulaire, puis en lisant les données de la publication..
En fait, cela peut être aussi simple que de capturer l'adresse électronique de l'utilisateur. Je le mentionne car, bien que les noms d’utilisateur soient agréables et amusants, les courriers électroniques ont tendance à être uniques à un individu, ce qui facilite la vérification des erreurs..
Ainsi, les étapes à suivre seraient les suivantes:
Relativement simple, non? Bien entendu, cela implique que vous puissiez générer un mot de passe pour l'utilisateur lors de la création de son compte. Heureusement, il y a une API pour ça.
Alors, voici un exemple comment créer par programme un utilisateur basé sur une adresse email spécifiée (en générant automatiquement un mot de passe).
Accentsconagua
if (null == username_exists ($ email_address)) $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ password, $ email_address); wp_update_user (array ('ID' => $ id_utilisateur, 'pseudonyme' => $ adresse_email));); else // Le nom d'utilisateur existe déjà, alors gérez-le en conséquence… Après cela, vous devez créer une nouvelle instance de WP_User.
$ user = new WP_User ($ user_id);
C’est ce qui nous permettra de définir des rôles pour l’utilisateur donné.
Enfin, il est temps de déterminer quel rôle et quel ensemble de fonctionnalités vous allez attribuer à l'utilisateur..
D'une part, vous pouvez coder ces valeurs en fonction des options offertes par WordPress. La vérité est que vous pouvez même créer des rôles et des fonctionnalités personnalisées. Pour l'instant, cela sort du cadre de l'article. cependant, nous pourrions le visiter dans une future série.
Alors, disons que nous voulons que tous les utilisateurs qui sont actuellement inscrits reçoivent le abonné rôle. Vous pouvez voir quel ensemble de capacités leur sera accordé dans cet article du Codex.
Définir un rôle est trivial:
$ user-> set_role ('contributor'); À ce stade, vous avez créé par programme un nouvel utilisateur dans l'application WordPress sans avoir à utiliser les fonctionnalités administratives par défaut..
Connectez-le simplement à votre propre modèle, validez, désinfectez et vérifiez les données entrantes. $ _POST données, et vous serez prêt à aller.
Le code complet ressemble à ceci:
if (null == username_exists ($ email_address)) // Génère le mot de passe et crée l'utilisateur $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ password, $ email_address); // Définissez le pseudonyme wp_update_user (array ('ID' => $ id_utilisateur, 'pseudonyme' => $ adresse_email);); // Définir le rôle $ user = new WP_User ($ user_id); $ user-> set_role ('contributor'); else // L'utilisateur existe déjà // end if / else Pas mal, droit?
Mais créer un utilisateur et ensuite enregistrer ses informations dans la base de données en seulement la moitié, à droite?
Une fois l'utilisateur connecté et authentifié, vous souhaiterez probablement restreindre le contenu en fonction de son rôle. Cela soulève donc la question suivante: une fois qu'un utilisateur est connecté, comment récupérer le rôle d'un utilisateur?
Heureusement, l'API de WordPress rend cela relativement facile:
Nous allons avoir besoin de profiter de la wp_get_current_user () fonction, puis nous devrons obtenir une instance de la WP_User objet en utilisant l'ID de l'utilisateur actuel après quoi nous pouvons jeter un coup d'oeil sur les capacités de l'utilisateur.
Regardez le code ci-dessous:
// Obtient une instance de l'utilisateur actuel $ user_id = wp_get_current_user () -> ID; $ user = new WP_User ($ user_id);
Pas mal, droit?
Cela rend très facile l'écriture de code conditionnel tel que:
// Ceci imprimera les capacités de l'utilisateur print_r ($ user-> wp_capabilities); // Ce qui à son tour vous permettra d'effectuer une vérification comme celle-ci: if ('1' === $ user-> wp_capabilities ['subscriber']) Nous avons un abonné Là est une autre façon de le faire, cependant:
global $ current_user; get_currentuserinfo (); if (0 === $ current_user-> user_level) // Nous avons un abonné
Mais cela soulève la question de savoir d'où vient ce zéro. Découvrez exactement cela.
Les différences entre les deux approches dépendent de la manière dont vous souhaitez que votre code soit orienté objet..
J'ai tendance à moins aimer utiliser global quand une approche orientée objet est disponible (comme dans le premier exemple); Cependant, le deuxième exemple fournit également une solution relativement simple. Votre choix.
Quoi qu'il en soit, une fois que vous êtes en mesure de vérifier de manière conditionnelle le rôle du compte d'un utilisateur, vous pouvez le limiter à des zones spécifiques de l'application..
Vous avez raison: au minimum, les utilisateurs ont besoin de recevoir des e-mails lorsque leur compte a été créé et ils doivent pouvoir recevoir des e-mails chaque fois que quelque chose a changé sur leur compte..
Encore une fois, WordPress fournit une API qui rend cela très facile, mais il peut être étendu au-delà de simples actions telles que le changement des informations de profil d'un utilisateur..
En fait, étant donné que WordPress dispose d’un système d’événements riche, vous pouvez potentiellement vous connecter à un nombre illimité d’événements et envoyer des e-mails lorsque vous en avez besoin. n'importe quoi arrive. C'est évidemment excessif, mais cela montre à quel point l'API est puissante.
Dans la section suivante, nous allons examiner l'API de messagerie de WordPress et la manière dont elle peut être utilisée pour envoyer des messages concernant certaines activités, ainsi que la manière dont elle peut être intégrée à d'autres fonctionnalités de l'application..
