La confidentialité et l'optimisation d'un widget de tableau de bord WordPress

Ce que vous allez créer

Dans les deux premières parties de cette série, nous avons terminé, un plugin complet qui nous indique l'état du serveur en tant que widget de tableau de bord. En tant que tel, il est disponible pour chaque utilisateur connecté. Certaines informations peuvent être sensibles et nous ne voulons pas qu'elles le voient. Il est donc préférable de vérifier le rôle de l'utilisateur pour déterminer si nous devons lui rendre le widget disponible.. 

Utilisation de rôles ou de fonctionnalités pour limiter la visibilité

WordPress utilise un concept de rôles, conçu pour permettre au propriétaire du site de contrôler ce que les utilisateurs peuvent et ne peuvent pas faire sur le site. Chaque rôle est autorisé à effectuer un ensemble de tâches appelées capacités. Nous pouvons personnaliser le rôle et ses fonctionnalités avec les fonctions add_roles et add_cap.

Notre plugin va créer un nouvel appel de capacité servermétrique. Seul l'utilisateur disposant de cette fonctionnalité peut charger nos widgets de tableau de bord. Nous allons ajouter cette fonctionnalité pour le rôle d'administrateur afin que tous les utilisateurs administrateurs la voient par défaut.. 

Pour les autres utilisateurs, vous pouvez utiliser le plug-in User Role Editor pour gérer les capacités de tout utilisateur particulier et attribuer le servermétique capacité pour l'utilisateur.

Nous utilisons add_cap pour ajouter une nouvelle fonctionnalité. Toutefois, cette fonction écrit dans la base de données. Nous ne devrions donc le faire que lors de l'activation du plug-in. Une fois la désactivation effectuée, nous devrions nettoyer la base de données en supprimant le rôle avec remove_cap..

class Dashboard //… autre code const CAP_METRIC = 'server_metric'; / ** * Commencer à installer hook * / public function run () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ this, 'add_asset')); add_action ('admin_footer', array ($ this, 'footer')); register_activation_hook (__ FILE__, array ($ this, 'add_servermetric_caps')); register_deactivation_hook (__ FILE__, array ($ this, 'remove_servermetric_caps'));  / ** * Ajoute plusieurs capacités pour admin par défaut * / function add_servermetric_caps () // obtient le rôle d'auteur $ role = get_role ('administrator'); // Cela ne fonctionne que parce qu'il accède à l'instance de la classe. // permettrait à l'auteur de modifier les publications des autres pour le thème actuel uniquement $ role-> add_cap (self :: CAP_METRIC);  function remove_servermetric_caps () // get_role renvoie une instance de WP_Role. $ role = get_role ('administrateur'); $ role-> remove_cap (self :: CAP_METRIC);  //…

Nous créons un nouvel appel constant CAP_METRIC et mettre sa valeur à server_metric afin que nous puissions facilement changer le nom de la capacité plus tard facilement. Nous modifions notre courir méthode pour ajouter deux crochets.

Register_activation_hook s'exécute lors de l'activation du plugin. Il accepte deux paramètres:

1. (string) nom de fichier: chemin d'accès au fichier de plugin principal
2. (rappeler) (Champs obligatoires) La fonction à exécuter lorsque le plugin est activé

register_deactivation_hook s'exécute lors de la désactivation du plugin. Il accepte le même paramètre que register_activation_hook.

Dans chaque fonction accrochée, nous allons charger le rôle administrateur et appeler add_cap ou remove_cap sur l'objet rôles.

Ensuite, nous allons modifier notre add_dashboard_widgets méthode pour enregistrer les widgets uniquement si l'utilisateur actuel a le servermétrique casquette.

 / ** * Enregistre le widget de tableau de bord pour qu'il apparaisse sur le tableau de bord * / function add_dashboard_widgets () if (! Current_user_can (self :: CAP_METRIC)) return false;  $ widget = Widget :: instance (); foreach ($ widget-> get_provider () as $ name => $ fournisseur) $ widget-> register ($ name); 

Ensuite, nous utilisons current_user_can pour vérifier si l’utilisateur actuel a la capacité de demander.
Désormais, seul l'administrateur verra le widget lors du chargement du tableau de bord. Si vous souhaitez activer le widget d'état du serveur pour d'autres utilisateurs, vous pouvez installer le plug-in User Role Editor pour gérer les rôles et les fonctionnalités de tout utilisateur.. 
Une fois installé et activé, allez dans le menu Utilisateurs, sélectionnez le Utilisateur> Capacités:

Ensuite, sur l'écran des capacités, nous pouvons attribuer le server_metric casquette.

Modifier les capacités utilisateur avec le plugin User Role Editor

En utilisant des rôles et des fonctionnalités, nous avons amélioré la sécurité de nos plugins afin de rendre notre widget accessible uniquement aux utilisateurs de confiance..

Mettre en cache la métrique du serveur

WordPress utilise l'API Transients en tant qu'API de cache. Les données sont sérialisées et stockées dans le wp_option tableau de WordPress avec un délai d'expiration du cache. 

Au lieu d'obtenir des données de métrique sur chaque requête HTTP, nous pouvons obtenir les données une seule fois et les mettre en cache. Cependant, nous ne pouvons pas simplement tout mettre dans le cache ou utiliser le même délai d'expiration. Par exemple, l'espace disque peut être mis en cache pendant 15 minutes et les informations du serveur pendant 60 minutes car elles sont rarement modifiées. De même, les logiciels installés peuvent être mis en cache pendant un jour car ils ne changent que rarement une fois la configuration du serveur configurée pour la production..

Nous utilisons principalement get_transient et set_transient lorsque vous travaillez avec l'API. Selon la documentation WordPress:

1. get_transient ($ transitoire): récupère le nom du passager sous forme de chaîne et renvoie ses données. Si les données ont expiré, il renvoie false. Nous devrions utiliser === opérateur à vérifier parce que nous pouvons stocker une valeur vide pour le transitoire.
2. set_transient ($ transitoire, $ valeur, $ expiration): récupère trois paramètres: le nom du transitoire, sa valeur et son délai d'expiration en secondes. Notez que le nom du passager ne doit pas dépasser 45 caractères..
   

Nos deux options consistent à envisager de mettre en cache les données de métrique ou les données HTML générées. La mise en cache des données HTML peut rendre notre site très rapide, mais cela alourdit la base de données. À cette fin, nous pourrions faire des points de repère pour décider lequel est le mieux. 

Pour notre tutoriel, mettons simplement en cache les données de métrique. De plus, nous devrions avoir un moyen d'invalider le cache - comme une ancre - qui nous permettra de recharger les données du tableau de bord et de forcer le chargement des données au lieu du cache.

Mise en cache des données pour le widget

Nous pouvons directement utiliser la fonction get_transient ou set_transient travailler avec l'API transitoire. Cependant, si nous décidons de changer la façon dont nous avons utilisé l'API transitoire, nous devons examiner chaque endroit où nous l'utilisons et le modifier pour chaque widget.. 

Ajoutons encore une couche pour extraire le mécanisme de cache. Nous allons concevoir une classe de cache simple pour notre widget qui comporte trois méthodes:

1. ensemble: définir les données de cache pour un widget
   
2. obtenir: obtenir les données de cache pour un widget
   
3. charge: essayez de charger à partir du cache, s’il n’existait pas, calculez les données, définissez le cache et renvoyez-le
   

Composons le fichier widget / cache.php de la manière suivante. Notez que, comme notre convention de chargement automatique, le nom de la classe sera Cache et son espace de noms est AXE \ StatBoard \ Widget

get_metric (); static :: set ($ fournisseur, $ data, $ cache_time); retourne $ data;  

Tout d'abord, notez que nous avons marqué nos méthodes de mise en cache comme statiques. Notre ensemble et obtenir les méthodes ne sont que des wrappers pour  get_transient et set_transient. le charge la méthode repose sur ensemble et obtenir. Toutes ces méthodes s'attendent à récupérer l'objet fournisseur de widget; donc à l'intérieur de charge méthode que nous pouvons invoquer get_metric méthode pour obtenir les données réelles. 
Ici, la chose la plus importante est le nom transitoire. Étant donné que le nom de classe est unique dans notre application, nous le considérons comme suffisamment unique pour le nom transitoire. La fonction get_class renvoie le nom de classe d'un objet.
Il est temps d'utiliser notre Cache classe. Nous allons essayer de mettre en œuvre Cache pour widget / software.php. Changer notre original Obtenir du contenu méthode pour:

$ info) $ content. = "
$ cmd  $ info
"; echo $ content; //…

Vous pouvez voir que nous nous débarrassons de $ cmds = $ this-> get_metric () et simplement le remplacer par Cache :: load qui chargera les données du cache ou du système si aucun cache n'existait. 
Assurez-vous de transmettre le deuxième paramètre pendant combien de temps vous souhaitez que les données soient mises en cache. sinon, les données ne sont mises en cache que pendant cinq minutes. Comme les informations logicielles sur le serveur changent rarement à court terme, nous avons défini le temps de cache à 24 heures..
Maintenant que vous avez eu l'idée, vous pouvez répéter avec tous les autres widgets que vous souhaitez mettre en cache. Il suffit de remplacer get_metric à l'intérieur Obtenir du contenu avec:

Cache :: load ($ this, $ time_in_second);

l'avoir prendre en charge de sa mise en cache.
Les données d'utilisation du disque peuvent être mises en cache pendant des heures et l'interface Ethernet peut être mise en cache pendant un jour ou deux. C'est à vous de décider combien de temps vous voulez le mettre en cache. Nous pouvons également créer une page d’options permettant au plug-in de gérer ces valeurs de cache de durée de vie. Cela peut être un exercice sur lequel vous pouvez travailler après avoir terminé cet article..
Nous avons un dernier exemple avec widget / ethernet.php. Nous pouvons ajouter une capacité de cache comme suit:

fonction publique get_content () 
$ interfaces = Cache :: load ($ this, 3600 * 24 * 7);
$ html = '


';
foreach ($ interfaces en tant que $ interface => $ ip) 
$ html. = "


";

$ html. = '
Interface
IP
$ interface
$ ip
';
echo $ html;

  //… 

Encore une fois, il suffit de remplacer get_metric avec Cache :: load. Les informations Ethernet et son adresse IP ne changent probablement jamais. J'ai donc défini une durée de vie très longue du cache à une semaine: 3600 secondes * 24 heures * 7 jours.

Forcer le chargement de données réelles

Une fois que nous avons ajouté une capacité de cache, nous devons prendre en charge un mécanisme permettant à l'administrateur d'extraire le widget sans le mettre en cache. Pour ce faire, le plus simple consiste à utiliser un paramètre de requête spécial pour indiquer que nous voulons des données réelles.. 

Que diriez-vous de petit paramètre comme nocache pour ça? Donc, au lieu de l’URL par défaut du tableau de bord WordPress avec domaine.com/wp-admin/ on peut utiliser domain.com/wp-admin/?nocache. 

Cela semble facile? Faisons le.

Editer notre méthode obtenir dans widget / cache.php

 fonction statique get (fournisseur $ fournisseur) if (isset ($ _GET ['nocache']))) return false;  $ cache_id = get_class ($ fournisseur); if (false! == $ data = get_transient ($ cache_id)) return $ data;  return false; 

Tant que le nocache Si le paramètre de requête existait, nous renvoyons la valeur false instantanément et forçons donc les données réelles à être récupérées au lieu des données mises en cache.
Maintenant, réfléchissons à l’ajout de cette fonctionnalité sans la classe Cache. Nous pouvons avoir à aller à chaque ligne de get_transient et vérifiez le paramètre de requête ici. Par conséquent, envisagez de diviser les choses en plusieurs couches lors de la conception de votre plugin. Ne mettez pas tout dans le même fichier et ne copiez pas le code à plusieurs reprises.
Maintenant, essayons de visiter domain.com/wp-admin et domain.com/wp-admin?nocache et remarquez la vitesse différente.987ms de chargement avec activation du cache

Voici le résultat avec ?nocache = 1 ajouté à l'URL.

3.01 seconde de chargement sans cache

Utilisation de cronjob pour générer du cache

Même si nous avons implémenté et utilisé un cache, si le cache est manquant, la page est toujours lente. Il faut encore du temps pour extraire les données du serveur. Nous avons encore de la place pour nous améliorer avec cronjob. Nous pouvons planifier l'exécution de notre plug-in à un intervalle spécifique. WordPress nous permet de le faire via wp_schedule_event. Idéalement, nous pouvons utiliser wp_schedule_event pour programmer un hook qui sera exécuté à un intervalle spécifique.

Sur la base de cet exemple, notre plug-in peut programmer un hook à invoquer toutes les trois minutes. Le hook invoquera à son tour une autre fonction pour extraire les données de métrique. Les données sont toujours disponibles dans le cache et suffisamment fraîches.

Ouvrez notre fichier de plugin principal, serverdashboard.php, et mettre à jour la méthode d'exécution pour inclure un nouveau crochet ainsi qu'un nouveau gestionnaire de crochet.

 3 * 60, 'display' => __ ('une fois toutes les 3 minutes')); renvoyer les horaires;  / ** * Calendrier de planification pour l'événement. Si la planification n'existe pas *, nous l'enregistrons dans * / function setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (time (), '3min', 'metric_generate_evener_3min');  / ** * La fonction principale qui s'exécute sur cron et * génère des données * / function generate_metric () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () as $ name => $ fournisseur) // En appelant get_content, nous déclenchons le processus Cache :: load. $ provider-> get_content (); 

Tout d'abord, la méthode wp_schedule_event ne prend en charge que trois types de récurrence: quotidienne, horaire et bi-quotidienne. Nous devons ajouter un nouveau type de récurrence avec le filtre wp_get_schedules. 
Nous ajoutons un autre type récurrent qui s'exécute toutes les trois minutes. Sa définition:

 $ schedule ['3min'] = array ('interval' => 3 * 60, 'display' => __ ('une fois toutes les 3 minutes')); renvoyer les horaires;

Nous pouvons personnaliser la valeur de l'intervalle en fonction du nombre de secondes pendant lequel nous souhaitons que le travail soit répété. Ensuite nous installons un metric_generate_every_3min crochet.

 add_action ('metric_generate_every_3min', tableau ($ this, 'generate_metric'));

Ceci est notre crochet personnalisé, il n’existe pas dans WordPress. On enregistre une poignée avec méthode generate_metric pour ce crochet. N'importe quand metric_generate_every_3min le crochet est invoqué, generate_metric sera exécuté.
Dans la déclaration suivante, nous passons à l'action init avec setup_schedule méthode pour vérifier l'existence du prochain événement planifié du hook metric_generate_every_3min. S'il n'est pas encore défini, nous programmerons un événement avec wp_schedule_event, en utilisant notre récurrence personnalisée pour toutes les trois minutes pour ce crochet.
À l'intérieur de generate_metric méthode, nous parcourons tous les widgets disponibles et appelons leur Obtenir du contenu méthode. En faisant cela, nous déclenchons Cache :: load processus pour cette métrique.
WordPress exécutera automatiquement ces événements planifiés chaque fois que quelqu'un visite votre site WordPress. Il essaiera de trouver l'événement planifié qui doit être exécuté et l'invoquera..
Cependant, vous pouvez également les exécuter manuellement. WordPress exécute cronjob via la consultation du fichier wp-content.php avec l'URL votredomaine.com/wp-cron.php?doing_wp_cron.
Vous voudrez peut-être mettre à jour votre travail cron pour ajouter un nouveau travail qui envoie une requête ping à l'URL ci-dessus toutes les minutes.
Ouvrons votre crontab sur le serveur avec crontab -e et ajoutez cette ligne à la fin de celle-ci:

0 * * * * wget domain.com/wp-cron.php?doing_wp_cron> / dev / null 2> & 1

Nous avons utilisé wget pour envoyer une requête HTTP au fichier wp-cron.php. Puisque nous ne nous soucions pas de la sortie et de toute erreur, nous redirigeons toute la sortie vers / dev / null.
Vous pouvez en savoir plus sur la configuration de ces tâches cron dans les articles suivants:

1. http://tommcfarlin.com/wordpress-cron-jobs/
2. http://code.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordp…
   

Conclusion

Ceci conclut notre long tutoriel sur la création d'un widget de tableau de bord de serveur qui donne un aperçu des différents aspects de notre système..
Tout au long de cette série, nous avons utilisé des bibliothèques tierces, pris une idée, expérimenté avec la ligne de commande, appris à propos des rôles et des fonctionnalités, et passé en revue les capacités transitoires de WordPress ainsi que ses mécanismes de planification d'événements..
Enfin, nous avons tout lié ensemble dans un plugin WordPress.
Veuillez envisager de laisser un commentaire et de nous faire savoir quelles autres idées et quels changements vous apportez, ainsi que vos questions et / ou commentaires sur cette série..