Cum să Remediați Eroarea „Link-ul pe care l-ați Urmat a Expirat” în WordPress

Eroarea "The link you followed has expired" în WordPress este declanșată atunci când un fișier încărcat sau o trimitere de formular depășește una sau mai multe limite de rulare PHP — în special upload_max_filesize, post_max_size, max_execution_time sau memory_limit. WordPress nu poate recupera elegant din aceste respingeri de pe server, astfel că afișează acest mesaj generic în loc de o eroare PHP specifică.

Remedierea necesită creșterea valorilor acelor directive PHP prin orice nivel de configurare expus de mediul dvs. de găzduire: php.ini, .htaccess, wp-config.php sau o interfață grafică a panoului de control. Metoda care funcționează depinde în totalitate de nivelul dvs. de acces la server — acces SSH root, cPanel administrat sau un mediu partajat restricționat necesită fiecare o abordare diferită.

De ce apare de fapt această eroare

Înțelegerea cauzei principale vă împiedică să aplicați remedierea greșită. Când WordPress procesează o încărcare, browserul trimite o cerere POST multipart către wp-admin/async-upload.php sau wp-admin/update.php. PHP evaluează cererea față de patru limite independente înainte ca WordPress să execute o singură linie de cod al aplicației:

• upload_max_filesize — limita maximă pentru orice fișier încărcat individual
• post_max_size — limita pentru întregul corp POST, care trebuie să fie *mai mare* decât upload_max_filesize
• max_execution_time — numărul maxim de secunde în care un proces PHP poate rula
• memory_limit — RAM disponibil pentru procesul PHP; procesarea imaginilor și instalarea temelor necesită multă memorie

Dacă oricare dintre acestea este depășită, PHP termină silențios cererea. WordPress primește un răspuns gol sau malformat și afișează "The link you followed has expired." Eroarea nu este un bug WordPress — este PHP care aplică politica serverului.

Declanșatori comuni în practică:

• Instalarea unei teme premium (adesea 5–30 MB) pe un server partajat cu o limită implicită de încărcare de 2 MB
• Încărcarea unui fișier CSV de import de produse WooCommerce
• Instalarea unui pachet de plugin-uri care include resurse incluse
• Restaurarea unui site dintr-o arhivă de backup prin panoul de control WordPress
• Rularea unui script de import de lungă durată care atinge limita de timp de execuție

Tabel de referință rapidă pentru directive PHP

Regulă critică: post_max_size trebuie să fie întotdeauna setat mai mare decât upload_max_filesize. Dacă setați upload_max_filesize = 128M dar lăsați post_max_size = 8M, încărcările vor eșua în continuare deoarece limita corpului POST este atinsă prima.

Metoda 1: Editați php.ini (Recomandat pentru VPS și servere dedicate)

Aceasta este cea mai fiabilă și permanentă metodă. Într-un mediu de VPS Hosting sau Server Dedicat unde aveți acces root sau sudo, controlați direct configurația PHP.

Localizați fișierul php.ini activ:

php --ini | grep "Loaded Configuration File"

Sau din interiorul unui site WordPress, creați un fișier temporar:

<?php phpinfo(); ?>

Căutați rândul Loaded Configuration File în rezultat, apoi ștergeți fișierul imediat după.

Editați directivele:

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

După salvare, reporniți PHP-FPM sau Apache pentru a aplica modificările:

# 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

Verificați că noile valori au intrat în vigoare:

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

Caz limită de știut: Pe serverele care rulează mai multe versiuni PHP (o configurație comună pe cPanel), există un php.ini separat pentru fiecare versiune. Editarea celui greșit nu are niciun efect. Confirmați ce versiune PHP folosește WordPress înainte de a edita.

Metoda 2: Utilizați .htaccess (Găzduire partajată Apache)

Dacă vă aflați pe o găzduire partajată fără acces direct la php.ini, iar serverul dvs. rulează Apache cu mod_php sau suPHP, puteți suprascrie directivele PHP per director folosind .htaccess.

Accesați directorul rădăcină WordPress prin FTP, SFTP sau managerul de fișiere al găzduirii. Deschideți .htaccess și adăugați următorul bloc:

<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>

Salvați și încărcați fișierul, apoi testați încărcarea.

Avertismente importante:

• Această metodă nu funcționează pe serverele care rulează PHP-FPM, CGI sau FastCGI. Pe acele stive, directivele php_value din .htaccess vor cauza o Eroare Internă de Server 500 deoarece modulul Apache care gestionează PHP nu este mod_php. Dacă vedeți un 500 după salvare, eliminați imediat acele linii.
• Pe serverele Nginx, .htaccess este ignorat complet. Utilizați php.ini sau un fișier de suprascriere utilizator php.ini în schimb.
• Unii furnizori de găzduire administrați dezactivează explicit AllowOverride pentru directivele PHP, făcând această metodă ineficientă chiar și pe Apache.

Metoda 3: Adăugați directive în wp-config.php

Această metodă folosește funcția ini_set() a PHP pentru a suprascrie directivele la runtime. Funcționează indiferent de tipul serverului web, dar este supusă restricțiilor open_basedir și disable_functions ale furnizorului — unii furnizori blochează ini_set() din motive de securitate.

Deschideți wp-config.php din rădăcina WordPress și adăugați următoarele linii înainte de comentariul /* 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' );

@ suprimă erorile dacă ini_set() este dezactivat, prevenind un ecran alb. Cu toate acestea, dacă furnizorul a blocat aceste valori la nivel de server folosind php_admin_value, apelurile ini_set() sunt ignorate silențios — valorile nu se vor schimba.

Cum să verificați că a funcționat efectiv:

Instalați plugin-ul gratuit Query Monitor și verificați tab-ul de mediu PHP, sau adăugați un apel temporar phpinfo(). Dacă valorile afișează în continuare limitele vechi, ini_set() este suprascris la un nivel superior și trebuie să utilizați o altă metodă.

Metoda 4: Ajustați setările PHP în cPanel

Pentru mediile de găzduire administrate prin cPanel — inclusiv VPS cu cPanel — puteți modifica limitele PHP prin interfața grafică fără a atinge niciun fișier.

Pași:

1. Conectați-vă la cPanel.
2. Navigați la Software și faceți clic pe MultiPHP INI Editor.
3. Selectați rădăcina documentului site-ului dvs. WordPress din lista derulantă.
4. Localizați și actualizați următoarele câmpuri:

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

1. Faceți clic pe Apply.

Alternativ, utilizați Select PHP Version (PHP Selector) dacă furnizorul dvs. folosește CloudLinux. Sub tab-ul Options, aceleași directive sunt disponibile ca glisoare sau câmpuri de introducere.

Ce face cPanel în culise: Scrie un fișier .user.ini (pentru PHP-FPM) sau modifică .htaccess (pentru mod_php) în rădăcina documentului dvs. Dacă editați ulterior manual acele fișiere, este posibil să suprascrieți modificările cPanel — fiți conștient de acest conflict.

Metoda 5: Creați sau editați un fișier .user.ini (Medii PHP-FPM)

Aceasta este metoda pe care majoritatea tutorialelor o omit, dar este abordarea corectă pentru PHP-FPM — care este handlerul PHP implicit pe practic orice stivă modernă de găzduire, inclusiv mediile bazate pe Nginx.

Creați un fișier numit .user.ini în directorul rădăcină WordPress cu următorul conținut:

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

Încărcați-l în același director cu wp-config.php. PHP-FPM scanează periodic fișierele .user.ini — TTL-ul cache-ului este controlat de user_ini.cache_ttl, care implicit este de 300 de secunde (5 minute). Modificările nu sunt instantanee. Dacă aveți nevoie de efect imediat, reporniți PHP-FPM.

sudo systemctl restart php8.2-fpm

Notă de securitate: Fișierul .user.ini nu ar trebui să fie accesibil prin web. Adăugați aceasta în .htaccess dacă vă aflați pe Apache:

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

Pe Nginx, adăugați un bloc location pentru a refuza accesul:

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

Metoda 6: Contactați furnizorul dvs. de găzduire

Dacă niciuna dintre metodele de mai sus nu produce o schimbare în valorile PHP pe care le-ați verificat cu phpinfo() sau Query Monitor, furnizorul aplică limite la nivelul pool-ului PHP-FPM sau prin directive php_admin_value în configurația serverului — ambele neputând fi suprascrise de niciun fișier accesibil utilizatorului.

În acest caz, contactați suportul și solicitați creșteri specifice. Furnizați numele exacte ale directivelor și valorile țintă. Dacă furnizorul refuză sau impune un plafon maxim care nu îndeplinește cerințele dvs., luați în considerare migrarea la un plan de VPS Hosting unde controlați complet configurația PHP.

Diagnosticarea limitei care declanșează efectiv eroarea

În loc să ghiciți, utilizați acești pași de diagnosticare înainte de a aplica orice remediere:

Verificați limitele PHP curente din linia de comandă:

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;"

Verificați jurnalul de erori PHP pentru eșecul efectiv:

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

Căutați linii care conțin Allowed memory size, Maximum execution time sau POST Content-Length. Mesajul specific vă spune exact ce directivă să vizați.

Verificați dimensiunea fișierului pe care îl încărcați față de upload_max_filesize curent. Dacă fișierul are 45 MB și limita este de 64 MB, limita de încărcare nu este problema — uitați-vă la post_max_size sau memory_limit în schimb.

Alegerea metodei potrivite: Matrice de decizie

Listă de verificare tehnică înainte de a considera problema rezolvată

• post_max_size este setat mai mare decât upload_max_filesize — aceasta este cea mai frecventă configurare greșită
• Modificările au fost verificate cu phpinfo() sau php -r "echo ini_get(...)" — nu doar presupuse
• PHP-FPM a fost repornit dacă .user.ini sau php.ini a fost editat direct
• .user.ini sau php.ini editat corespunde versiunii PHP care servește efectiv site-ul WordPress
• memory_limit este cel puțin 256M dacă instalați teme mari sau rulați operațiuni intensive cu imagini
• Jurnalul de erori a fost verificat pentru a confirma ce limită specifică a cauzat terminarea
• Dacă vă aflați pe un plan de Găzduire Web Partajată, plafonul maxim al furnizorului a fost confirmat — unii furnizori limitează upload_max_filesize la 64M indiferent de setările utilizatorului
• După remedierea erorii de încărcare, verificați că Certificatele SSL sunt valide dacă accesați wp-admin prin HTTPS, deoarece erorile de conținut mixt sau de certificat pot produce eșecuri de redirecționare superficial similare

Întrebări frecvente

De ce apare eroarea chiar și după ce am crescut upload_max_filesize în .htaccess?

Serverul rulează probabil PHP prin FastCGI sau PHP-FPM în loc de mod_php. Directiva php_value din .htaccess este procesată doar de handlerul mod_php al Apache. Pe stivele PHP-FPM, utilizați în schimb un fișier .user.ini în directorul rădăcină WordPress.

Care este diferența dintre upload_max_filesize și post_max_size, și de ce contează ambele?

upload_max_filesize limitează dimensiunea fiecărui fișier individual dintr-un upload multipart. post_max_size limitează dimensiunea totală a întregului corp al cererii POST, care include datele fișierului plus câmpurile de formular și delimitatorii. Dacă post_max_size este mai mic decât upload_max_filesize, limita corpului POST este atinsă prima și PHP elimină întreaga cerere înainte ca WordPress să poată evalua dimensiunea fișierului.

Apelurile mele ini_set() din wp-config.php sunt ignorate. De ce?

Furnizorul folosește php_admin_value în configurația pool-ului PHP-FPM sau în blocul virtual host Apache. php_admin_value setează o directivă ca read-only din perspectiva aplicației — apelurile ini_set() pentru acele directive sunt eliminate silențios. Doar furnizorul de găzduire poate schimba valorile setate în acest mod.

Cum verific că modificările configurației PHP au intrat efectiv în vigoare?

Creați un fișier temporar în rădăcina WordPress care conține <?php phpinfo(); ?>, accesați-l într-un browser și căutați numele directivei. Coloana Local Value arată valoarea efectivă pentru acel director. Ștergeți fișierul imediat după verificare — lăsarea rezultatelor phpinfo() accesibile public reprezintă un risc de securitate.

Poate fi cauzată această eroare de altceva decât limitele de încărcare PHP?

Da. Expirarea unui nonce WordPress poate produce același mesaj. Nonce-urile WordPress sunt valabile implicit 24 de ore. Dacă un utilizator deschide pagina de încărcare a plugin-ului, o lasă inactivă mai mult de 24 de ore și apoi trimite formularul, validarea nonce eșuează și WordPress afișează "The link you followed has expired." În acest caz, simpla reîmprospătare a paginii generează un nonce nou și încărcarea continuă normal — nu sunt necesare modificări ale configurației PHP.