Comment corriger l’erreur “Le lien que vous avez suivi a expiré” dans WordPress

L’erreur "The link you followed has expired" dans WordPress est déclenchée lorsqu’un téléchargement de fichier ou une soumission de formulaire dépasse une ou plusieurs limites d’exécution PHP — notamment upload_max_filesize, post_max_size, max_execution_time, ou memory_limit. WordPress ne peut pas récupérer correctement de ces rejets côté serveur, et affiche donc ce message générique au lieu d’une erreur PHP spécifique.

La correction nécessite d’augmenter ces valeurs de directives PHP via la couche de configuration exposée par votre environnement d’hébergement : php.ini, .htaccess, wp-config.php, ou une interface de panneau de contrôle. La méthode qui fonctionne dépend entièrement de votre niveau d’accès au serveur — accès SSH root, cPanel géré, ou environnement partagé verrouillé, chacun nécessite une approche différente.

Pourquoi cette erreur se produit réellement

Comprendre la cause profonde vous évite d’appliquer le mauvais correctif. Lorsque WordPress traite un téléchargement, le navigateur envoie une requête POST multipart à wp-admin/async-upload.php ou wp-admin/update.php. PHP évalue la requête par rapport à quatre limites indépendantes avant que WordPress n’exécute une seule ligne de code applicatif :

• upload_max_filesize — plafond absolu pour tout fichier téléchargé individuellement
• post_max_size — plafond pour l’ensemble du corps POST, qui doit être *supérieur* à upload_max_filesize
• max_execution_time — nombre maximum de secondes d’horloge murale pendant lesquelles un processus PHP peut s’exécuter
• memory_limit — RAM disponible pour le processus PHP ; le traitement d’images et l’installation de thèmes sont gourmands en mémoire

Si l’une de ces limites est dépassée, PHP termine silencieusement la requête. WordPress reçoit une réponse vide ou malformée et affiche "The link you followed has expired." L’erreur n’est pas un bug WordPress — c’est PHP qui applique la politique du serveur.

Déclencheurs courants en pratique :

• Installation d’un thème premium (souvent 5–30 MB) sur un hébergement partagé avec une limite de téléchargement par défaut de 2 MB
• Téléchargement d’un fichier CSV d’importation de produits WooCommerce
• Installation d’un bundle de plugin incluant des ressources groupées
• Restauration d’un site depuis une archive de sauvegarde via le tableau de bord WordPress
• Exécution d’un script d’importation de longue durée qui atteint le plafond de temps d’exécution

Tableau de référence rapide des directives PHP

Règle critique : post_max_size doit toujours être défini à une valeur supérieure à upload_max_filesize. Si vous définissez upload_max_filesize = 128M mais laissez post_max_size = 8M, les téléchargements échoueront quand même car la limite du corps POST est atteinte en premier.

Méthode 1 : Modifier php.ini (Recommandé pour les VPS et serveurs dédiés)

C’est la méthode la plus fiable et permanente. Sur un environnement VPS Hosting ou Serveur Dédié où vous disposez d’un accès root ou sudo, vous contrôlez directement la configuration PHP.

Localiser le fichier php.ini actif :

php --ini | grep "Loaded Configuration File"

Ou depuis un site WordPress, créez un fichier temporaire :

<?php phpinfo(); ?>

Recherchez la ligne Loaded Configuration File dans la sortie, puis supprimez le fichier immédiatement après.

Modifier les directives :

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Après avoir enregistré, redémarrez PHP-FPM ou Apache pour appliquer les modifications :

# For PHP-FPM (most common on modern stacks)
sudo systemctl restart php8.2-fpm

# For Apache with mod_php
sudo systemctl restart apache2

# For Nginx + PHP-FPM
sudo systemctl restart nginx php8.2-fpm

Vérifier que les nouvelles valeurs ont pris effet :

php -r "echo ini_get('upload_max_filesize');"

Cas particulier à connaître : Sur les serveurs exécutant plusieurs versions PHP (configuration courante sur cPanel), il existe un fichier php.ini distinct pour chaque version. Modifier le mauvais n’a aucun effet. Confirmez quelle version PHP WordPress utilise avant de modifier.

Méthode 2 : Utiliser .htaccess (Hébergement partagé Apache)

Si vous êtes sur un hébergement partagé sans accès direct à php.ini, et que votre serveur exécute Apache avec mod_php ou suPHP, vous pouvez remplacer les directives PHP par répertoire en utilisant .htaccess.

Accédez à votre répertoire racine WordPress via FTP, SFTP, ou le gestionnaire de fichiers de votre hébergement. Ouvrez .htaccess et ajoutez le bloc suivant :

<IfModule mod_php.c>
    php_value upload_max_filesize 128M
    php_value post_max_size 256M
    php_value max_execution_time 300
    php_value max_input_time 300
    php_value memory_limit 256M
</IfModule>

Enregistrez et téléchargez le fichier, puis testez votre téléchargement.

Mises en garde importantes :

• Cette méthode ne fonctionne pas sur les serveurs exécutant PHP-FPM, CGI, ou FastCGI. Sur ces stacks, les directives php_value dans .htaccess provoqueront une erreur 500 Internal Server Error car le module Apache gérant PHP n’est pas mod_php. Si vous voyez une erreur 500 après l’enregistrement, supprimez immédiatement ces lignes.
• Sur les serveurs Nginx, .htaccess est entièrement ignoré. Utilisez php.ini ou un fichier de remplacement utilisateur php.ini à la place.
• Certains hébergeurs gérés désactivent explicitement AllowOverride pour les directives PHP, rendant cette méthode inefficace même sur Apache.

Méthode 3 : Ajouter des directives à wp-config.php

Cette méthode utilise la fonction ini_set() de PHP pour remplacer les directives à l’exécution. Elle fonctionne quel que soit le type de serveur web, mais elle est soumise aux restrictions open_basedir et disable_functions de l’hébergeur — certains hébergeurs bloquent ini_set() pour des raisons de sécurité.

Ouvrez wp-config.php dans votre racine WordPress et ajoutez les lignes suivantes avant le commentaire /* That's all, stop editing! Happy publishing. */ :

@ini_set( 'upload_max_size',    '128M' );
@ini_set( 'post_max_size',      '256M' );
@ini_set( 'max_execution_time', '300'  );
@ini_set( 'max_input_time',     '300'  );
@ini_set( 'memory_limit',       '256M' );

Le @ supprime les erreurs si ini_set() est désactivé, évitant ainsi un écran blanc. Cependant, si l’hébergeur a verrouillé ces valeurs au niveau serveur en utilisant php_admin_value, les appels ini_set() sont silencieusement ignorés — les valeurs ne changeront pas.

Comment vérifier que cela a réellement fonctionné :

Installez le plugin gratuit Query Monitor et vérifiez l’onglet environnement PHP, ou ajoutez un appel temporaire phpinfo(). Si les valeurs affichent toujours les anciennes limites, ini_set() est remplacé à un niveau supérieur et vous devez utiliser une méthode différente.

Méthode 4 : Ajuster les paramètres PHP dans cPanel

Pour les environnements d’hébergement gérés via cPanel — y compris les VPS avec cPanel — vous pouvez modifier les limites PHP via l’interface graphique sans toucher aucun fichier.

Étapes :

1. Connectez-vous à cPanel.
2. Naviguez vers Logiciels et cliquez sur MultiPHP INI Editor.
3. Sélectionnez la racine du document de votre site WordPress dans le menu déroulant.
4. Localisez et mettez à jour les champs suivants :

• upload_max_filesize → 128M
• post_max_size → 256M
• max_execution_time → 300
• memory_limit → 256M

1. Cliquez sur Appliquer.

Alternativement, utilisez Select PHP Version (PHP Selector) si votre hébergeur utilise CloudLinux. Sous l’onglet Options, les mêmes directives sont disponibles sous forme de curseurs ou de champs de saisie.

Ce que cPanel fait réellement en coulisses : Il écrit un fichier .user.ini (pour PHP-FPM) ou modifie .htaccess (pour mod_php) dans votre racine de document. Si vous modifiez manuellement ces fichiers par la suite, vous risquez d’écraser les modifications de cPanel — soyez conscient de ce conflit.

Méthode 5 : Créer ou modifier un fichier .user.ini (Environnements PHP-FPM)

C’est la méthode que la plupart des tutoriels omettent, pourtant c’est l’approche correcte pour PHP-FPM — qui est le gestionnaire PHP par défaut sur pratiquement toutes les stacks d’hébergement modernes, y compris les environnements basés sur Nginx.

Créez un fichier nommé .user.ini dans votre répertoire racine WordPress avec le contenu suivant :

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Téléchargez-le dans le même répertoire que wp-config.php. PHP-FPM analyse périodiquement les fichiers .user.ini — le TTL du cache est contrôlé par user_ini.cache_ttl, qui est par défaut de 300 secondes (5 minutes). Les modifications ne sont pas instantanées. Si vous avez besoin d’un effet immédiat, redémarrez PHP-FPM.

sudo systemctl restart php8.2-fpm

Note de sécurité : Le fichier .user.ini ne doit pas être accessible via le web. Ajoutez ceci à votre .htaccess si vous êtes sur Apache :

<Files ".user.ini">
    Require all denied
</Files>

Sur Nginx, ajoutez un bloc location pour refuser l’accès :

location ~ /.user.ini {
    deny all;
}

Méthode 6 : Contacter votre hébergeur

Si aucune des méthodes ci-dessus ne produit de changement dans les valeurs PHP que vous avez vérifiées avec phpinfo() ou Query Monitor, l’hébergeur applique des limites au niveau du pool PHP-FPM ou via des directives php_admin_value dans la configuration du serveur — les deux ne pouvant pas être remplacés par un fichier accessible à l’utilisateur.

Dans ce cas, contactez le support et demandez des augmentations spécifiques. Fournissez les noms exacts des directives et les valeurs cibles. Si l’hébergeur refuse ou impose un plafond absolu qui ne répond pas à vos besoins, envisagez de migrer vers un plan VPS Hosting où vous contrôlez entièrement la configuration PHP.

Diagnostiquer quelle limite déclenche réellement l’erreur

Plutôt que de deviner, utilisez ces étapes de diagnostic avant d’appliquer un correctif :

Vérifier les limites PHP actuelles depuis la ligne de commande :

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL;
echo 'max_execution_time: ' . ini_get('max_execution_time') . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

Vérifier le journal d’erreurs PHP pour l’échec réel :

tail -n 50 /var/log/php/error.log
# or
tail -n 50 /var/log/apache2/error.log

Recherchez les lignes contenant Allowed memory size, Maximum execution time, ou POST Content-Length. Le message spécifique vous indique exactement quelle directive cibler.

Vérifiez la taille du fichier que vous téléchargez par rapport au upload_max_filesize actuel. Si le fichier fait 45 MB et que la limite est 64 MB, la limite de téléchargement n’est pas le problème — regardez plutôt post_max_size ou memory_limit.

Choisir la bonne méthode : Matrice de décision

Liste de contrôle technique clé avant de considérer le problème résolu

• post_max_size est défini plus haut que upload_max_filesize — c’est la mauvaise configuration la plus courante
• Les modifications ont été vérifiées avec phpinfo() ou php -r "echo ini_get(...)" — pas seulement supposées
• PHP-FPM a été redémarré si .user.ini ou php.ini a été modifié directement
• Le fichier .user.ini ou php.ini modifié correspond à la version PHP servant réellement le site WordPress
• memory_limit est au moins 256M si vous installez des thèmes volumineux ou effectuez des opérations intensives en images
• Le journal d’erreurs a été vérifié pour confirmer quelle limite spécifique a causé la terminaison
• Si vous êtes sur un plan Hébergement Web Partagé, le plafond absolu de l’hébergeur a été confirmé — certains fournisseurs limitent upload_max_filesize à 64M quels que soient les paramètres utilisateur
• Après avoir corrigé l’erreur de téléchargement, vérifiez que vos Certificats SSL sont valides si vous accédez à wp-admin via HTTPS, car les erreurs de contenu mixte ou de certificat peuvent produire des échecs de redirection superficiellement similaires

FAQ

Pourquoi l’erreur apparaît-elle même après avoir augmenté upload_max_filesize dans .htaccess ?

Le serveur exécute probablement PHP via FastCGI ou PHP-FPM plutôt que mod_php. La directive php_value dans .htaccess n’est traitée que par le gestionnaire mod_php d’Apache. Sur les stacks PHP-FPM, utilisez plutôt un fichier .user.ini dans le répertoire racine WordPress.

Quelle est la différence entre upload_max_filesize et post_max_size, et pourquoi les deux sont-ils importants ?

upload_max_filesize limite la taille de chaque fichier individuel dans un téléchargement multipart. post_max_size limite la taille totale du corps de la requête POST entière, qui inclut les données du fichier plus les champs de formulaire et les délimiteurs. Si post_max_size est inférieur à upload_max_filesize, la limite du corps POST est atteinte en premier et PHP rejette la requête entière avant que WordPress puisse évaluer la taille du fichier.

Mes appels ini_set() dans wp-config.php sont ignorés. Pourquoi ?

L’hébergeur utilise php_admin_value dans la configuration du pool PHP-FPM ou le bloc d’hôte virtuel Apache. php_admin_value définit une directive en lecture seule du point de vue de l’application — les appels ini_set() pour ces directives sont silencieusement ignorés. Seul le fournisseur d’hébergement peut modifier les valeurs définies de cette façon.

Comment vérifier que mes modifications de configuration PHP ont réellement pris effet ?

Créez un fichier temporaire dans votre racine WordPress contenant <?php phpinfo(); ?>, accédez-y dans un navigateur, et recherchez le nom de la directive. La colonne Local Value affiche la valeur effective pour ce répertoire. Supprimez le fichier immédiatement après vérification — laisser la sortie phpinfo() accessible publiquement est un risque de sécurité.

Cette erreur peut-elle être causée par autre chose que les limites de téléchargement PHP ?

Oui. L’expiration d’un nonce WordPress peut produire le même message. Les nonces WordPress sont valides pendant 24 heures par défaut. Si un utilisateur ouvre la page de téléchargement de plugin, la laisse inactive pendant plus de 24 heures, puis soumet le formulaire, la validation du nonce échoue et WordPress affiche "The link you followed has expired." Dans ce cas, il suffit de rafraîchir la page pour générer un nouveau nonce et le téléchargement se déroule normalement — aucune modification de configuration PHP n’est nécessaire.