Как исправить ошибку «Срок действия ссылки истёк» в 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 обрабатывает загрузку, браузер отправляет составной 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 — оперативная память, доступная 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 и выделенных серверов)

Это наиболее надёжный и постоянный метод. В среде VPS-хостинга или выделенного сервера, где у вас есть 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 или файл пользовательских переопределений php.ini.
• Некоторые управляемые хостинги явно отключают AllowOverride для PHP-директив, что делает этот метод неэффективным даже на Apache.

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

Этот метод использует функцию PHP ini_set() для переопределения директив во время выполнения. Он работает независимо от типа веб-сервера, однако подчиняется ограничениям 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. Перейдите в раздел Программное обеспечение и нажмите MultiPHP INI Editor.
3. Выберите корневую директорию вашего сайта WordPress из выпадающего списка.
4. Найдите и обновите следующие поля:

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

1. Нажмите Применить.

Кроме того, используйте 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 на предмет фактической причины сбоя:

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, если вы устанавливаете крупные темы или выполняете операции с большим количеством изображений
• Журнал ошибок был проверен для подтверждения того, какой конкретный лимит вызвал завершение процесса
• Если вы используете план общего веб-хостинга, подтверждён жёсткий предел хостинга — некоторые провайдеры ограничивают upload_max_filesize значением 64M независимо от пользовательских настроек
• После устранения ошибки загрузки убедитесь, что ваши SSL-сертификаты действительны, если вы обращаетесь к wp-admin по HTTPS, поскольку ошибки смешанного контента или сертификата могут внешне напоминать аналогичные сбои перенаправления

Часто задаваемые вопросы

Почему ошибка появляется даже после того, как я увеличил upload_max_filesize в .htaccess?

Скорее всего, сервер запускает PHP через FastCGI или PHP-FPM, а не через mod_php. Директива php_value в .htaccess обрабатывается только обработчиком mod_php Apache. В стеках PHP-FPM вместо этого используйте файл .user.ini в корневой директории WordPress.

В чём разница между upload_max_filesize и post_max_size и почему важны оба?

upload_max_filesize ограничивает размер каждого отдельного файла в составной загрузке. 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?

Да. То же сообщение может появиться из-за истечения срока действия nonce WordPress. По умолчанию nonce WordPress действительны в течение 24 часов. Если пользователь открыл страницу загрузки плагина, оставил её неактивной более 24 часов, а затем отправил форму, проверка nonce завершается неудачей и WordPress отображает "The link you followed has expired." В этом случае достаточно просто обновить страницу — будет сгенерирован новый nonce и загрузка пройдёт нормально, без каких-либо изменений конфигурации PHP.