On dirait que WordPress déclenche inutilement WP CRON à chaque chargement de page. Je pense qu'au lieu de l'exécuter à chaque visite, pourquoi ne pas simplement le planifier pour qu'il s'exécute toutes les 5 minutes via le serveur? Je pourrais simplement déclencher wp-cron.php toutes les cinq minutes et obtenir le résultat souhaité?
Y a-t-il un inconvénient à cela?
Réponses:
Il n'y a aucun inconvénient à exécuter WP CRON à l'aide des tâches cron du serveur. En fait, c'est la pratique recommandée.
Selon le document officiel de développement du plugin WordPress :
WP-Cron ne s'exécute pas en continu, ce qui peut être un problème s'il existe des tâches critiques qui doivent s'exécuter à temps. Il existe une solution simple à cela. Configurez simplement le planificateur de tâches de votre système pour qu'il s'exécute aux intervalles que vous désirez (ou à l'heure précise nécessaire).
Pour ce faire, vous devez d'abord désactiver le comportement cron par défaut dans wp-config.php:
define('DISABLE_WP_CRON', true);Ensuite, planifiez à wp-cron.phppartir de votre serveur. Pour Linux, cela signifie:
crontab -eCependant, au lieu de l'exécuter en ligne de commande (CLI), exécutez-le en tant que requête HTTP. Pour cela, vous pouvez utiliser wget:
*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronWordPress charge tous les fichiers de base, plugins, etc. requis wp-cron.phpavec le CODE suivant:
if ( !defined('ABSPATH') ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . '/wp-load.php' );
}Alors ne vous inquiétez pas si WordPress ne charge pas de fonctionnalités importantes.
define('DISABLE_WP_CRON', true);désactive uniquement cette partie du processus cron, puis appeler le script cron avec du code comme: */5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronsur le serveur s'assure que les tâches cron sont exécutées. Tout plugin de planification ne connaîtra même pas la différence.
Il y a quelques inconvénients: Premièrement, lors de l'utilisation de wp-cron.php en tant que cli, des choses telles que les variables $ _SERVER ne sont pas définies. Les utilisateurs surmontent cette limitation en utilisant à la place une requête curl vers wp-cron.php.
Deuxièmement, parce que WP lui-même n'est pas chargé avec wp-cron.php; si vous utilisez un plugin de messagerie SMTP, celui-ci ne sera pas chargé lors de l'appel à wp-cron. Encore une fois, l'utilisation d'un appel curl remplace ce problème. Curl semble être la méthode la plus utilisée.
Pourtant; Je préfère utiliser wp-cli après avoir défini les paramètres de messagerie dans postfix et (pour nginx) php-fpm config correctement et défini un crontab tel que
*/5 * * * * wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1(Répertoriez tous les crons avec des champs spécifiques au format csv - hook étant le nom du cron, le prochain cycle relatif est le temps. Supprimez ceux montrant 'maintenant' comme le prochain cycle (ceux qui sont dus maintenant) en utilisant AWK, passez cette liste à xargs pour faire appel wp cron event run $HOOKà chaque cron.) L'utilisation de wp-cli charge correctement WordPress (je choisis de sauter les plugins lors de la liste des crons, car les erreurs de code et les avertissements php vont bousiller la sortie scriptée; mais pas de les ignorer lors de l'exécution du cron avec xargs, comme le cron peut nécessiter le chargement des plugins)
J'espère que cela vous donne quelques conseils sur ce qu'il faut rechercher.
Il y a plusieurs raisons de ne pas désactiver le wp-cron. En fait, il est presque impossible de trouver un cas d'utilisation pour ce faire. Cela ne ralentit pas votre site et il est utilisé pour des choses que vous ne connaissez peut-être pas.
De nombreux plugins utilisent le WP-Cron pour planifier des choses. Ils peuvent devenir confus si vous désactivez le planificateur.
Il y a une prolifération de tutoriels sur ce sujet car il est déroutant et parce que cela ne fait pas grand-chose à votre site lorsque vous le désactivez. Ce qu'il va faire, c'est causer un mal de tête au développeur qui doit résoudre le mystérieux problème qu'il crée en six mois.
De plus, le WP Heartbeat se déclenche toutes les 15 secondes dans la zone d'administration, résolvant ce problème pour 99% des personnes qui pensent l'avoir.
Je n'ai pas encore trouvé de véritable inconvénient au déchargement de wp-cron vers un service externe. Faire cela depuis de nombreuses années maintenant.
Surtout dans le monde d'aujourd'hui où vous pouvez exécuter des applications en tant que microservices.
J'utilise des conteneurs Docker séparés pour chaque composant WordPress - php, web, db, crontab, redis, etc.). Ayant crontab comme conteneur séparé, appelant wp-cron via http en utilisant le réseau local, ne fonctionnant que lorsque j'en ai besoin.
Cela réduit le stress sur les nœuds principaux et améliore la sécurité en ayant une surface d'attaque plus petite.
Si le développeur ne peut pas comprendre comment faire des choses sans avoir à appeler wp-cron à chaque chargement de page, diable, cela parle simplement d'inexpérience en son nom. "Laissant ça tranquille", parce que vous ne comprenez pas comment les choses fonctionnent n'est pas une bonne raison de le garder.
wget http://YOUR_SITE_URL/wp-cron.phpsans l'ajout de?doing_wp_cronSo est-elle meilleure que l'autre? Que fait l'ajout de?doing_wp_cronce que la non-version ne fait pas?