Jak naprawić błąd „Link, który kliknąłeś, wygasł” w WordPress

Błąd "The link you followed has expired" w WordPress jest wywoływany, gdy przesyłanie pliku lub przesyłanie formularza przekracza jeden lub więcej limitów środowiska uruchomieniowego PHP — konkretnie upload_max_filesize, post_max_size, max_execution_time lub memory_limit. WordPress nie może płynnie odzyskać sprawności po tych odrzuceniach po stronie serwera, dlatego wyświetla tę ogólną wiadomość zamiast konkretnego błędu PHP.

Rozwiązanie wymaga podwyższenia wartości tych dyrektyw PHP przez warstwę konfiguracyjną dostępną w Twoim środowisku hostingowym: php.ini, .htaccess, wp-config.php lub interfejs panelu sterowania. Metoda, która zadziała, zależy wyłącznie od poziomu dostępu do serwera — dostęp root SSH, zarządzany cPanel lub zablokowane środowisko współdzielone wymagają różnych podejść.

Dlaczego ten błąd faktycznie występuje

Zrozumienie głównej przyczyny zapobiega zastosowaniu niewłaściwego rozwiązania. Gdy WordPress przetwarza przesyłanie, przeglądarka wysyła żądanie POST multipart do wp-admin/async-upload.php lub wp-admin/update.php. PHP ocenia żądanie względem czterech niezależnych limitów, zanim WordPress wykona choćby jedną linię kodu aplikacji:

• upload_max_filesize — górny limit dla każdego pojedynczego przesyłanego pliku
• post_max_size — limit całego ciała POST, który musi być *większy* niż upload_max_filesize
• max_execution_time — maksymalna liczba sekund zegarowych, przez które może działać proces PHP
• memory_limit — RAM dostępny dla procesu PHP; przetwarzanie obrazów i instalacja motywów są pamięciochłonne

Jeśli którykolwiek z tych limitów zostanie przekroczony, PHP po cichu kończy żądanie. WordPress otrzymuje pustą lub zniekształconą odpowiedź i wyświetla "The link you followed has expired." Błąd nie jest błędem WordPress — to PHP egzekwuje politykę serwera.

Typowe przyczyny w praktyce:

• Instalowanie premium motywu (często 5–30 MB) na hostingu współdzielonym z domyślnym limitem przesyłania 2 MB
• Przesyłanie pliku CSV importu produktów WooCommerce
• Instalowanie pakietu wtyczek zawierającego dołączone zasoby
• Przywracanie witryny z archiwum kopii zapasowej przez panel WordPress
• Uruchamianie długotrwałego skryptu importu, który osiąga limit czasu wykonania

Tabela szybkiego odniesienia do dyrektyw PHP

Kluczowa zasada: post_max_size musi być zawsze ustawiony wyżej niż upload_max_filesize. Jeśli ustawisz upload_max_filesize = 128M, ale pozostawisz post_max_size = 8M, przesyłanie nadal będzie kończyć się niepowodzeniem, ponieważ limit ciała POST zostanie osiągnięty jako pierwszy.

Metoda 1: Edycja php.ini (zalecana dla VPS i serwerów dedykowanych)

Jest to najbardziej niezawodna i trwała metoda. W środowisku Hostingu VPS lub Serwera Dedykowanego, gdzie masz dostęp root lub sudo, kontrolujesz konfigurację PHP bezpośrednio.

Znajdź aktywny plik php.ini:

php --ini | grep "Loaded Configuration File"

Lub z poziomu witryny WordPress utwórz tymczasowy plik:

<?php phpinfo(); ?>

Znajdź wiersz Loaded Configuration File w wynikach, a następnie natychmiast usuń plik.

Edytuj dyrektywy:

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

Po zapisaniu uruchom ponownie PHP-FPM lub Apache, aby zastosować zmiany:

# 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

Zweryfikuj, czy nowe wartości zostały zastosowane:

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

Przypadek brzegowy, o którym warto wiedzieć: Na serwerach obsługujących wiele wersji PHP (typowa konfiguracja w cPanel) istnieje osobny plik php.ini dla każdej wersji. Edytowanie niewłaściwego nie przyniesie żadnego efektu. Przed edycją potwierdź, której wersji PHP używa WordPress.

Metoda 2: Użycie .htaccess (hosting współdzielony Apache)

Jeśli korzystasz z hostingu współdzielonego bez bezpośredniego dostępu do php.ini, a Twój serwer działa na Apache z mod_php lub suPHP, możesz nadpisać dyrektywy PHP per-katalog za pomocą .htaccess.

Uzyskaj dostęp do głównego katalogu WordPress przez FTP, SFTP lub menedżer plików hostingu. Otwórz .htaccess i dołącz następujący blok:

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

Zapisz i prześlij plik, a następnie przetestuj przesyłanie.

Ważne zastrzeżenia:

• Ta metoda nie działa na serwerach obsługujących PHP-FPM, CGI lub FastCGI. W tych konfiguracjach dyrektywy php_value w .htaccess spowodują błąd 500 Internal Server Error, ponieważ moduł Apache obsługujący PHP nie jest mod_php. Jeśli po zapisaniu pojawi się błąd 500, natychmiast usuń te linie.
• Na serwerach Nginx plik .htaccess jest całkowicie ignorowany. Zamiast tego użyj php.ini lub pliku nadpisania użytkownika php.ini.
• Niektórzy zarządzani dostawcy hostingu jawnie wyłączają AllowOverride dla dyrektyw PHP, co sprawia, że ta metoda jest nieskuteczna nawet na Apache.

Metoda 3: Dodanie dyrektyw do wp-config.php

Ta metoda używa funkcji ini_set() PHP do nadpisywania dyrektyw w czasie wykonywania. Działa niezależnie od typu serwera WWW, ale podlega ograniczeniom open_basedir i disable_functions hosta — niektórzy dostawcy blokują ini_set() ze względów bezpieczeństwa.

Otwórz wp-config.php w katalogu głównym WordPress i dodaj następujące linie przed komentarzem /* 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' );

Znak @ tłumi błędy, jeśli ini_set() jest wyłączone, zapobiegając białemu ekranowi. Jednak jeśli host zablokował te wartości na poziomie serwera za pomocą php_admin_value, wywołania ini_set() są po cichu ignorowane — wartości nie ulegną zmianie.

Jak zweryfikować, czy faktycznie zadziałało:

Zainstaluj darmową wtyczkę Query Monitor i sprawdź zakładkę środowiska PHP lub dodaj tymczasowe wywołanie phpinfo(). Jeśli wartości nadal pokazują stare limity, ini_set() jest nadpisywane na wyższym poziomie i musisz użyć innej metody.

Metoda 4: Dostosowanie ustawień PHP w cPanel

W środowiskach hostingowych zarządzanych przez cPanel — w tym VPS z cPanel — możesz modyfikować limity PHP przez interfejs graficzny bez dotykania jakichkolwiek plików.

Kroki:

1. Zaloguj się do cPanel.
2. Przejdź do sekcji Oprogramowanie i kliknij MultiPHP INI Editor.
3. Wybierz katalog główny dokumentów swojej witryny WordPress z listy rozwijanej.
4. Znajdź i zaktualizuj następujące pola:

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

1. Kliknij Zastosuj.

Alternatywnie użyj Select PHP Version (PHP Selector), jeśli Twój host używa CloudLinux. W zakładce Opcje te same dyrektywy są dostępne jako suwaki lub pola wprowadzania.

Co cPanel faktycznie robi w tle: Zapisuje plik .user.ini (dla PHP-FPM) lub modyfikuje .htaccess (dla mod_php) w katalogu głównym dokumentów. Jeśli później ręcznie edytujesz te pliki, możesz nadpisać zmiany cPanel — miej świadomość tego konfliktu.

Metoda 5: Tworzenie lub edycja pliku .user.ini (środowiska PHP-FPM)

Jest to metoda pomijana przez większość poradników, a jednocześnie właściwe podejście dla PHP-FPM — który jest domyślnym handlerem PHP praktycznie w każdym nowoczesnym stosie hostingowym, w tym środowiskach opartych na Nginx.

Utwórz plik o nazwie .user.ini w głównym katalogu WordPress z następującą zawartością:

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

Prześlij go do tego samego katalogu co wp-config.php. PHP-FPM skanuje pliki .user.ini okresowo — TTL pamięci podręcznej jest kontrolowany przez user_ini.cache_ttl, który domyślnie wynosi 300 sekund (5 minut). Zmiany nie są natychmiastowe. Jeśli potrzebujesz natychmiastowego efektu, uruchom ponownie PHP-FPM.

sudo systemctl restart php8.2-fpm

Uwaga dotycząca bezpieczeństwa: Plik .user.ini nie powinien być dostępny przez sieć. Dodaj to do swojego .htaccess, jeśli korzystasz z Apache:

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

Na Nginx dodaj blok location, aby odmówić dostępu:

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

Metoda 6: Skontaktuj się z dostawcą hostingu

Jeśli żadna z powyższych metod nie zmienia wartości PHP zweryfikowanych za pomocą phpinfo() lub Query Monitor, host egzekwuje limity na poziomie puli PHP-FPM lub za pomocą dyrektyw php_admin_value w konfiguracji serwera — obu nie można nadpisać żadnym plikiem dostępnym dla użytkownika.

W takim przypadku skontaktuj się z pomocą techniczną i poproś o konkretne zwiększenia. Podaj dokładne nazwy dyrektyw i docelowe wartości. Jeśli host odmówi lub narzuci twardy limit, który nie spełnia Twoich wymagań, rozważ migrację do planu Hostingu VPS, gdzie masz pełną kontrolę nad konfiguracją PHP.

Diagnozowanie, który limit faktycznie wywołuje błąd

Zamiast zgadywać, wykonaj te kroki diagnostyczne przed zastosowaniem jakiegokolwiek rozwiązania:

Sprawdź aktualne limity PHP z wiersza poleceń:

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

Sprawdź dziennik błędów PHP w poszukiwaniu rzeczywistej przyczyny awarii:

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

Szukaj linii zawierających Allowed memory size, Maximum execution time lub POST Content-Length. Konkretna wiadomość wskaże dokładnie, którą dyrektywę należy zmienić.

Sprawdź rozmiar przesyłanego pliku względem aktualnego upload_max_filesize. Jeśli plik ma 45 MB, a limit wynosi 64 MB, limit przesyłania nie jest problemem — zamiast tego sprawdź post_max_size lub memory_limit.

Wybór właściwej metody: macierz decyzyjna

Kluczowa lista kontrolna przed uznaniem problemu za rozwiązany

• post_max_size jest ustawiony wyżej niż upload_max_filesize — to najczęstsza błędna konfiguracja
• Zmiany zostały zweryfikowane za pomocą phpinfo() lub php -r "echo ini_get(...)" — nie tylko założone
• PHP-FPM został uruchomiony ponownie, jeśli .user.ini lub php.ini był edytowany bezpośrednio
• Edytowany .user.ini lub php.ini odpowiada wersji PHP faktycznie obsługującej witrynę WordPress
• memory_limit wynosi co najmniej 256M, jeśli instalujesz duże motywy lub wykonujesz operacje wymagające dużej ilości obrazów
• Dziennik błędów został sprawdzony w celu potwierdzenia, który konkretny limit spowodował zakończenie procesu
• Jeśli korzystasz z planu Hostingu Współdzielonego, twardy limit hosta został potwierdzony — niektórzy dostawcy ograniczają upload_max_filesize do 64M niezależnie od ustawień użytkownika
• Po naprawieniu błędu przesyłania sprawdź, czy Twoje Certyfikaty SSL są ważne, jeśli uzyskujesz dostęp do wp-admin przez HTTPS, ponieważ błędy mieszanej zawartości lub certyfikatu mogą powodować powierzchownie podobne awarie przekierowań

FAQ

Dlaczego błąd pojawia się nawet po zwiększeniu upload_max_filesize w .htaccess?

Serwer prawdopodobnie obsługuje PHP przez FastCGI lub PHP-FPM zamiast mod_php. Dyrektywa php_value w .htaccess jest przetwarzana tylko przez handler mod_php Apache. Na stosach PHP-FPM zamiast tego użyj pliku .user.ini w głównym katalogu WordPress.

Jaka jest różnica między upload_max_filesize a post_max_size i dlaczego oba mają znaczenie?

upload_max_filesize ogranicza rozmiar każdego pojedynczego pliku w przesyłaniu wieloczęściowym. post_max_size ogranicza całkowity rozmiar całego ciała żądania POST, który obejmuje dane pliku oraz pola formularza i granice. Jeśli post_max_size jest mniejszy niż upload_max_filesize, limit ciała POST jest osiągany jako pierwszy i PHP odrzuca całe żądanie, zanim WordPress może ocenić rozmiar pliku.

Moje wywołania ini_set() w wp-config.php są ignorowane. Dlaczego?

Host używa php_admin_value w konfiguracji puli PHP-FPM lub bloku wirtualnego hosta Apache. php_admin_value ustawia dyrektywę jako tylko do odczytu z perspektywy aplikacji — wywołania ini_set() dla tych dyrektyw są po cichu odrzucane. Tylko dostawca hostingu może zmienić wartości ustawione w ten sposób.

Jak zweryfikować, czy moje zmiany konfiguracji PHP faktycznie zostały zastosowane?

Utwórz tymczasowy plik w katalogu głównym WordPress zawierający <?php phpinfo(); ?>, uzyskaj do niego dostęp w przeglądarce i wyszukaj nazwę dyrektywy. Kolumna Local Value pokazuje efektywną wartość dla tego katalogu. Usuń plik natychmiast po sprawdzeniu — pozostawienie publicznie dostępnych danych wyjściowych phpinfo() stanowi zagrożenie bezpieczeństwa.

Czy ten błąd może być spowodowany czymś innym niż limity przesyłania PHP?

Tak. Wygaśnięcie nonce WordPress może powodować tę samą wiadomość. Nonce WordPress są domyślnie ważne przez 24 godziny. Jeśli użytkownik otworzy stronę przesyłania wtyczki, pozostawi ją bezczynną przez ponad 24 godziny, a następnie prześle formularz, weryfikacja nonce nie powiedzie się i WordPress wyświetli "The link you followed has expired." W takim przypadku wystarczy odświeżyć stronę, aby wygenerować nowy nonce i przesyłanie przebiega normalnie — żadne zmiany konfiguracji PHP nie są potrzebne.