Як виправити помилку “Посилання, яке ви перейшли, застаріло” у 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 та виділених серверів)

Це найнадійніший і найдовговічніший метод. У середовищі 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

Цей метод використовує функцію 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 periodically scans for .user.ini files — 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, оскільки помилки змішаного вмісту або сертифіката можуть зовні нагадувати подібні збої перенаправлення

FAQ

Чому помилка з’являється навіть після того, як я збільшив 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 обмежує розмір кожного окремого файлу у 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?

Так. Те саме повідомлення може з’явитися через закінчення терміну дії nonce WordPress. Nonce WordPress дійсні протягом 24 годин за замовчуванням. Якщо користувач відкрив сторінку завантаження плагіна, залишив її неактивною більш ніж на 24 години, а потім надіслав форму, перевірка nonce не пройде і WordPress відобразить "The link you followed has expired." У цьому випадку достатньо просто оновити сторінку — буде згенеровано новий nonce і завантаження відбудеться нормально, без жодних змін конфігурації PHP.