WP-Cron

Définition : Dans WordPress, ordonnanceur applicatif déclenché par le trafic ou un appel explicite, et non horloge système garantie. Il faut distinguer la planification enregistrée de l'exécution réellement observée sur le site.

Comprendre et utiliser

À quoi sert cette notion ?

Ordonnanceur applicatif déclenché par le trafic ou un appel explicite, et non horloge système garantie. Un usage concret consiste à programmer le nettoyage nocturne des exports temporaires d'un plugin. La fiche précise ainsi ce que résout l'élément et pourquoi son comportement importe dans un projet WordPress.

Fonctionnement technique

WP-Cron s'appuie sur des événements stockés par WordPress et sur les hooks auxquels des callbacks sont attachés. Contrairement à un ordonnanceur système, il peut être déclenché par l'arrivée d'une requête et les échéances ne garantissent pas un horaire à la seconde près. Pour ce terme, retenir précisément : ordonnanceur applicatif déclenché par le trafic ou un appel explicite, et non horloge système garantie. La valeur pratique dépend de son cycle d'exécution et du type de données réellement manipulées.

Dans quel contexte l’utiliser ?

Exemple professionnel : Programmer le nettoyage nocturne des exports temporaires d'un plugin. Avant l'application, relever la version de WordPress, le type d'installation, les droits disponibles et les éventuelles extensions participant au traitement.

Étude de cas : application professionnelle

Une intervention documentaire ATOOLPHA part du problème suivant : programmer le nettoyage nocturne des exports temporaires d'un plugin. L'équipe relève l'état attendu et observe le comportement réel. Elle reproduit ensuite un cas limite lié à la notion : une visite peut déclencher une tâche en retard; envisager un cron système pour les exigences horaires strictes. Elle contrôle alors les données réellement affectées. Elle note toute divergence avant déploiement.

Exemple technique commenté

Extrait PHP dans le contexte WordPress chargé, présenté comme exemple pédagogique isolé et non comme extension autonome. Les fonctions nécessitant un hook, un contrôle de permission ou une activation préalable doivent être intégrées à ces mécanismes.

// Dans un plugin : contrôler la planification avant de l'ajouter.
if ( ! wp_next_scheduled( 'atoolpha_maintenance_daily' ) ) {
    wp_schedule_event( time() + HOUR_IN_SECONDS, 'daily', 'atoolpha_maintenance_daily' );
}

Décryptage du code et résultat attendu

Le hook est stable et le test initial empêche des événements identiques de s'accumuler. Examiner les arguments dans l'ordre, identifier le type de retour et distinguer les valeurs fictives des paramètres réellement requis par la fonction ou la commande.

Exercice guidé pour vérifier la notion

Lister les événements dans une instance de test, relever l'horaire prévu, déclencher une exécution contrôlée et comparer les journaux avant et après. Vérifier aussi le fonctionnement lorsque le site reçoit peu de visites. Pour « WP-Cron », vérifier ensuite ce cas ciblé : programmer le nettoyage nocturne des exports temporaires d'un plugin. Conserver la valeur observée, la date et le contexte de test.

Précautions et limites

Point de vigilance particulier : une visite peut déclencher une tâche en retard; envisager un cron système pour les exigences horaires strictes. Les opérations qui modifient des données nécessitent permissions adéquates, sauvegarde si besoin et vérification après exécution.

À ne pas confondre

Le nom du hook identifie le traitement; l'événement représente une planification enregistrée, tandis qu'un cron Linux constitue un ordonnanceur externe. Cette distinction évite d'attribuer à « WP-Cron » des responsabilités qui relèvent d'un autre mécanisme WordPress.

Diagnostic avancé

Lorsque le comportement ne correspond pas aux attentes, contrôler en priorité : une visite peut déclencher une tâche en retard; envisager un cron système pour les exigences horaires strictes. Examiner ensuite les paramètres d'entrée, les éventuels retours d'erreur et les effets observables sur la cible exacte.

Choix d’architecture et déploiement

Isoler le travail dans une callback idempotente, vérifier que l'événement n'a pas déjà été programmé, le retirer à la désactivation si le plugin en est propriétaire et mesurer les durées réelles. Sur un VPS à faible trafic, une tâche système peut appeler le planificateur WordPress à intervalles stables. Pour le scénario retenu, documenter aussi les conditions d'installation, les dépendances de version et une manière réversible de corriger une erreur.

Références documentaires

Bouton retour en haut de la page