Share
Ce tutoriel en quatre parties couvre les utilisateurs WordPress, les rôles et les fonctionnalités. 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 les deux derniers articles, nous allons construire un exemple concret qui démontre l'utilité de cette API.
Dans le dernier tutoriel, nous avons construit un exemple concret en utilisant le système de rôles et de fonctionnalités de WordPress. Le système est encapsulé dans une seule classe. et peut être utilisé en initialisant la classe et en lui transmettant des paramètres. Les paramètres sont le tableau d'identifiants des utilisateurs, un autre tableau de noms de rôles; et aussi un commutateur pour permettre l'accès à tous les utilisateurs. En pratique, vous voulez que l'administrateur WordPress puisse modifier ces paramètres; et ainsi contrôler quels utilisateurs ont un "tableau de bord client" accès.
Dans ce tutoriel, nous construirons l'interface qui donnera à l'administrateur la possibilité d'initialiser automatiquement notre classe et de l'alimenter avec les données adéquates. L'interface permettra à l'administrateur de sélectionner des rôles, des utilisateurs; ou opter pour un accès complet.
Le code de ce nouveau didacticiel est disponible sur le même référentiel Github. Pour accéder au code précédent, accédez au premier commit du référentiel. J'ai décidé de garder le code sans licence, vous êtes donc libre de l'utiliser et de le mettre sous licence à votre guise.
Contrairement aux utilisateurs, WordPress ne fournit aucune interface pour les rôles. Vous ne pouvez pas ajouter, supprimer ou modifier des rôles ou des fonctionnalités existants sans l'aide d'un plug-in tiers. Vous pouvez toutefois avoir une liste des rôles existants dans votre blog à partir de la liste déroulante de sélection de rôle lors de la modification d'un profil utilisateur existant. L'interface vous limite à la sélection d'un seul rôle pour un utilisateur particulier. En outre, vous ne pouvez pas attribuer de fonctionnalités aux utilisateurs avec l'interface par défaut fournie avec WordPress.
Pour cette raison, il est important que votre plug-in fournisse l'interface requise pour configurer ses capacités d'accès utilisateur. Les utilisateurs de votre plugin ne doivent pas compter sur un plugin tiers externe. En fonction de la sophistication de vos utilisateurs et de leur connaissance de la plate-forme WordPress, ils voudront peut-être:
Si vous êtes un peu confus, nous parlons ici d'un plug-in qui comporte deux tableaux de bord: un pour l'administrateur du blog, doté de fonctionnalités et de paramètres spécifiques à l'administrateur; et un autre pour certains utilisateurs, dont les fonctionnalités et les paramètres sont limités. Donc, cet exemple ne s'applique pas à tous les plugins existants; mais seulement ceux qui nécessitent un accès administrateur et client.
Pour cela, nous aurons deux interfaces différentes: une pour la sélection des rôles et une autre pour la sélection des utilisateurs. Pour la sélection des rôles, nous devons créer une interface personnalisée, car WordPress n’a pas d’interface visuelle pour eux. Pour la sélection des utilisateurs, nous pouvons exploiter la page de profil utilisateur déjà existante en ajoutant des champs personnalisés supplémentaires..
WordPress est livré avec un petit nombre de rôles prédéfinis: administrateur, auteur, contributeur, éditeur et abonné. Les utilisateurs avertis de WordPress peuvent ajouter leurs propres rôles pour catégoriser et gérer leurs utilisateurs. De ce fait, notre interface doit extraire tous les rôles du site et offrir la possibilité de choisir ceux qui autoriseront l'accès au client. J'ai également profité de l'occasion pour coller le commutateur "tous" à la même interface. Si vous cochez "Tous", vos autres paramètres seront remplacés..
Pour construire l'interface, nous allons utiliser l'API de paramètres WordPress et créer une fonction personnalisée qui affichera les cases à cocher. Le code suivant est utilisé pour enregistrer le "wptuts_settings"paramètres du formulaire. Nous enregistrons également une section à l'intérieur de ce formulaire; et un champ à l'intérieur de la section.
Accentsconagua
// Enregistre un nouveau formulaire de configuration add_action ('admin_init', 'wptuts_settings_form'); function wptuts_settings_form () // Enregistre un nouveau paramètre sous la forme register_setting ('wptuts_settings', 'wptuts_settings'); // Enregistre une nouvelle section add_settings_section ('wptuts_settings', 'Paramètres généraux', 'wptuts_section', 'general_settings_form', 'Accès client'); // Enregistre un nouveau champ add_settings_field ('client_roles', 'Client Roles', 'wptuts_roles_check', 'general_settings_form', 'wptuts_settings', array ('clients_roles', 'wptuts_settings')); function wptuts_section () return null; La fonction add_settings_section () requiert une fonction en tant que troisième paramètre qui retourne la description de la section. Pour que les choses restent simples, j'ai passé une fonction qui renvoie null (ou rien).
La fonction add_settings_field () accepte un identifiant de champ, une étiquette, une fonction, la section et le formulaire auxquels le champ doit être connecté; et l'argument à passer à la fonction de champ. La fonction de champ affichera le code HTML du champ.
L'API de paramètres WordPress permet de créer des formulaires qui enregistrent automatiquement leur contenu dans une option WordPress. L'option est "wptuts_settings"et constitue un tableau contenant les différents paramètres de notre plug-in. Pour que WordPress reconnaisse nos champs de formulaire, nous devons d’abord les enregistrer à l’aide des fonctions indiquées ci-dessus; et également d’attribuer le bon nom à chaque champ. Chaque champ avoir un nom sous la forme wptuts [nom_zone].
Dans notre cas, nous avons un nombre imprévisible de rôles; et donc un nombre imprévisible de cases à cocher. Cela n'a pas de sens de créer et d'enregistrer un champ pour chaque rôle. Heureusement, HTML supporte les éléments de tableau; alors nous nommons nos cases à cocher wptuts [nom_zone] [rôle_1], wptuts [nom_zone] [rôle_2], wptuts [nom_zone] [rôle_n]… WordPress reconnaîtra cet élément de tableau HTML et l'enregistrera sous forme de tableau PHP.
Ci-dessous le contenu de la "wptuts_settings"tableau quand le"tout","auteur", et "abonné"les cases à cocher sont sélectionnées.
'wptuts_settings' => array 'client_roles' => array 'all' => chaine 'on' (longueur = 2) 'author' => chaine 'on' (longueur = 2) 'abonné' => chaine 'on' (' longueur = 2) La fonction liée au champ est "wptuts_roles_check". Il accepte un tableau contenant les paramètres ID et le nom du champ; cela permet de réutiliser notre fonction dans d’autres champs. Vous pouvez ignorer ce paramètre et coder en dur l’ID des paramètres et le nom du champ dans votre fonction..
La fonction va parcourir un tableau de noms de rôles renvoyés par "$ wp_roles-> get_names ()". Il va également désactiver le rôle d’administrateur et ajouter une case à cocher supplémentaire" tous ".
/ ** * Génère les cases à cocher des rôles sous la forme * * @param array $ param * / function wptuts_roles_check ($ param) // Liste des rôles $ settings = get_option ($ param [1]); if (isset ($ settings [$ param [0]])) $ val = $ settings [$ param [0]]; else $ val = "; // Génération de code HTML // Obtention de rôles WP global $ wp_roles; $ roles = $ wp_roles-> get_names (); unset ($ roles ['administrateur']); // Génère du code HTML if ($ val ['all'] === 'on') echo ' Tout
'; else echo ' Tout
'; foreach ($ rôles en tant que $ key => $ valeur) if ($ val [$ key] === 'on') echo ' '. valeur de $. '
'; else echo ' '. valeur de $. '
';
Comme indiqué dans le premier tutoriel de cette série, les utilisateurs peuvent avoir des données supplémentaires qui leur sont associées sous forme de paires clé / valeur. Nous avons présenté les fonctions permettant d'ajouter, de mettre à jour et de supprimer les métadonnées des utilisateurs dans le deuxième tutoriel. Dans cette partie, nous verrons comment ajouter une section à chaque page de profil d'utilisateur et mettre à jour les métadonnées de l'utilisateur en conséquence..
WordPress propose quatre actions à connecter à la page de profil de l'utilisateur. Deux actions pour ajouter de nouveaux champs à la page d’édition; et deux autres actions pour gérer la demande HTTP POST. La différence entre le "show_user_profile"action et"edit_user_profile"l'action est que ce dernier passe un WP_User objet pour l'utilisateur en cours d'édition. Cependant, la différence entre les deux autres actions n'est pas claire.
/ ** * Crochets Metabox utilisateur * / private function metabox_user () // Affiche le metabox add_action ('show_user_profile', array (& $ this, 'display_metabox')); add_action ('edit_user_profile', array (& $ this, 'display_metabox')); // Enregistrer la mise à jour add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox')); Contrairement à l'API Settings, il n'y a pas de restrictions ou d'exigences pour le code HTML que la fonction génère. WordPress ne fait pas la sauvegarde des métadonnées, vous êtes donc libre de les gérer comme vous le souhaitez.
/ ** * Affiche le champ personnalisé * * @param objet $ utilisateur * / fonction publique display_metabox ($ utilisateur) $ user_meta = get_user_meta ($ utilisateur-> ID, 'wptuts_client', true); if ($ user_meta) $ vérifié = 'vérifié'; else $ vérifié = "; print <<
