Le cauchemar qu’est wp-cron.php

Un des principaux griefs que j’ai avec WordPress est l’implémentation par défaut de wp-cron.php. Si vous êtes familier avec la façon dont WordPress utilise wp-cron.php par défaut, vous pouvez passer directement à la section suivante de cet article.

Le fichier wp-cron.php est la partie de WordPress qui gère les événements planifiés dans un site WordPress. Tout ce qui a trait à la programmation des articles ou des publications et vraiment tout ce qui est orienté date/heure est régi par le fichier wp-cron.php.

Pour que wp-cron.php fonctionne correctement, il doit être exécuté fréquemment, mais pas plus d’une fois par minute. Cependant, le comportement par défaut ne vous oblige pas à configurer une véritable tâche cron au niveau du système sur votre serveur. Au lieu de cela, il utilise une méthode de ferroutage pour chaque requête entrante. Lorsqu’une requête arrive sur le site, WordPress va générer une requête supplémentaire de sa part vers le fichier wp-cron.php via HTTP(S). Cela semble assez inoffensif, non ?

Pourquoi le comportement par défaut de wp-cron.php est-il un cauchemar ?

La méthode par défaut fonctionne parfaitement bien sur un petit site avec très peu de visiteurs par heure. Cependant, lorsqu’elle est mise en œuvre sur un site moyen ou plus grand ou même un site qui est scanné par des bots (ce qui est très courant de nos jours), cela signifie que vous obtenez deux fois le pli quel que soit le trafic que vous traitez actuellement. Cela devient une attaque DDoS rudimentaire contre vous-même. Cela est dû au fait que le cron est exécuté plusieurs fois par minute à l’aide d’une requête HTTP. La requête HTTP génère des frais généraux supplémentaires car elle doit générer, négocier et établir la connexion sur un socket réseau. Elle a même un impact sur la capacité effective de votre serveur web sous-jacent. Cette solution ne s’en sort pas bien dans la plupart des situations, et honnêtement, elle devrait être supprimée comme comportement par défaut en raison de sa propension à être abusée ou transformée en vecteur d’attaque sur un serveur juste à partir du trafic régulier.

Bien, quelles sont les alternatives ?

La seule véritable alternative et la bien meilleure solution est de configurer un cronjob système régulier qui exécute le script wp-cron.php directement via PHP toutes les minutes. Cela garantit que toute tâche planifiée est effectivement exécutée à l’heure prévue. Cela ne doit pas non plus se faire via une requête HTTP mais une exécution directe de PHP pour éviter d’entraver la capacité du serveur web ou de générer une surcharge mémoire supplémentaire sur la couche réseau.

Comment désactiver le comportement par défaut de wp-cron.php ?

C’est assez universel et simple à faire. Vous devez mettre à jour votre fichier wp-cronfig.php pour inclure le paramètre suivant :

define('DISABLE_WP_CRON', true);

• Vous pouvez généralement trouver votre fichier wp-config.php dans le répertoire public_html de votre site.
• Ce nouveau paramètre doit être mis dans le fichier juste après la ligne de la base de données DB_COLLATE qui ressemble à ce qui suit

define('DB_COLLATE', '');

Comment puis-je configurer une tâche cron système ?

C’est simple dans cPanel, en supposant que votre hébergeur a activé la fonction de tâche cron sur votre compte. La documentation sur les tâches cron de cPanel entre dans les détails, mais essentiellement, vous faites :

1. Connectez-vous à cPanel pour votre domaine : yourdomain.tld/cpanel
2. Entrez « cron » dans la boîte de recherche rapide située en haut de la page.
3. Cliquez sur l’icône « Tâches cron » qui apparaît.

• Si elle n’apparaît pas, votre compte n’a pas la fonction Cron Jobs activée et vous devrez parler à votre fournisseur d’hébergement pour qu’il vous aide à configurer le cron ou à passer à un forfait qui inclut la fonction Cron Jobs.

1. Prêtez attention à la page Cron Jobs, elle vous fournira l’emplacement exact de votre binaire PHP. Vous devrez copier ce chemin dans la boîte de commande en bas de la page et modifier le fichier exécuté par PHP pour qu’il soit votre fichier /home/username/public_html/wp-cron.php à la place. En utilisant le chemin complet.
2. Sélectionnez la première entrée (« * ») pour chaque paramètre. Cela exécutera le fichier wp-cron.php toutes les minutes.
3. Cliquez sur ce bouton d’ajout de cron et vous avez terminé.

Pourquoi êtes-vous si sévère à l’égard de cette pratique, elle semble raisonnable et facile à corriger ?

Je crois que c’est aux ingénieurs logiciels qui développent notre monde numérique de s’imprégner d’un sens des responsabilités pour leurs produits. WordPress est omniprésent de nos jours et avec les logiciels d’installation automatique, comme Softaculous, WordPress est installé sur une très grande majorité de sites. Ils sont installés avec le comportement par défaut activé, ce qui est essentiellement un vecteur d’attaque sur n’importe quel serveur. Maintenant que le secteur de l’hébergement est si présent dans nos vies, de nombreuses personnes ont des sites WordPress et ne connaissent pas ce problème jusqu’à ce qu’il paralyse leur site. L’intégration par défaut est cruellement inadéquate et devrait être supprimée. Aujourd’hui, sur un seul serveur, j’ai trouvé plus de 500 installations différentes de WordPress et j’ai vu un bot frapper chaque site sur le serveur. Chacun de ces sites est soudainement devenu un passif pour la stabilité du serveur.

Je réalise que ce problème est traité au cas par cas. Cependant, avec autant d’installations dans le monde, il serait mieux traité par WordPress plutôt que par chaque hébergeur qui doit mettre en place des conditions spéciales sur son serveur pour se protéger du trou que ce logiciel génère. Le coût de la suppression de ce comportement et de l’obligation pour les propriétaires de sites de générer un cron système devrait être basique et un avis placé dans l’interface d’administration de WordPress indiquant que les tâches programmées ne seront pas exécutées tant qu’un travail cron système n’aura pas été créé correctement. C’est dans mes compétences de programmation, donc je sais que c’est bien dans les leurs.

WordPress vise la facilité d’utilisation, donc leurs consommateurs cibles sont ceux qui savent généralement peu de choses sur les caveats d’hébergement. Je crois que la responsabilité ici incombe entièrement à WordPress pour réparer et ils ont pris la position contre cela. En attendant, les administrateurs système du secteur de l’hébergement doivent souffrir de cette terrible « fonctionnalité » lorsqu’ils examinent des serveurs qui ont échappé à tout contrôle en raison d’un bot fonctionnant sur une installation WordPress par défaut.