Share
Parmi les fonctionnalités WordPress les moins utilisées, WP-Cron est souvent négligé par les développeurs. Ses applications, cependant, ne font pas rire. De la mise en cache aux notifications en passant par le nettoyage, la planification des tâches cron peut permettre de créer un avantage certain, même dans le plus simple des blogs WordPress. Joignez-vous à nous lorsque nous explorons des applications importantes de ce système.
WP-Cron n'est pas le même que le planificateur de cron Unix?
Immédiatement après avoir vu le mot cron, Je suis sûr que vous avez déterminé où vous vous dirigez: planifiez des événements parfaitement programmés à des intervalles spécifiés. Au contraire, WP-Cron n’est pas identique au planificateur de cron Unix. La distinction clé réside dans la façon dont il est exécuté; Contrairement à un processus d'arrière-plan, WP-Cron active chaque fois qu'un visiteur ouvre votre site utilisant WordPress. En tant que tel, il conserve la caractéristique essentielle d'un timing imprécis.
Oui, vous avez bien lu: calendrier imprécis. Bien que les mots cron et exactitude ressemblent à deux pois dans un pod, ils ne s'harmonisent pas dans le système de WordPress. Mais est-ce vraiment un problème? Si considéré dans le contexte de l'utilisateur, cela devient un atout.
Prenons l'exemple d'un travail cron normal s'exécutant toutes les cinq minutes pour mettre à jour certaines informations de base de données utilisées sur un site Web. Si aucun visiteur ne visite le site pendant 40 minutes, à quoi sert-il alors d'exécuter ce travail huit fois? Toutes les valeurs intermédiaires seraient toutes deux obsolètes et inutilisées. Si, au contraire, il entrait en ligne de compte lors de la première visite de l'utilisateur au bout de cinq minutes au minimum, le travail à effectuer ne serait pas le même, mais empêcherait également les mises à jour inutiles. En d'autres termes, WP-Cron étant basé sur l'utilisateur, il présente l'avantage de ne s'exécuter que lorsque les visiteurs sont présents..
Pour appliquer WP-Cron, considérons l’application de gestion RSS fréquemment utilisée, FeedBurner. De loin, l’une des fonctionnalités les plus populaires de cette application est sa capacité à compter les abonnés RSS. Une fois indexé, le nombre d'abonnés d'un site est accessible via un simple appel d'API. Il s'ensuit que cet appel d'API peut être effectué une fois par page pour fournir le nombre d'abonnés aux téléspectateurs. Cela pose cependant un problème.
Si l'on accède à l'API de FeedBurner une fois par page, cela entraîne inévitablement une requête HTTP supplémentaire (sans parler de celle d'un autre domaine) pour chaque visiteur. Cela augmente le temps de chargement de la page pour les utilisateurs.
Pour remédier à ce problème, il est important de réaliser une réalisation clé sur cette méthode de diffusion: il est peu probable qu'un compte d'abonnés RSS se mette à jour sur chaque affichage de la page. En fait, FeedBurner ne met à jour son nombre qu'une fois par jour. Même si cela devait changer rapidement, est-il vraiment nécessaire d'afficher le dernier décompte pour chaque visiteur? Le décompte est-il un peu obsolète, mais actualisé par la suite en une journée??
Pour nos besoins, il est totalement inutile d'extraire le nombre d'abonnés RSS pour chaque affichage de page. Au lieu de cela, s'il est récupéré pour un visiteur, il peut simplement être réutilisé pour les futurs. Ensuite, une fois le jour écoulé, une mise à jour de ce nombre peut être effectuée. Un tel processus s'appelle la mise en cache. Après avoir été mis à jour, le nombre d'abonnés RSS est mis en cache - stocké pour une utilisation future au lieu d'être recalculé - jusqu'à ce qu'un jour se soit écoulé. Et, avec cela, nous entrons dans le monde de WP-Cron.
Pour comprendre WP-Cron, il est important de savoir où la documentation est disponible. WordPress.org fournit des résumés de chaque fonction cron dans son codex. Pour mener à bien notre tâche définie précédemment, nous devrons examiner les wp_schedule_event fonction, qui nécessite quatre paramètres:
Notre événement se déclenchera lorsque l'heure actuelle atteindra ou dépassera le temps passé à cette fonction, comme prescrit par un futur visiteur du site Web. Il se déclenche ensuite en fonction du paramètre de récurrence, qui peut être défini sur horaire, tous les deux jours, tous les jours ou sur aucun. Des calendriers de récurrence personnalisés peuvent également être définis.
Pour faire face à l'événement, un hook est utilisé. En bref, un hook WordPress peut être considéré comme un espace réservé pour une action. Des actions peuvent être assignées aux hooks via WordPress ' add_action une fonction. Plus spécifiquement, pour ajouter un gestionnaire de fonction au hook donné, on peut appeler:
Accentsconagua
add_action ('hook_name', 'function_name'); où hook_name et function_name sont le nom de la fonction de hook et de la fonction de traitement, respectivement.
Étant donné que FeedBurner est mis à jour une fois par jour, nous allons spécifier un programme quotidien, conformément au code ci-dessous:
wp_schedule_event (time (), 'daily', 'feedburner_refresh');
Notez que temps() est l'horodatage UNIX actuel en secondes. Si exécuté, le hook 'FeedBurner Update' se déclenchera immédiatement et ensuite une fois par jour après. Notez que si nous devions simplement mettre cela dans notre fichier functions.php de WordPress, il programmerait un nouvel événement à chaque chargement de page. Ce n'est pas notre fonctionnalité désirée; nous voulons seulement planifier cet événement une seule fois. Le moyen le plus simple de procéder consiste simplement à vérifier si l'événement est déjà planifié. Cela peut être fait à travers le wp_next_scheduled function, qui retournera false si l'événement n'est pas configuré pour se déclencher à l'avenir ou à l'heure de son prochain déclencheur, sinon:
if (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh'); Si nous devons jamais annuler la planification de cet événement, il vous suffit de téléphoner au wp_unschedule_event fonction, qui prend les mêmes paramètres-sauf pour la récurrence-comme wp_schedule_event. Notez que le temps écoulé doit être le temps du prochain déclencheur, qui peut être récupéré via wp_next_scheduled:
if (false! == ($ time = wp_next_scheduled ('feedburner_refresh'))) wp_unschedule_event ($ time, 'feedburner_refresh'); Nous pouvons également annuler la planification de cet événement via son nom de hook en utilisant le wp_clear_scheduled_hook une fonction. Sachez que cette alternative supprimera également tous les autres événements utilisant le même hook.
wp_clear_scheduled_hook ('feedburner_refresh'); 
Maintenant que notre événement est planifié, nous devons y ajouter un gestionnaire:
add_action ('feedburner_refresh', 'update_rss_subscriber_count'); Ceci définit la fonction nommée update_rss_subscriber_count être appelé une fois feedburner_refresh le crochet est déclenché. Il est maintenant temps d'écrire cette fonction.
Pour récupérer le nombre d'abonnés dans le update_rss_subscriber_count fonction, nous pouvons appeler l'API de FeedBurner via l'URL
Cela renverra des données XML sous la forme suivante:
Les informations que nous recherchons se trouvent dans l'attribut de circulation. L'expression régulière suivante peut facilement analyser les données de cette valeur: circulation = "(. *?)".
En anglais, notre expression régulière correspond à ce qui suit:
circulation = - Le mot circulation suivi d'un signe égal"(. *?)" - Citations et tout à l'intérieur Exécuter ceci en utilisant le preg_match function récupérera un tableau de correspondances qui contiendra le nombre d'abonnés dans la première position d'index. Rassembler ces informations donne le code suivant:
// trouve l'URL de FeedBurner et en récupère les données // remplacez [NOM] par le nom de votre fil FeedBurner $ url = 'https://feedburner.google.com/api/awareness/1.0/GetFeedData?uri= [ PRÉNOM]'; $ data = @file_get_contents ($ url); // @ will surpress errors // utilisera une expression régulière pour analyser les données $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // récupère le nombre résultant si disponible $ count = false; if ($ correspond && $ correspond [1]) $ count = (int) $ correspond [1];
Maintenant que nous avons récupéré le nombre d’abonnés, nous devons le stocker pour plus d’accessibilité. au lieu de consulter à nouveau les données XML de l'API, les visiteurs accéderont simplement à cette valeur stockée..
Plutôt que de créer une base de données ou un fichier à des fins de stockage, nous pouvons utiliser une autre fonctionnalité de WordPress: les options. Les options WordPress sont des moyens simples de stocker des bits de données avec des noms d'identification. L'ajout, la suppression et l'accès aux options sont aussi simples que les fonctions suivantes:
update_option ($ name, $ value) - Ajoute ou met à jour une option avec le nom $ name et valeur $ valeur.delete_option ($ name) - Supprimer une option avec nom $ name.get_option ($ name) - Obtenir la valeur d'option associée à name $ name. Bien que notre nombre d’abonnés ne soit pas techniquement une valeur de configuration, l’utilisation des options WordPress est l’un des moyens les plus pratiques, sinon le plus pratique, de stocker des données aussi simples. Par conséquent, pour stocker le nombre d'abonnés, nous allons utiliser le update_option méthode, qui non seulement remplacera les valeurs précédentes, mais créera également l’option en premier lieu:
// si aucun compte n'a pu être trouvé, ne mettez pas à jour // à la place, conservez le nombre précédent si ($ count! == false) update_option ('subscriber_count', $ count); Notre fonction est complète! Après avoir configuré l'événement, récupéré les données via l'API FeedBurner et stocké la valeur souhaitée, il ne reste plus qu'à générer une sortie! Le code complet de la fonction de planification et de récupération, que vous pouvez placer dans functions.php, se trouve ci-dessous:
// planifie l'événement feedburner_refresh une seule fois si (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh'); add_action ('feedburner_refresh', 'update_rss_subscriber_count'); function update_rss_subscriber_count () // trouve l'URL de FeedBurner et en extrait les données // remplace le nom [NOM] par le nom de votre flux FeedBurner $ url = 'https://feedburner.google.com/api/awareness/1.0/ GetFeedData? Uri = [NOM] '; $ data = @file_get_contents ($ url); // @ will surpress errors // utilisera une expression régulière pour analyser les données $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // récupère le nombre résultant si disponible $ count = false; if ($ correspond && $ correspond [1]) $ count = (int) $ correspond [1]; // si aucun compte n'a pu être trouvé, ne mettez pas à jour // à la place, conservez le nombre précédent si ($ count! == false) update_option ('subscriber_count', $ count); Le nombre d'abonnés est maintenant juste un simple appel de fonction dans n'importe quel fichier de modèle:
echo get_option ('subscriber_count'); 
Le nombre d'abonnés RSS est maintenant optimisé. Plutôt que d'être récupéré pour chaque requête, il est mis en cache à l'aide de WP-Cron, ce qui permet aux utilisateurs de gagner du temps et d'économiser de la bande passante. Comme il n’est activé que lorsque notre site reçoit réellement un visiteur, notre fonction est paresseuse. Ce terme peut certainement être considéré comme bon dans ce contexte. Mais hélas, nous n’avons découvert qu’une application de WP-Cron ici; Le reste dépend de toi.
Vous avez votre propre application innovante de WP-Cron? Partagez-le avec nous dans les commentaires!
