On dirait que WordPress déclenche inutilement WP CRON à chaque chargement de page. Je pense qu'au lieu de le lancer à chaque visite, pourquoi ne pas simplement le programmer toutes les 5 minutes via un serveur? Je pourrais simplement déclencher wp-cron.php toutes les cinq minutes et obtenir le résultat souhaité?
Y a-t-il des inconvénients à cela?
Il n'y a aucun inconvénient à exécuter WP CRON à l'aide des tâches périodiques du serveur. En fait, c'est la pratique recommandée.
Selon Document officiel de développement du plugin WordPress :
WP-Cron ne s'exécute pas en permanence, ce qui peut poser problème si des tâches critiques doivent être exécutées à temps. Il existe une solution facile pour cela. Configurez simplement le planificateur de tâches de votre système pour qu’il s’exécute selon les intervalles souhaités (ou à l’heure spécifique requise).
Pour ce faire, vous devez d’abord désactiver le comportement par défaut de cron dans wp-config.php
:
define('DISABLE_WP_CRON', true);
Ensuite, programmez wp-cron.php
à partir de votre serveur. Pour Linux, cela signifie:
crontab -e
Toutefois, au lieu de l'exécuter dans la 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_cron
WordPress charge tous les fichiers de base, plugins, etc. requis dans wp-cron.php
avec le CODE suivant:
if ( !defined('ABSPATH') ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . '/wp-load.php' );
}
Alors, ne vous inquiétez pas du fait que WordPress ne charge pas les fonctionnalités importantes.
Il y a quelques inconvénients: Tout d'abord, lorsque vous utilisez wp-cron.php en tant qu'interface client, les variables telles que les variables $ _SERVER ne sont pas définies. Les gens surmontent cette limitation en utilisant plutôt une requête curl à wp-cron.php.
Deuxièmement, parce que WP lui-même n'est pas chargé avec wp-cron.php; Si vous utilisez un plug-in de messagerie SMTP, il ne sera pas chargé lors de l'appel de wp-cron. Encore une fois, l’utilisation d’un appel curl annule ce problème. Le curl semble être la méthode la plus fréquemment utilisée.
Toutefois; Je préfère utiliser wp-cli après avoir défini correctement les paramètres de messagerie dans postfix et (pour nginx) la configuration de php-fpm et avoir défini une crontab telle 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, la prochaine exécution relative est le temps. Supprimez ceux qui affichent 'maintenant' comme prochaine exécution (ceux dus maintenant) utilisant AWK, transmettez cette liste à xargs à appelez wp cron event run $HOOK
sur chaque cron.) Utiliser wp-cli charge correctement WordPress (je choisis d’ignorer les plugins lors de la liste des crons, car le code erros et les avertissements php bousilleront la sortie scriptée; car le cron peut avoir besoin du chargement des plugins)
J'espère que cela vous donne des indications sur ce qu'il faut rechercher.