Jak zwiększyć maksymalny rozmiar przesyłanego pliku w WordPress

Limit przesyłanych plików w WordPress zależy od trzech ustawień, które muszą być ze sobą zgodne. Efektywny limit to najmniejsza z wartości upload_max_filesize, post_max_size oraz limitu żądań serwera WWW. Podniesiesz jedną, a dwie pozostałe zostawisz nisko — i nic się nie zmieni. Właśnie dlatego większość osób dochodzi do wniosku, że ich poprawka “nie zadziałała”. Najpierw sprawdź swoje aktualne wartości za pomocą narzędzia do sprawdzania maksymalnego rozmiaru przesyłanego pliku w WordPress; odczytuje ono te same wartości, które zgłasza WordPress, i pokazuje, która z nich Cię blokuje.

Dlaczego ten limit istnieje i gdzie jest ustawiany

WordPress nie ustawia limitu przesyłanych plików. On go tylko zgłasza. Gdy widzisz komunikat “The uploaded file exceeds the upload_max_filesize directive in php.ini”, pochodzi on wprost z PHP.

O tym, czy plik zostanie przyjęty, decydują trzy odrębne wartości, a rzeczywisty pułap wyznacza ta najniższa:

• upload_max_filesize (PHP) — największy pojedynczy plik, jaki PHP przyjmie.
• post_max_size (PHP) — największy łączny rozmiar treści żądania POST. Twój plik jedzie wewnątrz żądania POST razem z innymi polami formularza, więc ta wartość musi być większa niż upload_max_filesize.
• Limit treści żądania serwera WWW — client_max_body_size w Nginx lub LimitRequestBody w Apache. Ten żyje całkowicie poza PHP, i dlatego poprawki dotyczące wyłącznie PHP po cichu zawodzą, gdy z tyłu stoi Nginx.

Czwarta wartość, max_execution_time, nie ogranicza rozmiaru, ale przerwie powolne przesyłanie dużego pliku w połowie transferu przy słabym łączu. To osobny objaw, a nie element pułapu rozmiaru.

Pułapka: ustawiasz upload_max_filesize = 256M, przeładowujesz i wciąż nie możesz przesłać pliku o rozmiarze 100 MB — ponieważ post_max_size nadal wynosi 8M. PHP odrzuca żądanie na podstawie łącznego rozmiaru treści, zanim w ogóle sprawdzi sam plik. Limit Cię nie zignorował. Inny limit złapał go pierwszy.

Jak to naprawić, po kolei

Idź od rozwiązań najbardziej skutecznych do tych ostatecznych.

1. Edytuj php.ini (właściwe miejsce). Znajdź plik, który Twoja witryna faktycznie wczytuje — uruchom stronę z <?php phpinfo(); i odczytaj “Loaded Configuration File” albo zapytaj swojego dostawcę hostingu. Ustaw obie wartości PHP i pamiętaj, aby post_max_size było większe niż upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Zrestartuj PHP-FPM (sudo systemctl restart php8.2-fpm) lub Apache. Zmiany nie zadziałają, dopóki proces PHP się nie zrestartuje.

2. Brak dostępu do php.ini? Użyj .htaccess (tylko Apache + mod_php). Dodaj do pliku .htaccess w katalogu głównym WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Zadziała to tylko wtedy, gdy PHP działa jako moduł Apache. Pod PHP-FPM, CGI lub FastCGI php_value zwróci błąd 500 — a taka porażka oznacza, że jesteś na złej drodze, a nie że wartość jest błędna. Przejdź na .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Podnieś limit serwera WWW — krok, o którym wszyscy zapominają. W Nginx PHP nigdy nawet nie zobaczy zbyt dużego żądania; Nginx najpierw zwróci 413 Request Entity Too Large. W bloku serwera:

client_max_body_size 256M;

Przeładuj poleceniem sudo nginx -t && sudo systemctl reload nginx. Jeśli korzystasz z Nginx, a Twoje zmiany w PHP “nic nie dały”, to prawie zawsze właśnie o to chodzi.

Po każdej zmianie ponownie sprawdź zgłaszane wartości. Narzędzie do maksymalnego rozmiaru przesyłanego pliku poda Ci nowy efektywny pułap i wygeneruje dokładny fragment konfiguracji dla Twojego środowiska, dzięki czemu nie musisz zgadywać, która z trzech wartości nadal jest za niska.

Czego nie robić

Nie edytuj wp-config.php w nadziei, że podniesie to limit. Powszechnie kopiowana linijka nie robi tego, co twierdzą wpisy na blogach:

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize ma tryb PHP_INI_PERDIR. Nie da się go zmienić z poziomu PHP w czasie działania za pomocą ini_set(). Przyjmuje nowe wartości wyłącznie z php.ini, .htaccess lub .user.ini — nigdy z kodu aplikacji. Ta linijka wykonuje się bez błędu i nie robi nic, co czyni ją jedną z najpewniej powtarzanych błędnych porad w świecie WordPress.

Nie wklejaj też @ini_set('post_max_size', ...) — to samo ograniczenie, ta sama cicha bezczynność.

Nie ustawiaj WP_MEMORY_LIMIT w przekonaniu, że to limit przesyłanych plików. Ta wartość kontroluje pułap pamięci PHP dla wykonywanego kodu. Nie ma związku z tym, jak duży plik serwer przyjmie.

Nie poprzestawaj na jednym pliku. Najczęstsza porażka to zmiana samego upload_max_filesize i ogłoszenie, że poprawka jest zepsuta. Zmień wszystkie trzy wartości i pilnuj, aby post_max_size było większe niż upload_max_filesize.

Nie ustawiaj limitów absurdalnie wysoko “na wszelki wypadek”. Limit 2 GB tylko sprasza problemy z wyczerpaniem zasobów i i tak nie pomaga — jeśli naprawdę potrzebujesz plików wielogigabajtowych, przesyłaj je poza przeglądarką (przez SFTP lub wtyczkę do przesyłania fragmentarycznego), zamiast przepychać je przez pojedyncze żądanie POST w PHP.

Nadal utknąłeś?

Jeśli wszystkie trzy wartości są podniesione, a mimo to trafiasz na ścianę, żądanie jest gdzieś ograniczane wyżej, przed Twoim serwerem: przez CDN lub proxy (panel Cloudflare sam z siebie ogranicza rozmiar przesyłanej treści), przez limit platformy zarządzanego hostingu, który ignoruje Twój php.ini, albo przez .user.ini, który jeszcze się nie odświeżył — respektuje on wartość user_ini.cache_ttl w PHP, więc po zapisaniu może reagować z kilkuminutowym opóźnieniem. Sprawdź, co serwer faktycznie zgłasza, a nie co wpisałeś w pliku, i popraw tę warstwę, która nadal jest za niska. Gdy zgłaszana liczba wreszcie zgodzi się z Twoim celem, przesyłanie zadziała.