Cron, Action Scheduler et staging

Module 7: Visibilité et hébergement · Temps de lecture : 10 minutes

Objectif pédagogique : À l’issue de cette leçon, vous saurez expliquer comment WooCommerce exécute des tâches en arrière-plan, contrôler les actions planifiées et les rétablir en cas de problème. Vous saurez aussi configurer un environnement de préproduction (staging) pour une boutique sans mettre en danger de vrais clients, de vrais paiements ou de vraies commandes.

Notions clés : WP-Cron, vraie tâche cron, DISABLE_WP_CRON, Action Scheduler, actions planifiées, en attente, terminé, échec, nettoyage, staging pour une boutique, mode test du prestataire de paiement, e-mails désactivés, webhooks, connexions, ne pas restaurer la base de données sur la production

Ce qui se passe quand personne ne regarde

Une boutique effectue beaucoup de travail qui ne dépend pas directement d’un clic d’un visiteur :

• annuler les commandes impayées lorsque le délai de conservation du stock est écoulé (leçon 3.4) ;
• envoyer des e-mails après un changement d’état, ainsi que des webhooks vers les connexions ;
• mettre à jour les rapports et les statistiques dans l’administration ;
• nettoyer les sessions expirées et les données temporaires ;
• appliquer les durées de conservation définies dans Comptes et confidentialité (leçon 2.3) ;
• pour les abonnements ou les connexions comptables : prélever les paiements et transmettre les données.

Pour cela, WordPress utilise WP-Cron et WooCommerce y ajoute Action Scheduler. S’ils ne fonctionnent pas correctement, vous ne le remarquez pas tout de suite. Vous le remarquez quand des commandes impayées continuent de bloquer du stock, que les rapports restent vides ou qu’une connexion accuse plusieurs jours de retard.

WP-Cron et vraie tâche cron

Le fonctionnement de WP-Cron et la raison pour laquelle une vraie tâche cron est préférable sont expliqués dans la formation WordPress, leçon 6.3 : WP-Cron s’exécute lors des visites, pas selon une horloge. C’est peu fiable avec peu de visiteurs et pesant avec beaucoup de visiteurs. La solution : DISABLE_WP_CRON dans wp-config.php et une tâche cron dans votre panneau d’hébergement qui exécute wp-cron.php toutes les quelques minutes.

Pour une boutique, ce n’est pas une optimisation mais une nécessité :

• La nuit, quand il y a peu de visites, les commandes impayées doivent tout de même être annulées à temps.
• Pendant une promotion très fréquentée, vous ne voulez surtout pas qu’une lourde tâche d’arrière-plan s’exécute sur la requête d’un client qui veut payer.

Chez WebOké, vous créez une telle tâche dans DirectAdmin, sous Tâches CRON (DA 15.1, KB 48), avec /usr/local/bin/php comme chemin vers PHP ; chez d’autres hébergeurs, cela fonctionne de manière similaire dans leur écran cron. Choisissez pour une boutique un intervalle d’une à cinq minutes plutôt que dix. Une tâche qui s’exécute chaque minute sans rien avoir à faire ne coûte presque rien.

Action Scheduler : la file d’attente de WooCommerce

Action Scheduler est une file d’attente pour les tâches d’arrière-plan, fournie avec WooCommerce et utilisée aussi par de nombreuses autres extensions (abonnements, connexions comptables, e-mail marketing). Chaque tâche est une action avec une heure et un état. La file est traitée via une tâche WP-Cron (action_scheduler_run_queue) ; ici aussi, sans cron fiable, la file prend du retard.

Vous voyez tout sous WooCommerce > État > Actions planifiées (Scheduled Actions). Il y a un onglet par état :

D’après le code source, Action Scheduler supprime par défaut les actions terminées et annulées au bout d’un mois, et les actions en échec au bout de trois mois. Si la table grossit malgré tout fortement, c’est probablement que de nombreuses actions échouent ou sont recréées sans cesse ; cherchez quelle extension les crée (la colonne Groupe et le nom du hook vous aident), au lieu de simplement vider la table.

Un exemple concret chez Theehuis Example : après un changement de mot de passe, la connexion avec le logiciel de comptabilité plaçait chaque commande dans la file comme action en échec. Au bout d’une semaine, il y avait 400 actions en échec et 60 factures manquaient (leçon 5.6). Une fois la connexion rétablie, l’administrateur a pu relancer les actions une par une avec Exécuter (Run).

Staging pour une boutique

Ce qu’est un staging, comment en créer un et comment le protéger (mot de passe, noindex) est expliqué dans la formation WordPress, leçon 8.3. Chez WebOké, cela se fait par clonage dans Installatron (DA 13.7, KB 232) et avec un répertoire protégé par mot de passe (DA 15.9) ; d’autres hébergeurs proposent des outils comparables. Pour une boutique, plusieurs points s’ajoutent, car une copie de boutique contient de vraies données clients et peut effectuer de vraies actions.

Juste après le clonage, avant de faire quoi que ce soit d’autre :

1. Prestataire de paiement en mode test, avec des clés de test. Un staging avec des clés de production peut recevoir de vrais paiements ou effectuer des remboursements.
2. E-mails désactivés ou redirigés. Sinon, une copie envoie des confirmations, des rappels et des e-mails de panier abandonné à de vrais clients. Utilisez une extension qui bloque tous les e-mails ou les envoie vers une seule adresse de test.
3. Connexions et webhooks désactivés. Comptabilité, synchronisation des stocks, étiquettes d’expédition, e-mail marketing : sinon, le staging enregistre des factures ou expédie des colis. Vérifiez aussi WooCommerce > Réglages > Avancé > Crochets Web et les clés API.
4. Passer en revue les actions planifiées. La file d’attente a été copiée aussi. Sinon, les actions en attente (un e-mail de rappel, un paiement d’abonnement) s’exécutent une seconde fois sur le staging.
5. Limiter les données personnelles. Si vous n’avez pas besoin de vraies données clients pour vos tests, supprimez-les ou anonymisez-les sur le staging. Un staging relève aussi du RGPD et est souvent moins bien sécurisé (leçon 5.5).

Et la règle la plus importante lors d’une restauration : ne restaurez jamais la base de données du staging sur une boutique en activité. Entre le clonage et la restauration, des commandes, des clients, des mouvements de stock et des paiements se sont ajoutés ; vous les perdriez. Refaites les modifications sur la production (vous savez maintenant qu’elles fonctionnent), ou synchronisez uniquement les fichiers. Si vous devez malgré tout passer par la base de données, faites-le uniquement avec la boutique en mode maintenance, juste après une sauvegarde récente, et avec un outil qui ignore les commandes et les clients.

Tester une mise à jour sur le staging

Un parcours type pour une mise à jour importante de WooCommerce ou d’une extension de paiement :

1. Créez un staging récent (clone de la production) et réglez les cinq points ci-dessus.
2. Faites la mise à jour sur le staging et lancez la mise à jour de la base de données si WooCommerce la demande.
3. Passez une commande test en mode test : paiement, échec, remboursement (leçon 4.5).
4. Vérifiez dans Actions planifiées et dans le journal d’erreurs s’il y a de nouvelles erreurs.
5. Mettez ensuite la production à jour à un moment calme, avec une sauvegarde juste avant (leçon 6.2).

Résumé

• WooCommerce effectue beaucoup de travail en arrière-plan ; celui-ci passe par WP-Cron et Action Scheduler.
• Pour une boutique, utilisez toujours une vraie tâche cron (toutes les une à cinq minutes) au lieu de WP-Cron déclenché par les visites.
• Contrôlez WooCommerce > État > Actions planifiées : de nombreuses actions en attente en retard ou en échec indiquent que le cron ou une connexion ne fonctionne pas.
• Sur le staging : prestataire de paiement en mode test, e-mails et connexions désactivés, actions planifiées passées en revue, données personnelles limitées.
• Ne restaurez jamais une base de données de staging sur une boutique en activité ; refaites les modifications sur la production.

Quiz

Exercice

Exercice A7.3 : Votre site de préproduction (staging) est-il protégé ? Il s’agit du même contrôle que l’exercice A8.3 de la formation WordPress. Vous avez d’abord besoin d’une preuve de propriété pour votre domaine (un enregistrement TXT _weboke-cursus.<domein> ou un fichier /.well-known/weboke-cursus-<code>.txt contenant le code que vous recevez). Saisissez ensuite l’adresse de votre boutique et l’adresse de votre staging (un hôte sous le même domaine). Le programme interroge la page d’accueil du staging, sans identifiants, ainsi que celle de la production. Vert si le staging demande un mot de passe (401), ou s’il a un noindex et utilise sa propre adresse (le point d’entrée REST pointe vers l’hôte de staging), tandis que la production n’a pas de noindex. Orange si le staging a bien un noindex mais pas de mot de passe, ou pas de certificat valide. Rouge si le staging est ouvert et indexable, s’il pointe encore vers l’adresse de la production, ou si la production a un noindex par erreur.

Questions pour vous-même (non corrigées) : le prestataire de paiement est-il en mode test sur votre staging ? Les e-mails sont-ils désactivés ou redirigés ? Les connexions et les webhooks sont-ils désactivés ? Combien d’actions en attente et en échec figurent actuellement dans Actions planifiées sur la production ?

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d’autres panneaux, cela fonctionne de manière similaire.

• Guide DirectAdmin 15.1: Tâches CRON : exécuter automatiquement des tâches
• Créer une tâche cron (et que faire si elle ne s'exécute pas)
• Créer un environnement de staging WordPress
• Guide DirectAdmin 13.7: Cloner et créer un environnement de test (staging)
• Guide DirectAdmin 15.9: Répertoires protégés par mot de passe
• Formation WordPress gratuite 8.3: Staging : tester en toute sécurité
• Formation WordPress gratuite 6.3: Images, PHP et autres gains de vitesse
• Action Scheduler (actionscheduler.org, en anglais) : https://actionscheduler.org/