WordPress error – Nie mogę wgrać zdjęć do biblioteki mediów – „HTTP error“, brak miniatur

Wrzucasz zdjęcie do biblioteki mediów, pasek postępu dochodzi prawie do końca i nagle pojawia się czerwony komunikat „HTTP error”. Albo plik niby się wgrywa, ale w bibliotece widzisz tylko szary kwadrat zamiast miniatury. Albo WordPress pisze, że nie może utworzyć katalogu. To jeden z tych problemów, z którymi klienci zgłaszają się do mnie regularnie, bo blokuje zwykłą, codzienną pracę: nie da się dodać produktu, wpisu ani podmienić zdjęcia na stronie głównej.

Dobra wiadomość jest taka, że przyczyn jest kilka i da się je sprawdzić po kolei. Poniżej pokazuję ścieżkę, którą sam przechodzę, kiedy diagnozuję problem z wgrywaniem plików. Zaczynam od rzeczy najprostszych, a kończę na tych, które wymagają dostępu do serwera.

Najpierw przeczytaj komunikat, bo on już coś mówi

Zanim zacznę cokolwiek zmieniać, zawsze sprawdzam, jaki dokładnie komunikat pokazuje WordPress. Każdy z nich prowadzi w trochę inne miejsce. W polskiej wersji panelu zobaczysz ich tłumaczenia, ale sens jest ten sam:

• „HTTP error” to najbardziej ogólny komunikat. Oznacza tylko tyle, że serwer nie odpowiedział tak, jak WordPress się spodziewał. Przyczyną może być limit pamięci, czas wykonania, przetwarzanie obrazu, wtyczka albo zapora na serwerze.
• „The server cannot process the image…” z sugestią, żeby wgrać mniejszy obraz (do 2500 pikseli). Plik dotarł na serwer, ale WordPressowi zabrakło zasobów, żeby wygenerować miniatury.
• „The uploaded file exceeds the upload_max_filesize directive in php.ini” to czysty limit rozmiaru pliku ustawiony w PHP.
• „Unable to create directory wp-content/uploads/2026/11. Is its parent directory writable by the server?” to problem z uprawnieniami albo ze ścieżką do katalogu uploads.
• „Sorry, you are not allowed to upload this file type” oznacza, że WordPress blokuje dany typ pliku albo zawartość pliku nie zgadza się z jego rozszerzeniem.
• „Missing a temporary folder” to brak katalogu tymczasowego na serwerze, czyli sprawa konfiguracji hostingu.

Jeśli nie ma żadnego komunikatu, a zdjęcia po prostu wyświetlają się jako szare pola, przejdź od razu do sekcji o brakujących miniaturach niżej.

Krok 1: szybkie testy, które zajmują dwie minuty

Zanim zajrzę do konfiguracji serwera, robię kilka prostych prób. Zaskakująco często któraś z nich od razu wskazuje winowajcę:

• Wgraj mały plik, na przykład zrzut ekranu o rozmiarze 200 KB. Jeśli przejdzie bez problemu, a duże zdjęcie nie, masz do czynienia z limitem rozmiaru albo zasobów.
• Zmień nazwę pliku na krótką, bez polskich znaków, spacji i nawiasów, na przykład zdjecie-produktu.jpg. Niektóre konfiguracje serwerów źle radzą sobie z nietypowymi znakami.
• Wyloguj się i zaloguj ponownie. Jeśli panel był otwarty od wielu godzin, sesja mogła wygasnąć i żądanie zostaje odrzucone.
• Spróbuj innej przeglądarki albo okna prywatnego. To wyklucza rozszerzenia blokujące skrypty i stary cache.
• Użyj prostego uploadera. W Media › Dodaj nowy plik WordPress pokazuje link do uploadera przeglądarkowego. Jeśli tą drogą plik się wgrywa, problem leży w obsłudze JavaScriptu, a nie w samym serwerze.

Krok 2: limity PHP, czyli najczęstsza przyczyna

Większość przypadków „HTTP error”, które naprawiam, kończy się na limitach PHP. Zdjęcie z telefonu ma dziś często 5 do 10 MB i rozdzielczość 4000 na 3000 pikseli, a domyślne ustawienia tańszych hostingów nie zawsze są na to gotowe.

Aktualne wartości sprawdzisz bez logowania na serwer: wejdź w Narzędzia › Kondycja witryny › Informacje i rozwiń sekcje „Serwer” oraz „Stałe WordPressa”. Interesują mnie cztery parametry:

• upload_max_filesize, czyli maksymalny rozmiar pojedynczego pliku,
• post_max_size, czyli maksymalny rozmiar całego żądania (musi być równy albo większy od poprzedniego),
• memory_limit, czyli pamięć dostępna dla PHP,
• max_execution_time, czyli czas, jaki skrypt ma na wykonanie zadania.

Jak je zwiększyć? Najpewniejsza droga to panel hostingu. Większość polskich firm hostingowych pozwala zmienić te wartości kilkoma kliknięciami w ustawieniach PHP. Jeśli takiej opcji nie ma, tworzę w głównym katalogu strony plik .user.ini z taką zawartością:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 120

Ważna rzecz, o której mało kto wie: zmiany w .user.ini mogą zacząć działać dopiero po kilku minutach, bo serwer odczytuje ten plik z opóźnieniem. Nie zakładaj od razu, że nie zadziałało.

Odradzam natomiast wpisywanie php_value do pliku .htaccess, jeśli nie wiesz, w jakim trybie działa PHP na Twoim serwerze. Na wielu hostingach skończy się to błędem 500 Internal Server Error na całej stronie.

Warto też pamiętać, że WordPress przy przetwarzaniu obrazów sam podnosi limit pamięci do wartości stałej WP_MAX_MEMORY_LIMIT (domyślnie 256 MB). Jeśli serwer na to nie pozwala, zdjęcie się wgra, ale miniatury już nie powstaną. Więcej o tym, kiedy zwiększanie pamięci pomaga, a kiedy tylko maskuje problem, pisałem we wpisie o błędzie „Allowed memory size exhausted”.

Krok 3: przetwarzanie obrazu, czyli Imagick kontra GD

Po wgraniu zdjęcia WordPress tworzy z niego kilka, a przy WooCommerce i rozbudowanych motywach nawet kilkanaście wersji w różnych rozmiarach. Robi to za pomocą jednej z dwóch bibliotek na serwerze: Imagick albo GD. To właśnie ten etap najczęściej „wysypuje się” przy dużych zdjęciach.

Od wersji 5.3 WordPress dodatkowo automatycznie zmniejsza bardzo duże obrazy do 2560 pikseli po dłuższym boku. To dobra zmiana, ale wymaga jeszcze więcej pracy od serwera przy samym wgrywaniu.

Co sprawdzam i co robię:

• Zmniejszam zdjęcie przed wgraniem. Na stronę internetową praktycznie nigdy nie potrzebujesz zdjęcia większego niż 2500 pikseli. To rozwiązuje problem od ręki, a przy okazji przyspiesza stronę. Jeśli prowadzisz sklep, przeczytaj też, dlaczego sklep WooCommerce działa wolno, bo ciężkie zdjęcia to jeden z głównych powodów.
• Sprawdzam, której biblioteki używa WordPress. Informację znajdziesz w Kondycji witryny, w sekcji „Obsługa obrazków”.
• Jeśli problem robi Imagick, przełączam WordPressa na GD. Na niektórych serwerach Imagick ma zbyt niskie limity zasobów i przerywa pracę przy większych plikach. Wystarczy taki fragment kodu:

add_filter( 'wp_image_editors', function() {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Ten kod dodaję jako osobną małą wtyczkę w katalogu wp-content/mu-plugins albo przez wtyczkę do fragmentów kodu. Nie wklejam go do functions.php motywu, bo zniknie przy pierwszej aktualizacji.

Osobna sprawa to nowe formaty. WordPress obsługuje WebP, a w nowszych wersjach także AVIF i zdjęcia HEIC z iPhone’a, ale tylko wtedy, gdy biblioteka na serwerze ma włączoną obsługę danego formatu. Jeśli zdjęcie w formacie HEIC lub AVIF się nie wgrywa, a JPG tak, to nie jest błąd WordPressa, tylko brak wsparcia po stronie serwera. Najprościej przekonwertować plik do JPG lub WebP przed wgraniem albo poprosić hosting o aktualizację bibliotek.

Krok 4: uprawnienia i ścieżka katalogu uploads

Komunikat „Unable to create directory” prawie zawsze oznacza, że serwer nie może zapisywać w katalogu wp-content/uploads. WordPress tworzy tam co miesiąc nowy podkatalog, więc problem potrafi pojawić się nagle, na przykład pierwszego dnia miesiąca, choć wcześniej wszystko działało.

Prawidłowe uprawnienia to:

• 755 dla katalogów,
• 644 dla plików.

Możesz je sprawdzić i poprawić przez klienta FTP (na przykład FileZilla) albo w menedżerze plików na hostingu. Jeśli masz dostęp do SSH, z poziomu głównego katalogu strony wystarczą dwa polecenia:

find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

Proszę, nie ustawiaj 777. Wiem, że to rada, która krąży po forach i „działa”, ale w praktyce otwiera katalog do zapisu dla każdego procesu na serwerze. Przy okazji sprzątania zainfekowanych stron bardzo często trafiam właśnie na uploads z uprawnieniami 777.

Jeśli uprawnienia są poprawne, a zapis nadal nie działa, sprawdzam jeszcze trzy rzeczy:

• Właściciela plików. Po przenoszeniu strony lub wgrywaniu plików przez SSH jako inny użytkownik katalog może należeć do konta, z którego PHP nie może pisać. To naprawia się poleceniem chown albo przez wsparcie hostingu.
• Miejsce na serwerze. Pełny dysk albo wyczerpany limit plików (inode) daje dokładnie takie same objawy. Sprawdzisz to w panelu hostingu. Częstym winowajcą są stare kopie zapasowe trzymane na tym samym koncie.
• Ścieżkę zapisaną w bazie. Po migracji z innego serwera w ustawieniach może zostać stara, absolutna ścieżka do katalogu uploads. Wejdź na adres /wp-admin/options.php i odszukaj pola upload_path oraz upload_url_path. W standardowej instalacji powinny być puste. Jeśli wpisana jest tam ścieżka z poprzedniego serwera, wyczyść je i zapisz zmiany.

Przy komunikacie o braku katalogu tymczasowego możesz wskazać WordPressowi własny katalog. Tworzę wtedy folder wp-content/tmp i dodaję w wp-config.php linijkę:

define( 'WP_TEMP_DIR', ABSPATH . 'wp-content/tmp' );

To jednak obejście. Brak katalogu tymczasowego to błąd konfiguracji serwera, który hosting powinien poprawić u siebie.

Krok 5: wtyczki, motyw i zapora serwera

Jeśli limity są w porządku, a uprawnienia poprawne, szukam konfliktu. Najczęściej przy wgrywaniu plików mieszają:

• wtyczki do optymalizacji obrazów, które kompresują zdjęcie zaraz po wgraniu i potrafią przekroczyć czas wykonania,
• wtyczki bezpieczeństwa, które blokują żądania wyglądające ich zdaniem podejrzanie,
• wtyczki i motywy rejestrujące dużo dodatkowych rozmiarów miniatur, przez co serwer przy każdym zdjęciu ma kilkanaście razy więcej pracy.

Najwygodniej sprawdzić to wtyczką Health Check & Troubleshooting. Jej tryb rozwiązywania problemów wyłącza wtyczki tylko dla Ciebie, więc odwiedzający widzą normalnie działającą stronę. Jeśli po aktualizacji coś przestało działać na dobre, pomoże Ci wpis o tym, jak wrócić do działającej wersji po aktualizacji wtyczki lub motywu.

Ostatni element tej układanki to zapora na serwerze, czyli najczęściej ModSecurity. Potrafi ona odrzucić wgrywany plik bez żadnego czytelnego komunikatu w WordPressie, a w panelu widzisz tylko „HTTP error”. Jeśli błąd pojawia się tylko przy niektórych plikach, a wszystkie inne testy wypadają dobrze, napisz do hostingu i poproś o sprawdzenie logów zapory dla konkretnej godziny, o której próbowałeś wgrać plik. Dla wsparcia technicznego to kilka minut pracy.

Krok 6: „niedozwolony typ pliku”

WordPress od lat sprawdza nie tylko rozszerzenie pliku, ale też jego rzeczywistą zawartość. Jeśli plik ma końcówkę .jpg, a w środku jest na przykład WebP (co zdarza się przy zdjęciach pobranych z internetu), wgrywanie zostanie zablokowane. Rozwiązanie jest proste: otwórz plik w programie graficznym i zapisz go ponownie we właściwym formacie.

Osobny przypadek to pliki SVG, które WordPress domyślnie blokuje i robi to celowo. Plik SVG to w rzeczywistości kod, w który da się wstrzyknąć złośliwy skrypt. Jeśli potrzebujesz SVG na stronie, używam wtyczki, która czyści zawartość pliku przy wgrywaniu (na przykład Safe SVG). Nie odblokowuję wszystkich typów plików jednym fragmentem kodu z forum.

Zdjęcie się wgrało, ale nie ma miniatury

To osobna grupa problemów i warto ją rozdzielić, bo wygląda podobnie, a przyczyny są różne.

Miniatury nie zostały wygenerowane

Jeśli w bibliotece mediów widzisz szary kwadrat z ikoną pliku, a po kliknięciu oryginał otwiera się normalnie, to plik dotarł na serwer, ale przetwarzanie się nie udało. Wracamy wtedy do kroków 2 i 3. Po usunięciu przyczyny nie musisz wgrywać wszystkiego od nowa: wystarczy wtyczka Regenerate Thumbnails albo, jeśli masz dostęp do WP-CLI, polecenie wp media regenerate.

Regeneracja przydaje się też po zmianie motywu. Nowy motyw często używa innych rozmiarów zdjęć niż poprzedni, więc stare obrazki wyświetlają się rozmazane albo źle przycięte. W sklepie widać to szczególnie na kartach produktów, o których budowie pisałem w artykule o tym, jak zbudować stronę produktu w WooCommerce.

Miniatury istnieją, ale się nie wyświetlają

Jeśli pliki miniatur są na serwerze, a przeglądarka ich nie pokazuje, sprawdzam:

• Adresy obrazków. Kliknij prawym przyciskiem na brakujący obrazek i otwórz go w nowej karcie. Jeśli adres zaczyna się od http://, a strona działa na https://, to klasyczny problem opisany we wpisie o mixed content po włączeniu SSL. Jeśli adres wskazuje na starą domenę, to pozostałość po migracji.
• Uprawnienia samych plików. Plik z uprawnieniami 600 istnieje, ale serwer odmawia jego wyświetlenia i zwraca błąd 403.
• Ochronę przed hotlinkowaniem lub CDN. Źle skonfigurowana reguła potrafi zablokować obrazki nawet na własnej stronie.

Biblioteka mediów w ogóle się nie ładuje

Jeśli biblioteka w widoku siatki kręci się bez końca albo jest pusta, choć pliki są na serwerze, to zwykle błąd JavaScriptu lub zapytania AJAX, a nie problem z samymi obrazkami. Przełącz bibliotekę na widok listy (ikona obok siatki). Jeśli w widoku listy wszystko widać, szukaj konfliktu wtyczek. Podobny mechanizm stoi za błędem „Updating failed. The response is not a valid JSON response” i za zawieszającym się edytorem, o którym pisałem przy okazji wpisu Elementor nie działa.

Przy okazji: zadbaj o bezpieczeństwo katalogu uploads

Skoro już zaglądasz do katalogu wp-content/uploads, rozejrzyj się w nim. Powinny tam być wyłącznie obrazki, dokumenty i inne pliki multimedialne. Jeśli znajdziesz pliki .php, zwłaszcza o dziwnych nazwach, to bardzo poważny sygnał, że strona została zainfekowana. W takiej sytuacji zajrzyj do mojego poradnika, jak odwirusować stronę WordPress.

Na serwerach z Apache profilaktycznie dodaję w katalogu uploads plik .htaccess, który blokuje uruchamianie skryptów PHP:

<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>

Na serwerach z Nginx taką regułę ustawia się w konfiguracji serwera, więc trzeba poprosić o to hosting.

Ściąga: objaw, przyczyna, rozwiązanie

Objaw	Najczęstsza przyczyna	Co zrobić
„HTTP error” przy dużych zdjęciach	Limit pamięci lub czasu, przetwarzanie obrazu	Zmniejsz zdjęcie, podnieś limity PHP, ewentualnie przełącz na GD
„HTTP error” przy wszystkich plikach	Wtyczka, zapora serwera, wygasła sesja	Zaloguj się ponownie, tryb rozwiązywania problemów, logi zapory u hostingu
Przekroczony upload_max_filesize	Za niski limit rozmiaru pliku	Zwiększ upload_max_filesize i post_max_size
Nie można utworzyć katalogu	Uprawnienia, właściciel, pełny dysk, stara ścieżka w bazie	755 i 644, sprawdź miejsce na serwerze i upload_path
Niedozwolony typ pliku	Format zablokowany lub niezgodny z rozszerzeniem	Zapisz plik ponownie we właściwym formacie, SVG tylko przez wtyczkę czyszczącą
Szare miniatury	Nieudane generowanie rozmiarów	Usuń przyczynę i zregeneruj miniatury
Miniatury są, ale się nie wyświetlają	Mixed content, stara domena, uprawnienia plików	Popraw adresy i uprawnienia

Problem z wgrywaniem zdjęć wygląda poważnie, bo komunikat „HTTP error” niewiele mówi, ale w większości przypadków kończy się na jednej z trzech rzeczy: zbyt dużym zdjęciu przy niskich limitach serwera, złych uprawnieniach katalogu uploads albo wtyczce, która miesza przy przetwarzaniu obrazów. Przejdź kroki po kolei, a przyczyna zwykle wyjdzie już w pierwszych trzech.

Jeśli sprawdziłeś wszystko z tej listy, a zdjęcia nadal się nie wgrywają, albo po prostu nie chcesz grzebać w plikach serwera, napisz do mnie. Zdiagnozuję problem na Twojej stronie i powiem wprost, czy leży po stronie WordPressa, czy hostingu.