La constante _HTML_BG_CRON_FORCE répond au problème relevé sur certains serveurs dont le firewall est réglé pour DROP silencieusement toute requête http sortante : fsockopen attend alors 30s pour lancer la requête à chaque hit avant de rendre la main. cURL lui n’attend pas mais ne sait pas que sa requête échoue. Résultat le CRON ne tourne jamais et le site a un temps de réponse catastrophique…
Si vous savez que vous êtes sur une telle configuration (et que vous ne pouvez pas la changer) il est possible de définir la valeur de la constante _HTML_BG_CRON_FORCE dans votre fichier config/mes_options.php (voir l’article qui lui est consacré).
Exemple :
// pour réduire fortement les temps de réponse du site,
// ne pas lancer le cron par fsockopen/cURL
// car la configuration du serveur ne le permet pas.
define('_HTML_BG_CRON_FORCE', TRUE);
Ce réglage permet aussi de rétablir le fonctionnement des tâches CRON dans le cas où votre site est protégé par un couple de fichiers .htaccess / .htpasswd (voir la constante _DIRECT_CRON_FORCE).
D’un point de vue technique, la définition de cette constante se traduit par l’ajout à la fin de chaque page publique d’un script javascript qui lance une requête asynchrone sur l’action qui traite les tâches CRON. L’utilisation de javascript fait que cela sera efficace même sur un site derrière un cache du type Varnish. Et le fonctionnement asynchrone permet de servir la page sans ralentissement. Si toutefois javascript n’est pas activé sur le navigateur, c’est l’insertion une image qui appelle le CRON et dans ce cas, l’internaute doit attendre.
Voir aussi : la constante _HTML_BG_CRON_INHIB.