Aller au contenu

Corriger « Le lien que vous avez suivi a expiré » dans WordPress sur cPanel

Apprenez à corriger l'erreur WordPress « Le lien que vous avez suivi a expiré » (The link you followed has expired) sur un hébergement cPanel. Vous confirmerez quelle limite PHP a bloqué votre téléversement, relèverez post_max_size et upload_max_filesize au bon endroit pour votre gestionnaire PHP, puis installerez votre fichier ZIP.

Ce guide aide les propriétaires et administrateurs de sites WordPress sur un hébergement cPanel à corriger l’erreur « Le lien que vous avez suivi a expiré. » (en anglais, “The link you followed has expired.”). Elle apparaît en général juste après le téléversement d’un thème, d’une extension (plugin) ou d’un gros fichier média, et rien ne s’installe. Le plus souvent, le fichier dépasse la limite post_max_size de PHP, alors PHP jette tout le téléversement avant que WordPress puisse le lire. La solution consiste à comparer la taille du fichier aux limites PHP du compte, puis à relever post_max_size et upload_max_filesize dans l’éditeur MultiPHP INI de cPanel. À la fin, le téléversement passe et WordPress affiche le nouveau thème, la nouvelle extension ou le nouveau fichier.

Ce que vous allez accomplir

  • Comprendre pourquoi un gros téléversement donne un message de « lien expiré » plutôt qu’une erreur de taille.
  • Lire les vraies limites PHP de votre site, et non celles que montre la ligne de commande.
  • Relever post_max_size et upload_max_filesize avec des valeurs fondées sur une règle claire.
  • Choisir le bon fichier de réglages pour votre gestionnaire PHP, et éviter la modification .htaccess qui fait tomber un site en erreur 500.
  • Installer un gros ZIP autrement quand vous ne pouvez pas, ou ne devriez pas, relever les limites.

Prérequis

Il vous faut un compte administrateur WordPress et un accès au compte cPanel qui héberge le site. Un accès SSH aide pour les vérifications avec WP-CLI (l’outil WordPress en ligne de commande), mais vous pouvez faire chaque correctif à partir de cPanel seulement.

Les étapes supposent une version récente de cPanel avec EasyApache 4, qui installe des versions de PHP nommées ea-php81, ea-php82, etc. Chaque domaine peut rouler une version différente, alors notez celle de votre site. Vous la voyez dans cPanel sous Software > MultiPHP Manager.

Il est aussi utile de connaître votre gestionnaire PHP (handler). C’est la façon dont le serveur Web exécute PHP. Les plus courants sur cPanel sont PHP-FPM (un groupe séparé de processus PHP), LSAPI sur LiteSpeed ou CloudLinux, et l’ancien DSO (PHP chargé à l’intérieur d’Apache). Votre hébergeur peut vous dire lequel sert votre domaine. Sur un serveur que vous gérez vous-même, WHM l’affiche sous MultiPHP Manager.

Comment ça fonctionne

Quand vous téléversez un ZIP à partir de Extensions > Ajouter > Téléverser une extension, votre navigateur envoie une seule grosse requête POST. Une requête POST est la façon dont un navigateur envoie les données d’un formulaire au serveur. La requête contient le fichier et quelques petits champs de formulaire. L’un de ces champs est un nonce, un jeton de sécurité à usage unique que WordPress ajoute à chaque formulaire d’administration pour prouver que la requête vient bien de vous.

La requête passe par plusieurs vérifications de taille, comme le montre le schéma.

Chemin d'une requête de téléversement WordPress sur cPanel. Le navigateur envoie le ZIP. La limite de corps du serveur Web peut l'arrêter avec une erreur 413. Si le corps dépasse post_max_size de PHP, PHP le jette et $_POST et $_FILES arrivent vides. Si seul le fichier dépasse upload_max_filesize, WordPress nomme cette limite. La vérification du nonce WordPress échoue ensuite quand le nonce est absent ou trop vieux et affiche Le lien que vous avez suivi a expiré. Si tout passe, WordPress installe le ZIP.

L’étape clé est post_max_size. Quand le corps complet de la requête dépasse cette valeur, PHP le laisse tomber en entier. WordPress reçoit alors un formulaire vide, sans fichier et sans nonce. Sa vérification de sécurité, check_admin_referer(), ne trouve aucun nonce valide et s’arrête avec « Le lien que vous avez suivi a expiré. ». Le message parle d’un lien expiré parce que WordPress ne peut pas distinguer un nonce absent d’un nonce trop vieux.

Les autres limites se comportent autrement, ce qui aide à trouver la cause :

  • Si seul le fichier dépasse upload_max_filesize mais que le corps tient dans post_max_size, le nonce survit. WordPress affiche alors un message clair indiquant que le fichier dépasse la directive upload_max_filesize.
  • Si la limite du serveur Web est plus basse que les deux, vous obtenez une page HTTP 413 « Request Entity Too Large » et WordPress ne s’exécute jamais. LimitRequestBody d’Apache, ModSecurity (un pare-feu d’applications Web) et la taille maximale de corps de requête de LiteSpeed peuvent tous provoquer ce résultat.
  • Un nonce peut aussi expirer pour vrai. Les nonces WordPress restent valides de 12 à 24 heures, alors un onglet resté ouvert toute la nuit peut échouer de la même façon avec un tout petit fichier.

Étapes

1. Vérifiez la taille du fichier à téléverser. Sur votre ordinateur, regardez les propriétés du fichier, ou lancez cette commande dans un terminal.

ls -lh my-theme.zip

La colonne de taille affiche quelque chose comme 87M. Notez-la. La requête de téléversement est un peu plus grosse que le fichier, parce que le navigateur ajoute des champs de formulaire et des séparateurs autour.

2. Lisez les limites que WordPress voit. Dans l’administration WordPress, ouvrez Médias > Ajouter. Sous la zone de téléversement, WordPress affiche la taille de fichier maximale pour le téléversement, par exemple 64 Mo. WordPress calcule cette valeur comme la plus petite entre upload_max_filesize et post_max_size.

Pour voir chaque valeur, ouvrez Outils > Santé du site > Infos et dépliez la section Serveur. Cherchez ces lignes (WordPress peut les afficher en anglais ou en français selon la version).

Upload max filesize   64M
PHP post max size     64M
PHP max input time    60
PHP time limit        30

Si votre fichier de l’étape 1 dépasse la taille maximale de POST de PHP, vous avez trouvé la cause. Passez à l’étape 4. Si le fichier est plus petit, allez à la section Dépannage, parce qu’une autre couche est en cause.

3. Facultatif : confirmez en ligne de commande. En SSH, WP-CLI peut afficher une valeur.

wp eval 'echo ini_get("post_max_size"), PHP_EOL;'

La commande affiche une valeur comme 64M. Prenez ce résultat avec prudence. WP-CLI exécute PHP en ligne de commande, et ce mode ne lit pas le fichier .user.ini qu’utilise votre site Web. Le chiffre peut donc différer de celui qu’applique le serveur Web. C’est la même chose pour php -i. Si vous l’utilisez, appelez le binaire de la version PHP de votre site, pour qu’au moins la version corresponde.

/opt/cpanel/ea-php82/root/usr/bin/php -i | grep -E 'post_max_size|upload_max_filesize'

La sortie affiche deux colonnes, la valeur locale et la valeur maîtresse. Quand elle contredit la Santé du site, fiez-vous à la Santé du site, parce qu’elle s’exécute à l’intérieur du site Web.

4. Choisissez les nouvelles valeurs. Suivez cette règle, pour que les valeurs conviennent à la tâche sans être démesurées.

  • Réglez upload_max_filesize sur le plus gros fichier prévu, arrondi vers le haut. Pour un thème de 87 Mo, utilisez 128M.
  • Réglez post_max_size environ 25 % plus haut que upload_max_filesize. Pour 128M, utilisez 160M. Cette valeur ne doit jamais être plus basse que upload_max_filesize.
  • Pour les connexions lentes, réglez max_execution_time et max_input_time à 300 (secondes). PHP a ainsi le temps de recevoir et de décompresser le fichier.

Vous n’avez pas besoin de relever memory_limit pour ce problème. PHP écrit les fichiers téléversés dans un dossier temporaire sur le disque, pas en mémoire.

5. Modifiez les valeurs dans l’éditeur MultiPHP INI. Dans cPanel, ouvrez Software > MultiPHP INI Editor et restez dans l’onglet Basic Mode. Dans le menu d’emplacement, choisissez le domaine qui fait rouler WordPress. Réglez upload_max_filesize, post_max_size, max_execution_time et max_input_time selon l’étape 4, puis cliquez sur Apply.

cPanel écrit les valeurs dans les fichiers de réglages que votre gestionnaire PHP lit dans ce dossier. Avec PHP-FPM et LSAPI, cela comprend un fichier .user.ini. Par défaut, PHP relit .user.ini toutes les 5 minutes (le réglage user_ini.cache_ttl), alors attendez jusqu’à 5 minutes avant de tester.

6. Si vous modifiez les fichiers à la main, prenez le bon. Certaines équipes gardent leurs réglages dans des fichiers qu’elles gèrent elles-mêmes. Voici le rôle de chacun.

  • .user.ini à la racine du site fonctionne avec PHP-FPM, LSAPI et les autres gestionnaires FastCGI. Utilisez des lignes simples.
upload_max_filesize = 128M
post_max_size = 160M
max_execution_time = 300
max_input_time = 300
  • php.ini dans le même dossier est aussi lu par certains gestionnaires. L’éditeur MultiPHP INI le gère pour vous, alors évitez de modifier les deux à la main.
  • Les lignes .htaccess comme php_value post_max_size 160M fonctionnent seulement quand PHP s’exécute dans le serveur Web, comme avec DSO (mod_php) ou LiteSpeed. Avec PHP-FPM, Apache ne connaît pas la directive php_value et tout le site renvoie « 500 Internal Server Error ». Si vous avez ajouté une telle ligne et que le site est tombé, retirez-la d’abord.

7. Refaites le téléversement. Rechargez Médias > Ajouter pour que la page reçoive un nouveau nonce. Vérifiez que la taille maximale affiche votre nouvelle valeur. Téléversez ensuite le ZIP de nouveau à partir de Extensions > Ajouter ou de Apparence > Thèmes > Ajouter.

Valider que ça fonctionne

Confirmez chaque partie du correctif.

  1. Outils > Santé du site > Infos > Serveur affiche les nouvelles valeurs pour la taille maximale de téléversement et la taille maximale de POST.
  2. Médias > Ajouter affiche une taille de fichier maximale de 128 Mo (ou la valeur choisie).
  3. Le téléversement se termine par un message de réussite, et l’élément apparaît dans la liste des extensions ou des thèmes.
  4. Le journal d’erreurs PHP du compte n’a pas de nouvelle ligne comme « POST Content-Length of 91226112 bytes exceeds the limit ». Sur cPanel, ce journal est en général le fichier error_log dans le dossier du site. Vérifiez-le en SSH.
tail -n 20 ~/public_html/error_log

Aucune nouvelle ligne « exceeds the limit » après votre test signifie que PHP a accepté la requête complète. Si vous en voyez encore une, PHP ne lit pas votre nouvelle valeur. Revérifiez l’emplacement choisi à l’étape 5.

Dépannage

Le site affiche une page 413 « Request Entity Too Large ». Le serveur Web a arrêté la requête avant que PHP la voie. Sur Apache, c’est souvent LimitRequestBody. Avec ModSecurity, la règle SecRequestBodyLimit fixe le plafond. Sur LiteSpeed, le serveur a sa propre taille maximale de corps de requête. Ce sont des réglages au niveau du serveur, dans WHM ou dans la console du serveur Web, alors demandez à votre hébergeur ou à l’administrateur du serveur de les relever.

Les valeurs ne changent pas dans la Santé du site. Avec PHP-FPM, WHM peut fixer une valeur pour tout le pool avec php_admin_value. Un pool est le groupe de processus PHP qui sert un domaine. Les valeurs fixées ainsi ont priorité sur .user.ini, et les utilisateurs ne peuvent pas les changer. Un administrateur de serveur peut les revoir dans WHM sous MultiPHP Manager, dans les réglages PHP-FPM du domaine. Assurez-vous aussi d’avoir modifié le dossier du bon domaine et d’avoir attendu les 5 minutes de cache.

Les petits téléversements échouent aussi, ou l’erreur apparaît en enregistrant un formulaire. Le nonce a vraiment expiré. Cela arrive quand un onglet reste ouvert plus de 12 à 24 heures, ou après une déconnexion dans un autre onglet. Rechargez la page et réessayez. Si le problème revient, vérifiez votre cache. Un cache de pages ou un CDN (réseau de diffusion de contenu) qui garde les pages d’administration ou les pages des utilisateurs connectés sert de vieux nonces. Excluez /wp-admin/ et les visiteurs connectés du cache.

Les gros téléversements échouent seulement sur des connexions lentes. L’envoi peut durer plus longtemps que ce que permettent max_input_time ou les délais du serveur Web. Relevez max_input_time et max_execution_time à 300. Pour les très gros fichiers, utilisez plutôt une des méthodes ci-dessous.

Les téléversements de médias échouent avec un autre message. Quand des images échouent avec un simple « HTTP error », la cause est souvent le traitement d’image, pas la taille. Notre guide sur l’erreur HTTP au téléversement dans la médiathèque WordPress couvre ces cas.

Quand cette approche ne convient pas

Relever les limites n’est pas toujours le meilleur choix. Si vous devez placer un gros fichier sur le serveur une seule fois, vous pouvez éviter le téléversement par le navigateur.

Avec WP-CLI en SSH, installez un ZIP déjà copié sur le serveur.

wp plugin install ./my-plugin.zip --activate
wp theme install ./my-theme.zip

WP-CLI affiche “Plugin installed successfully.” et, avec --activate, “Plugin ‘my-plugin’ activated.” Ces commandes ne passent pas par les limites de téléversement Web.

Sans SSH, téléversez le ZIP par SFTP (transfert de fichiers sécurisé) ou avec le Gestionnaire de fichiers de cPanel. Placez-le dans wp-content/plugins/ ou wp-content/themes/, décompressez-le à cet endroit et supprimez le ZIP. Activez-le ensuite à partir de l’administration WordPress.

Gardez des limites modestes sur les serveurs partagés. Des valeurs très hautes laissent un seul site occuper les processus PHP avec d’énormes requêtes. Si vous gérez le serveur et que plusieurs comptes ont besoin de plus gros téléversements, lisez notre guide pour relever upload_max_filesize sur cPanel sans nuire aux autres comptes. Le guide d’administration avancée de WordPress et la documentation de cPanel (en anglais) décrivent ces outils plus en détail.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.