Как да поправите грешката „Връзката, която следвахте, е изтекла” в WordPress

Грешката "The link you followed has expired" в WordPress се задейства, когато качване на файл или изпращане на формуляр надвишава един или повече PHP лимити по време на изпълнение — конкретно upload_max_filesize, post_max_size, max_execution_time или memory_limit. WordPress не може да се възстанови коректно от тези откази на сървърно ниво, затова показва това общо съобщение вместо конкретна PHP грешка.

Поправката изисква увеличаване на стойностите на тези PHP директиви чрез конфигурационния слой, до който вашата хостинг среда предоставя достъп: php.ini, .htaccess, wp-config.php или потребителски интерфейс на контролния панел. Кой метод работи зависи изцяло от нивото ви на достъп до сървъра — root SSH достъп, управляван cPanel или ограничена споделена среда изискват различен подход.

Защо всъщност възниква тази грешка

Разбирането на основната причина ви предпазва от прилагане на грешна поправка. Когато WordPress обработва качване, браузърът изпраща multipart POST заявка до wp-admin/async-upload.php или wp-admin/update.php. PHP оценява заявката спрямо четири независими лимита, преди WordPress да изпълни дори един ред от кода на приложението:

• upload_max_filesize — твърд таван за всеки отделно качен файл
• post_max_size — таван за цялото тяло на POST заявката, който трябва да е *по-голям* от upload_max_filesize
• max_execution_time — максималните секунди реално време, през които може да работи PHP процес
• memory_limit — RAM, достъпна за PHP процеса; обработката на изображения и инсталирането на теми са интензивни по отношение на паметта

Ако някой от тях бъде надвишен, PHP тихо прекратява заявката. WordPress получава празен или неправилно форматиран отговор и показва "The link you followed has expired." Грешката не е бъг в WordPress — това е PHP, прилагащ сървърната политика.

Чести причини на практика:

• Инсталиране на премиум тема (често 5–30 MB) на споделен хостинг с лимит за качване по подразбиране от 2 MB
• Качване на CSV файл за импортиране на продукти в WooCommerce
• Инсталиране на пакет от плъгини, включващ вградени ресурси
• Възстановяване на сайт от архивен файл за резервно копие чрез таблото на WordPress
• Изпълнение на дълготраен скрипт за импортиране, който достига тавана на времето за изпълнение

Таблица с бърза справка за PHP директиви

Критично правило: post_max_size трябва винаги да е зададен по-висок от upload_max_filesize. Ако зададете upload_max_filesize = 128M, но оставите post_max_size = 8M, качванията пак ще се провалят, защото лимитът на тялото на POST заявката се достига първи.

Метод 1: Редактиране на php.ini (препоръчително за VPS и dedicated сървъри)

Това е най-надеждният и постоянен метод. В среда с VPS хостинг или Dedicated сървър, където имате root или sudo достъп, вие контролирате PHP конфигурацията директно.

Намерете активния файл php.ini:

php --ini | grep "Loaded Configuration File"

Или от WordPress сайт създайте временен файл:

<?php phpinfo(); ?>

Потърсете реда Loaded Configuration File в изхода, след което незабавно изтрийте файла.

Редактирайте директивите:

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

След запазване рестартирайте PHP-FPM или Apache, за да приложите промените:

# 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

Проверете дали новите стойности са влезли в сила:

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

Граничен случай, който трябва да знаете: На сървъри, работещи с множество PHP версии (честа конфигурация при cPanel), има отделен php.ini за всяка версия. Редактирането на грешния няма никакъв ефект. Потвърдете коя PHP версия използва WordPress, преди да редактирате.

Метод 2: Използване на .htaccess (Apache споделен хостинг)

Ако сте на споделен хостинг без директен достъп до php.ini и сървърът ви работи с Apache с mod_php или suPHP, можете да замените PHP директивите за конкретна директория чрез .htaccess.

Достъпете основната директория на WordPress чрез FTP, SFTP или файловия мениджър на хостинга. Отворете .htaccess и добавете следния блок:

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

Запазете и качете файла, след което тествайте качването.

Важни предупреждения:

• Този метод не работи на сървъри, работещи с PHP-FPM, CGI или FastCGI. При тези стекове директивите php_value в .htaccess ще причинят 500 Internal Server Error, защото Apache модулът, обработващ PHP, не е mod_php. Ако видите 500 след запазване, незабавно премахнете тези редове.
• На Nginx сървъри .htaccess се игнорира изцяло. Вместо това използвайте php.ini или потребителски override файл php.ini.
• Някои управлявани хостинги изрично забраняват AllowOverride за PHP директиви, което прави този метод неефективен дори при Apache.

Метод 3: Добавяне на директиви към wp-config.php

Този метод използва функцията ini_set() на PHP за замяна на директиви по време на изпълнение. Работи независимо от типа на уеб сървъра, но е подчинен на ограниченията open_basedir и disable_functions на хостинга — някои хостинги блокират ini_set() по съображения за сигурност.

Отворете wp-config.php в основната директория на WordPress и добавете следните редове преди коментара /* 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' );

@ потиска грешките, ако ini_set() е деактивирана, предотвратявайки бял екран. Въпреки това, ако хостингът е заключил тези стойности на сървърно ниво чрез php_admin_value, извикванията на ini_set() се игнорират тихо — стойностите няма да се променят.

Как да проверите дали действително е проработило:

Инсталирайте безплатния плъгин Query Monitor и проверете раздела за PHP среда, или добавете временно извикване на phpinfo(). Ако стойностите все още показват старите лимити, ini_set() се замества на по-високо ниво и трябва да използвате различен метод.

Метод 4: Настройване на PHP настройките в cPanel

За хостинг среди, управлявани чрез cPanel — включително VPS с cPanel — можете да промените PHP лимитите чрез графичния интерфейс, без да докосвате никакви файлове.

Стъпки:

1. Влезте в cPanel.
2. Отидете в Software и кликнете върху MultiPHP INI Editor.
3. Изберете основната директория на вашия WordPress сайт от падащото меню.
4. Намерете и актуализирайте следните полета:

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

1. Кликнете върху Apply.

Алтернативно, използвайте Select PHP Version (PHP Selector), ако хостингът ви използва CloudLinux. В раздела Options същите директиви са достъпни като плъзгачи или полета за въвеждане.

Какво всъщност прави cPanel зад кулисите: Записва файл .user.ini (за PHP-FPM) или модифицира .htaccess (за mod_php) в основната ви директория. Ако по-късно ръчно редактирате тези файлове, може да презапишете промените на cPanel — имайте предвид този конфликт.

Метод 5: Създаване или редактиране на файл .user.ini (PHP-FPM среди)

Това е методът, който повечето уроци пропускат, а той е правилният подход за PHP-FPM — който е PHP обработчикът по подразбиране на практически всеки съвременен хостинг стек, включително среди базирани на Nginx.

Създайте файл с име .user.ini в основната директория на WordPress със следното съдържание:

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

Качете го в същата директория като wp-config.php. PHP-FPM периодично сканира за файлове .user.ini — TTL на кеша се контролира от user_ini.cache_ttl, което по подразбиране е 300 секунди (5 минути). Промените не са незабавни. Ако имате нужда от незабавен ефект, рестартирайте PHP-FPM.

sudo systemctl restart php8.2-fpm

Бележка за сигурността: Файлът .user.ini не трябва да е достъпен от уеб. Добавете това към .htaccess, ако сте на Apache:

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

На Nginx добавете location блок за отказване на достъп:

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

Метод 6: Свържете се с вашия хостинг доставчик

Ако нито един от горните методи не доведе до промяна в PHP стойностите, които сте проверили с phpinfo() или Query Monitor, хостингът налага лимити на ниво PHP-FPM пул или чрез директиви php_admin_value в конфигурацията на сървъра — и двете не могат да бъдат заменени от никакъв потребителски достъпен файл.

В този случай се свържете с поддръжката и поискайте конкретни увеличения. Предоставете точните имена на директивите и целевите стойности. Ако хостингът откаже или наложи твърд таван, който не отговаря на вашите изисквания, помислете за мигриране към план за VPS хостинг, където вие контролирате изцяло PHP конфигурацията.

Диагностициране кой лимит всъщност задейства грешката

Вместо да гадаете, използвайте тези диагностични стъпки, преди да приложите каквато и да е поправка:

Проверете текущите PHP лимити от командния ред:

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

Проверете PHP error log за действителния проблем:

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

Търсете редове, съдържащи Allowed memory size, Maximum execution time или POST Content-Length. Конкретното съобщение ви казва точно коя директива да насочите.

Проверете размера на файла, който качвате спрямо текущия upload_max_filesize. Ако файлът е 45 MB, а лимитът е 64 MB, лимитът за качване не е проблемът — потърсете post_max_size или memory_limit.

Избор на правилния метод: матрица за вземане на решения

Ключов технически контролен списък преди да считате проблема за решен

• post_max_size е зададен по-висок от upload_max_filesize — това е най-честата неправилна конфигурация
• Промените са проверени с phpinfo() или php -r "echo ini_get(...)" — не само предполагани
• PHP-FPM е рестартиран, ако .user.ini или php.ini са редактирани директно
• .user.ini или php.ini, който се редактира, съответства на PHP версията, която действително обслужва WordPress сайта
• memory_limit е поне 256M, ако инсталирате големи теми или извършвате операции с много изображения
• Error log е проверен, за да се потвърди кой конкретен лимит е причинил прекратяването
• Ако сте на план за споделен уеб хостинг, твърдият таван на хостинга е потвърден — някои доставчици ограничават upload_max_filesize до 64M независимо от потребителските настройки
• След отстраняване на грешката при качване, проверете дали вашите SSL сертификати са валидни, ако достъпвате wp-admin през HTTPS, тъй като грешки при смесено съдържание или сертификати могат да причинят повърхностно подобни проблеми с пренасочването

ЧЗВ

Защо грешката се появява дори след като увеличих upload_max_filesize в .htaccess?

Сървърът вероятно работи с PHP чрез FastCGI или PHP-FPM, а не mod_php. Директивата php_value в .htaccess се обработва само от Apache mod_php обработчика. При PHP-FPM стекове вместо това използвайте файл .user.ini в основната директория на WordPress.

Каква е разликата между upload_max_filesize и post_max_size и защо и двете имат значение?

upload_max_filesize ограничава размера на всеки отделен файл при multipart качване. post_max_size ограничава общия размер на цялото тяло на POST заявката, което включва данните на файла плюс полетата на формуляра и разделителите. Ако post_max_size е по-малък от upload_max_filesize, лимитът на тялото на POST заявката се достига първи и PHP отхвърля цялата заявка, преди WordPress да може да оцени размера на файла.

Извикванията ми на ini_set() в wp-config.php се игнорират. Защо?

Хостингът използва php_admin_value в конфигурацията на PHP-FPM пула или в блока на Apache виртуалния хост. php_admin_value задава директива като само за четене от гледна точка на приложението — извикванията на ini_set() за тези директиви се отхвърлят тихо. Само хостинг доставчикът може да промени стойности, зададени по този начин.

Как да проверя дали промените в PHP конфигурацията действително са влезли в сила?

Създайте временен файл в основната директория на WordPress, съдържащ <?php phpinfo(); ?>, достъпете го в браузър и потърсете името на директивата. Колоната Local Value показва ефективната стойност за тази директория. Изтрийте файла незабавно след проверката — оставянето на изхода от phpinfo() публично достъпен е риск за сигурността.

Може ли тази грешка да бъде причинена от нещо различно от PHP лимитите за качване?

Да. Изтичането на WordPress nonce може да доведе до същото съобщение. WordPress nonce-овете са валидни 24 часа по подразбиране. Ако потребител отвори страницата за качване на плъгин, остави я неактивна повече от 24 часа и след това изпрати формуляра, валидирането на nonce се проваля и WordPress показва "The link you followed has expired." В този случай просто опресняването на страницата генерира нов nonce и качването протича нормално — не са необходими промени в PHP конфигурацията.