Czym są parametry upload_max_filesize i post_max_size w PHP?

Musiałeś kiedyś przerwać import w WordPressie, bo plik okazał się za duży, albo dostałeś komunikat, że upload nie zostanie ukończony? Najczęściej przyczyną jest parametr: upload_max_filesize, który ogranicza maksymalny rozmiar pojedynczego pliku wysyłanego przez HTTP, a post_max_size ogranicza łączny rozmiar całego żądania POST (objaśnimy to w dalszej części), dlatego przy importach i przesyłaniu paczek motywów, wtyczek, mediów czy plików CSV/XML, to właśnie te parametry jako pierwsze odcinają operację, zanim aplikacja w ogóle zacznie przetwarzanie danych.

upload_max_filesize i post_max_size – jak ograniczają import danych?

Zdefiniujmy omawiane parametry:

• upload_max_filesize dotyczy pojedynczego pliku, więc jeśli próbujesz wgrać np. backup ZIP 256 MB albo paczkę z mediami 120 MB, a limit wynosi 64 MB, upload po prostu nie przejdzie, nawet jeśli serwer jest wydajny i masz wolną przestrzeń na dysku.
• post_max_size jest bardziej podstępny, bo dotyczy całego POST-a, czyli jeśli wysyłasz plik 64 MB i do tego formularz ma dużo pól, tokenów lub metadanych, to łączna wielkość żądania może przekroczyć post_max_size i w efekcie upload zostanie ucięty albo całe żądanie odrzucone.

W importach (np. WordPress importer, WooCommerce CSV, import produktów w PrestaShop, wgrywanie pliku WXR/XML, import przez phpMyAdmin) sytuacja wygląda tak, że najpierw musisz dostarczyć plik na serwer, a dopiero potem aplikacja go czyta i przetwarza, więc jeśli limit uploadu/POST zatrzyma operację na wejściu, to import nie ma nawet czego rozpocząć.

Przykłady, w których te parametry mogą okazać się kłopotliwe:

• wgrywanie motywu/wtyczki jako ZIP przez panel,
• import CSV z produktami lub wariantami, gdzie plik jest duży,
• import bazy danych w phpMyAdmin (jeśli robisz to przez www),
• wgrywanie backupów do narzędzi migracyjnych, które oczekują pliku w panelu.

Z czym te limity są powiązane i czy WebFTP/SSH rozwiązuje problem?

Te dwa parametry są ściśle powiązane z innymi elementami hostingu i serwera, bo upload i import to nie tylko rozmiar, ale też czas i zasoby potrzebne na przetworzenie pliku:

• memory_limit: import często parsuje duże pliki do pamięci, więc nawet jeśli upload przejdzie, przetwarzanie może się wywalić na braku RAM dla procesu PHP.

• max_execution_time i max_input_time: pierwszy ogranicza czas pracy skryptu, drugi czas na wczytanie danych wejściowych; duży import może wymagać więcej czasu niż standardowe 30–60 sekund.

• limity warstwy serwera WWW: Nginx może mieć client_max_body_size, Apache może ograniczać rozmiar żądania, a reverse proxy/WAF potrafią blokować duże uploady niezależnie od PHP.

• upload_tmp_dir i przestrzeń dyskowa / I/O: pliki uploadowane przez formularz trafiają najpierw do katalogu tymczasowego, więc brak miejsca lub wolny dysk potrafi zatrzymać operację mimo „dobrych” limitów w php.ini.

I teraz ważne pytanie: czy WebFTP lub SSH rozwiązuje problem, skoro mowa o upload? Częściowo tak, ale zależy, na jakim etapie masz blokadę wynikającą z konfiguracji tego parametru.

Spójrz na to w ten sposób. WebFTP/FTP/SFTP/SSH omija limity upload_max_filesize i post_max_size, bo wtedy nie wysyłasz pliku przez PHP i HTTP, tylko wrzucasz go bezpośrednio na serwer. To świetne rozwiązanie, gdy problemem jest sam upload przez panel.

Natomiast nie omija limitów przetwarzania: max_execution_time, memory_limit albo ograniczenia aplikacji.

W praktyce przy dużych importach często najstabilniejsza jest ścieżka „serwerowa”: plik wrzucasz przez SFTP/SSH, a import wykonujesz narzędziem CLI (np. WP-CLI dla WordPressa albo mysql dla bazy), bo wtedy unikasz ograniczeń typowych dla żądań HTTP i paneli webowych.