Błąd HTTP przy wgrywaniu zdjęć do biblioteki mediów. 6 możliwych przyczyn

Zdjęcie wybrane, pasek postępu dochodzi do końca, a zamiast miniatury w bibliotece mediów pojawia się czerwona ramka z dwoma słowami: „Błąd HTTP”. WordPress nie podaje przy tym żadnej przyczyny, dlatego wiele osób powtarza wgrywanie kilkanaście razy i za każdym razem dostaje ten sam wynik.

Ten komunikat jest ogólny z założenia. Oznacza tylko tyle, że serwer nie odpowiedział poprawnie w chwili, gdy przyjmował plik albo gdy przygotowywał z niego mniejsze wersje obrazka. Powodów może być sześć i każdy naprawia się inaczej, dlatego zgadywanie zwykle kończy się stratą czasu.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną na WordPressie. Po lekturze będzie wiadomo, jak w kilka minut ustalić, która przyczyna zachodzi w danej witrynie, jak ją usunąć, po czym poznać, że naprawa się udała, i kiedy sprawę trzeba przekazać firmie hostingowej.

Co oznacza komunikat „Błąd HTTP” i kiedy się pojawia?

Wgranie zdjęcia do WordPressa składa się z dwóch etapów. Najpierw przeglądarka wysyła plik na serwer. Potem serwer otwiera obrazek i tworzy z niego kilka mniejszych wersji: miniaturę, rozmiar średni, duży oraz rozmiary zadeklarowane przez motyw i wtyczki. Ten drugi etap wymaga dużo pamięci i czasu, i to on zawodzi najczęściej.

Jeśli serwer na którymkolwiek etapie przerwie pracę albo odpowie czymś innym niż oczekiwane potwierdzenie, WordPress pokazuje w bibliotece mediów „Błąd HTTP”. W nowszych wersjach systemu w części takich sytuacji pojawia się dłuższy komunikat: informacja, że serwer nie zdołał przetworzyć obrazka, razem z sugestią, by przesłać mniejszy plik o boku nie dłuższym niż 2560 pikseli. Oba komunikaty mają te same źródła i naprawia się je tak samo.

Sześć przyczyn, które trzeba wziąć pod uwagę

Z mojej praktyki wynika, że za tym komunikatem stoi jedna z sześciu przyczyn. Kolejność na liście odpowiada kolejności, w jakiej najrozsądniej je sprawdzać: od najprostszych do wymagających dostępu do serwera.

• Chwilowa usterka – przeciążony serwer, zerwane połączenie albo wygasła sesja w kokpicie.
• Zdjęcie zbyt duże dla serwera – za dużo pikseli lub za duża waga pliku w stosunku do limitu pamięci PHP i czasu wykonywania skryptu.
• Biblioteka Imagick – moduł, którym serwer obrabia obrazki, ma na danym hostingu zbyt ciasne limity zasobów.
• Konflikt wtyczki lub motywu – najczęściej dodatek do optymalizacji zdjęć, zabezpieczeń albo przenoszenia mediów na zewnętrzny serwer.
• Blokada lub limit po stronie hostingu – zapora serwera, limit wielkości żądania albo limit czasu ustawiony poza WordPressem.
• Brak możliwości zapisu – złe uprawnienia katalogu z mediami albo wyczerpane miejsce na koncie.

Od czego zacząć, zanim zmieni się cokolwiek na serwerze?

Pierwsze czynności nie wymagają żadnej wiedzy technicznej i zajmują kilka minut. Rozstrzygają o dwóch sprawach: czy błąd był jednorazowy i czy zależy od konkretnego pliku. Bez tej wiedzy dalsze poszukiwania są prowadzone po omacku.

1. Należy odczekać dwie lub trzy minuty i wgrać to samo zdjęcie ponownie. Jeśli serwer był chwilowo zajęty, drugie podejście się powiedzie.
2. Trzeba odświeżyć stronę kokpitu. Jeżeli pojawi się formularz logowania, sesja wygasła i to ona była powodem błędu. Po zalogowaniu wgrywanie powinno działać.
3. Kolejna próba powinna odbyć się w innej przeglądarce albo w oknie prywatnym, w którym nie działają rozszerzenia. Rozszerzenia blokujące reklamy i skrypty potrafią przerwać wysyłkę pliku.
4. Warto wgrać małą grafikę testową, na przykład zrzut ekranu o wadze kilkudziesięciu kilobajtów. Jeśli mały plik przechodzi, a duże zdjęcie nie, przyczyna leży w rozmiarze obrazka lub w zasobach serwera.
5. Nazwę pliku należy zmienić na prostą: małe litery bez polskich znaków, cyfry i dywizy, bez spacji, apostrofów i nawiasów, na przykład biuro-recepcja-01.jpg. Część serwerów odrzuca nazwy z nietypowymi znakami.
6. Ten sam obrazek można zapisać w innym formacie, na przykład JPG zamiast PNG, i wgrać ponownie. Uszkodzony albo nietypowo zapisany plik po ponownym zapisie w programie graficznym zwykle przestaje sprawiać kłopot.

Po tych sześciu próbach sytuacja jest już dużo jaśniejsza. Błąd, który zniknął po odczekaniu lub ponownym zalogowaniu, był chwilową usterką i nie wymaga dalszych działań. Błąd, który dotyczy tylko dużych zdjęć, kieruje do sekcji o rozmiarze pliku, pamięci i bibliotece Imagick. Błąd, który dotyczy każdego pliku, nawet najmniejszego, wskazuje na wtyczkę, zaporę serwera albo brak możliwości zapisu.

Jak podejrzeć prawdziwy kod odpowiedzi serwera?

Za ogólnym komunikatem kryje się zawsze konkretny kod odpowiedzi, a przeglądarka potrafi go pokazać. To najszybszy sposób, by zawęzić poszukiwania. W przeglądarce Chrome, Edge lub Firefox należy nacisnąć klawisz F12, przejść do karty „Sieć” i przy otwartym panelu wgrać zdjęcie jeszcze raz.

Na liście żądań pojawi się wiersz zaznaczony na czerwono. W bibliotece mediów ma on w nazwie async-upload.php, a w edytorze blokowym adres kończy się na /wp-json/wp/v2/media. W kolumnie ze stanem widać liczbę, która wiele mówi o przyczynie.

• 413 – serwer uznał, że przesyłane żądanie jest za duże. To limit serwera, nie WordPressa.
• 403 – żądanie zostało zablokowane, zwykle przez zaporę serwera albo wtyczkę zabezpieczającą.
• 500 – skrypt PHP przerwał pracę, najczęściej z powodu wyczerpanej pamięci lub błędu we wtyczce.
• 502, 503 lub 504 – serwer nie zdążył obsłużyć żądania w wyznaczonym czasie albo proces został zatrzymany.

Kod 500 w połączeniu z dużym zdjęciem bardzo często oznacza brak pamięci. Kody 502 i 504 przy dużych plikach wskazują na zbyt długie przetwarzanie.

Gdzie w kokpicie odczytać ustawienia serwera dotyczące mediów?

WordPress ma wbudowany ekran, który pokazuje wszystkie parametry potrzebne do dalszej diagnozy. Niczego na nim nie da się zmienić ani zepsuć, bo służy wyłącznie do odczytu. Znajduje się w menu „Narzędzia”, w pozycji „Stan witryny”.

1. W kokpicie należy przejść do menu „Narzędzia” i wybrać „Stan witryny”.
2. U góry ekranu trzeba przełączyć się z karty „Status” na kartę „Informacje”.
3. Na liście sekcji należy rozwinąć tę, która dotyczy obsługi mediów. W jej pierwszym wierszu widać aktywny edytor obrazków: WP_Image_Editor_Imagick albo WP_Image_Editor_GD.
4. W tej samej sekcji trzeba odczytać maksymalny rozmiar danych przesyłanych w jednym żądaniu oraz maksymalny rozmiar pojedynczego pliku. Mniejsza z tych dwóch wartości jest rzeczywistym limitem wgrywania.
5. Następnie należy rozwinąć sekcję „Serwer” i zanotować wersję PHP, limit pamięci PHP oraz maksymalny czas wykonywania skryptu.
6. Na końcu warto rozwinąć sekcję o uprawnieniach systemu plików. Przy katalogu przesyłanych plików powinna widnieć informacja, że WordPress może w nim zapisywać.

Odczytane wartości od razu podpowiadają kierunek. Limit wgrywania mniejszy niż waga zdjęcia oznacza, że plik nie ma prawa przejść. Jak go podnieść, opisałem w tekście o tym, jak zwiększyć limit wgrywanych plików. Niski limit pamięci przy aktywnym edytorze Imagick kieruje do dwóch kolejnych sekcji.

Czy zdjęcie nie jest po prostu za duże dla serwera?

To najczęstsza przyczyna i zarazem najłatwiejsza do usunięcia. Zdjęcie z telefonu lub aparatu ma zwykle kilka tysięcy pikseli szerokości. Na stronie internetowej tak duży obraz nie jest potrzebny, a serwer musi go w całości rozpakować w pamięci, żeby przygotować mniejsze wersje.

Liczy się przy tym liczba pikseli, a nie tylko waga pliku. Mocno skompresowany plik JPG o wadze trzech megabajtów po otwarciu może zająć w pamięci serwera kilkadziesiąt razy więcej. Dlatego zdjęcie, które mieści się w limicie wgrywania, i tak potrafi wyczerpać pamięć podczas przetwarzania.

WordPress sam próbuje ograniczyć ten problem. Obrazek, którego szerokość lub wysokość przekracza 2560 pikseli, jest po wgraniu automatycznie pomniejszany do tego rozmiaru, a pomniejszona wersja dostaje w nazwie dopisek -scaled. Oryginał pozostaje na serwerze. Pomniejszenie również wymaga jednak otwarcia całego oryginału, więc przy bardzo dużych plikach to właśnie ten etap kończy się błędem.

Jak przygotować zdjęcie przed wgraniem?

Najprościej zmniejszyć zdjęcie na komputerze, zanim trafi do WordPressa. Wystarczy do tego dowolny program graficzny albo systemowa przeglądarka zdjęć, która ma funkcję zmiany rozmiaru.

Dłuższy bok obrazka powinien mieć najwyżej 2560 pikseli, bo większego rozmiaru WordPress i tak nie użyje. W większości zastosowań, takich jak zdjęcia we wpisach, oferta czy galeria realizacji, w zupełności wystarcza bok o długości około 1800 pikseli. Fotografie najlepiej zapisywać w formacie JPG lub WebP, a format PNG zostawić dla grafik z przezroczystym tłem, zrzutów ekranu i logotypów.

Jeśli pomniejszone zdjęcie wgrywa się bez błędu, przyczyna została potwierdzona. Można na tym poprzestać i przyjąć zasadę, że każde zdjęcie przed wgraniem jest zmniejszane. Jeśli jednak strona ma przyjmować duże zdjęcia bez wcześniejszego przygotowania, trzeba zwiększyć zasoby serwera.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, która z sześciu przyczyn blokuje wgrywanie zdjęć w danej witrynie, usunę ją i sprawdzę, czy biblioteka mediów przyjmuje pliki bez błędów.

Jak zwiększyć limit pamięci, gdy serwer nie radzi sobie z obróbką zdjęć?

Jeśli małe zdjęcia przechodzą, duże kończą się błędem, a w karcie „Sieć” widać kod 500, najbardziej prawdopodobnym powodem jest zbyt niski limit pamięci PHP. Obowiązujący limit pokazuje sekcja „Serwer” na ekranie „Stan witryny”.

Limit można podnieść na dwa sposoby. Pierwszy to panel firmy hostingowej, w którym zazwyczaj znajduje się miejsce z ustawieniami PHP i pole o nazwie memory_limit. To droga pewniejsza, bo zmiana obowiązuje dla całego konta. Drugi sposób to wpis w pliku wp-config.php, którym WordPress prosi serwer o więcej pamięci.

Zgodnie z dokumentacją WordPress domyślnie próbuje ustawić 40 MB pamięci dla zwykłej witryny i 64 MB dla sieci witryn. W kokpicie, a więc także podczas wgrywania zdjęć, obowiązuje osobna, wyższa wartość określana stałą WP_MAX_MEMORY_LIMIT. Obie stałe można zdefiniować samodzielnie.

1. Przed zmianą należy pobrać na komputer kopię pliku wp-config.php. Plik leży w głównym katalogu WordPressa i jest dostępny przez menedżer plików w panelu hostingu albo przez FTP.
2. Plik trzeba otworzyć do edycji i odszukać wiersz, który wczytuje plik wp-settings.php. Znajduje się on na samym końcu.
3. Powyżej tego wiersza wpisuje się dwie linie: define( 'WP_MEMORY_LIMIT', '128M' ); oraz define( 'WP_MAX_MEMORY_LIMIT', '256M' );. Dokumentacja zastrzega, że stałe umieszczone poniżej tego wiersza nie zadziałają.
4. Po zapisaniu pliku należy wrócić na ekran „Stan witryny” i sprawdzić w sekcji „Serwer”, czy limit pamięci się zmienił.
5. Na koniec trzeba ponownie wgrać zdjęcie, które wcześniej powodowało błąd.

Trzeba mieć świadomość ograniczeń tej metody. Dokumentacja WordPressa mówi wprost, że część firm hostingowych nie pozwala na samodzielne podnoszenie limitu pamięci. Jeśli po zmianie wartość na ekranie „Stan witryny” pozostała taka sama, wpis w pliku został zignorowany i limit musi podnieść pomoc techniczna hostingu.

Nie radzę wpisywać wartości na wyrost. Limit ustawiony bardzo wysoko niczego nie przyspiesza, a potrafi ukryć prawdziwy problem, na przykład wadliwą wtyczkę, która zużywa nadmierną ilość pamięci. Więcej o bezpiecznym doborze wartości piszę w tekście o komunikacie „Allowed memory size exhausted”.

Drugim parametrem z tej samej grupy jest maksymalny czas wykonywania skryptu. Jeśli serwer jest wolny, a zdjęcie duże, przygotowanie wszystkich rozmiarów może trwać dłużej, niż pozwala limit. Zmienia się go w panelu hostingu, w ustawieniach PHP, w polu max_execution_time.

Kiedy zawodzi biblioteka Imagick i jak przełączyć WordPressa na GD?

WordPress obrabia obrazki za pomocą jednej z dwóch bibliotek zainstalowanych na serwerze: Imagick albo GD. Jeśli dostępne są obie, system w pierwszej kolejności wybiera Imagick, a GD traktuje jako rozwiązanie zapasowe. Która z nich pracuje w danej witrynie, pokazuje wiersz z aktywnym edytorem na ekranie „Stan witryny”.

Imagick daje dobrą jakość, ale ma własne limity zasobów, niezależne od limitu pamięci PHP. Na współdzielonych serwerach bywają one ustawione bardzo oszczędnie. Skutek jest wtedy mylący: pamięć PHP została podniesiona, a duże zdjęcia nadal kończą się błędem, bo proces obróbki zatrzymuje sama biblioteka.

Najprostszym testem jest czasowe przełączenie WordPressa na bibliotekę GD. Służy do tego filtr wp_image_editors, który ustala kolejność edytorów. Poniższy fragment należy wkleić przez wtyczkę do dodawania własnych fragmentów kodu albo do pliku functions.php motywu potomnego.

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

Po zapisaniu należy odświeżyć ekran „Stan witryny” i upewnić się, że aktywnym edytorem jest WP_Image_Editor_GD, a następnie wgrać problematyczne zdjęcie. Jeśli błąd ustąpił, przyczyną były limity biblioteki Imagick.

W takiej sytuacji są dwie drogi. Można zostawić GD na stałe, bo dla zdjęć na stronie firmowej różnica w jakości jest zwykle niezauważalna. Można też poprosić hosting o zwiększenie limitów Imagick i po potwierdzeniu usunąć dodany fragment kodu. Jeżeli przełączenie niczego nie zmieniło, kod trzeba usunąć, żeby nie zostawiać w witrynie zbędnych modyfikacji.

Jedna uwaga dotycząca bezpieczeństwa. Wklejanie kodu bezpośrednio do pliku functions.php motywu głównego jest ryzykowne: literówka może wyłączyć całą witrynę, a aktualizacja motywu usunie zmianę. Bezpieczniejsza jest wtyczka do fragmentów kodu, która pozwala wyłączyć wadliwy wpis.

Jak sprawdzić, czy błąd wywołuje wtyczka albo motyw?

Wtyczki często włączają się w proces wgrywania. Dodatki do optymalizacji kompresują obrazek zaraz po przesłaniu, dodatki do znaków wodnych nakładają grafikę, a wtyczki przenoszące media do zewnętrznego magazynu wysyłają plik dalej. Każda z tych operacji zużywa czas i pamięć, a błąd w którejkolwiek kończy się tym samym ogólnym komunikatem.

Podejrzenie pada na wtyczkę szczególnie wtedy, gdy błąd pojawił się po instalacji lub aktualizacji dodatku albo gdy dotyczy każdego pliku bez względu na rozmiar. Test najlepiej przeprowadzić na kopii testowej witryny. Jeśli jej nie ma, trzeba wybrać porę najmniejszego ruchu, bo na czas testu część funkcji strony przestanie działać.

1. Przed testem należy wykonać pełną kopię witryny. Jak zrobić to poprawnie, wyjaśniam w tekście o tym, jak przygotować kopię zapasową WordPressa, która naprawdę działa.
2. W menu „Wtyczki” trzeba w pierwszej kolejności wyłączyć dodatki związane z obrazkami: optymalizację zdjęć, znaki wodne, zewnętrzny magazyn mediów, a także wtyczki zabezpieczające.
3. Po wyłączeniu należy wgrać zdjęcie testowe. Jeśli błąd zniknął, winna jest jedna z wyłączonych wtyczek.
4. Wtyczki włącza się z powrotem pojedynczo i po każdej ponawia wgrywanie. Ta, po której błąd wraca, jest przyczyną.
5. Jeśli wyłączenie wtyczek z tej grupy nie pomogło, test trzeba powtórzyć dla pozostałych, a na końcu w menu „Wygląd” przełączyć witrynę na jeden z domyślnych motywów WordPressa.
6. Po zakończeniu testu należy przywrócić właściwy motyw i włączyć wszystkie potrzebne wtyczki.

Znalezienie winnej wtyczki nie oznacza, że trzeba z niej zrezygnować. Najpierw warto ją zaktualizować i przejrzeć jej ustawienia. W dodatkach do optymalizacji pomaga zwykle wyłączenie kompresji w chwili wgrywania i pozostawienie jej do wykonania w tle. Jeśli to nie wystarcza, pozostaje zgłoszenie do autora wtyczki albo wymiana na inną.

Co może blokować wgrywanie po stronie serwera?

Część ograniczeń leży poza WordPressem i z poziomu kokpitu nie da się ich zmienić. Wskazują na nie kody 413, 403 oraz 502, 503 i 504 widoczne w karcie „Sieć”, a także sytuacja, w której żadna z wcześniejszych metod nie przyniosła skutku.

Limit wielkości żądania

Serwer WWW ma własny limit rozmiaru przyjmowanych danych, niezależny od ustawień PHP. Gdy plik go przekracza, serwer odrzuca żądanie, zanim WordPress w ogóle je zobaczy, i odpowiada kodem 413. Taki limit zmienia wyłącznie administrator serwera, więc na hostingu współdzielonym potrzebne jest zgłoszenie do pomocy technicznej.

Zapora serwera

Wiele firm hostingowych stosuje zaporę, która analizuje każde żądanie i blokuje te, które przypominają atak. Zdarza się, że regułę uruchamia zwykłe zdjęcie albo nietypowa nazwa pliku. Objawem jest kod 403 i błąd, który dotyczy tylko niektórych plików. Zapory nie należy wyłączać samodzielnie w całości, bo chroni ona witrynę. Właściwą drogą jest prośba do hostingu o sprawdzenie dziennika zapory i dodanie wyjątku dla konkretnej reguły.

Limit czasu i liczby procesów

Kody 502, 503 i 504 oznaczają, że proces obsługujący wgrywanie został zatrzymany albo nie zdążył odpowiedzieć. Na tanich pakietach powodem bywa limit jednoczesnych procesów lub obciążenie procesora przypisane do konta.

Uprawnienia katalogu i miejsce na koncie

Ostatnia z sześciu przyczyn dotyczy samego zapisu. Wgrane zdjęcia trafiają do katalogu wp-content/uploads, domyślnie do podkatalogów z podziałem na lata i miesiące. Jeśli WordPress nie ma prawa zapisu w tym miejscu albo na koncie skończyło się miejsce, wgrywanie nie powiedzie się dla żadnego pliku.

Uprawnienia sprawdza się na ekranie „Stan witryny”, w sekcji o uprawnieniach systemu plików. Informacja o braku możliwości zapisu przy katalogu przesyłanych plików potwierdza tę przyczynę. Problem pojawia się najczęściej po przeniesieniu strony na inny serwer albo po ręcznym wgraniu plików przez FTP z innego konta.

Dokumentacja WordPressa zaleca dla katalogów uprawnienia 755 lub 750, a dla plików 644 lub 640. Zmienia się je w menedżerze plików panelu hostingu albo w programie FTP, we właściwościach katalogu uploads, z zastosowaniem zmiany do podkatalogów. Jeśli po ustawieniu wartości 755 zapis nadal nie działa, katalog ma niewłaściwego właściciela i poprawić to może tylko hosting.

Jednego rozwiązania stanowczo odradzam: ustawienia uprawnień 777. Taką radę można znaleźć na wielu forach i rzeczywiście usuwa ona błąd, ale dokumentacja WordPressa mówi jednoznacznie, że żaden katalog, także katalog z przesyłanymi plikami, nie powinien mieć takich uprawnień. Otwierają one drogę do zapisania na serwerze obcych plików.

Wolne miejsce widać w panelu hostingu, zwykle na stronie głównej konta. Oprócz pojemności w megabajtach wiele firm limituje też liczbę plików. Każde wgrane zdjęcie to w praktyce kilka lub kilkanaście plików, bo WordPress zapisuje wszystkie rozmiary osobno, więc ten drugi limit wyczerpuje się szybciej, niż można się spodziewać.

Jak napisać zgłoszenie do hostingu?

Pomoc techniczna odpowiada szybciej i trafniej, gdy od razu dostaje konkretne dane. Poniżej znajduje się treść, którą wystarczy uzupełnić i wysłać.

Dzień dobry, przy wgrywaniu zdjęć do biblioteki mediów WordPressa w domenie [adres strony] pojawia się błąd HTTP. Żądanie do pliku wp-admin/async-upload.php kończy się kodem [kod z karty Sieć]. Ostatnia próba miała miejsce o godzinie [godzina], plik ważył [waga] i miał wymiary [szerokość x wysokość] pikseli. Proszę o sprawdzenie dziennika błędów serwera i dziennika zapory z tej godziny oraz o informację, który limit został przekroczony: pamięć PHP, czas wykonywania, wielkość żądania czy limity biblioteki Imagick. W załączeniu raport z ekranu Stan witryny.

Jak znaleźć dokładną przyczynę w dzienniku błędów?

Gdy testy nie dały jednoznacznej odpowiedzi, pozostaje dziennik błędów. To plik, w którym serwer zapisuje dokładną przyczynę każdego przerwanego skryptu, razem z nazwą pliku i numerem wiersza. Większość paneli hostingowych udostępnia go w osobnej zakładce z dziennikami lub logami.

WordPress ma też własny dziennik, który włącza się w pliku wp-config.php. Powyżej wiersza wczytującego wp-settings.php wpisuje się trzy linie:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Trzecia linia jest ważna, bo zapobiega wyświetlaniu błędów odwiedzającym stronę. Po zapisaniu pliku należy ponownie wgrać zdjęcie, a następnie otworzyć plik wp-content/debug.log i przeczytać ostatnie wiersze.

Wpis zawierający słowa „Allowed memory size” oznacza brak pamięci. Wpis ze słowami „Maximum execution time” oznacza przekroczony czas, o czym piszę w tekście o błędzie „Maximum execution time exceeded”. Ścieżka zawierająca nazwę katalogu konkretnej wtyczki wskazuje winowajcę z nazwy. Brak jakiegokolwiek wpisu z chwili wgrywania sugeruje, że żądanie zatrzymał serwer lub zapora, zanim dotarło do WordPressa.

Po zakończeniu diagnozy dziennik trzeba wyłączyć, zmieniając wartość true przy WP_DEBUG na false, a plik debug.log usunąć z serwera. Dokumentacja WordPressa ostrzega, że dziennik pozostawiony w publicznie dostępnym miejscu jest zagrożeniem dla bezpieczeństwa, bo zawiera ścieżki i szczegóły konfiguracji.

Po czym poznać, że naprawa zadziałała, i jakich błędów unikać?

Jedno udane wgranie nie jest jeszcze dowodem. Błąd zależny od obciążenia serwera potrafi zniknąć na godzinę i wrócić. Dlatego po każdej zmianie należy przeprowadzić ten sam, pełny test.

Test polega na wgraniu tego samego zdjęcia, które wcześniej wywoływało błąd, bez żadnych przeróbek. Po wgraniu w bibliotece mediów powinna pojawić się miniatura, a nie szary prostokąt. Po kliknięciu w obrazek w szczegółach załącznika powinny być widoczne jego wymiary. Następnie zdjęcie trzeba wstawić do roboczego wpisu i sprawdzić w ustawieniach bloku obrazka, czy dostępne są różne rozmiary: miniatura, średni i duży. Ich obecność potwierdza, że serwer zakończył przetwarzanie.

Zdjęcia, które podczas wcześniejszych nieudanych prób trafiły do biblioteki bez miniatur, najlepiej usunąć i wgrać ponownie. Pozostawione będą wyświetlały się na stronie w pełnym rozmiarze albo wcale.

Czego nie robić podczas naprawy?

• Nie należy ustawiać uprawnień 777 dla katalogu z mediami ani dla żadnego innego.
• Nie należy wprowadzać kilku zmian jednocześnie, bo po udanym teście nie będzie wiadomo, która pomogła, a pozostałe zostaną w witrynie bez potrzeby.
• Nie należy edytować pliku wp-config.php ani .htaccess bez kopii poprzedniej wersji zapisanej na komputerze.
• Nie należy zostawiać włączonego dziennika błędów ani testowego kodu po zakończeniu diagnozy.
• Nie należy wyłączać na stałe zapory ani wtyczki zabezpieczającej tylko po to, by wgrać zdjęcie.
• Nie należy wgrywać wielokrotnie tego samego pliku z nadzieją, że w końcu przejdzie. Każda nieudana próba może zostawić na serwerze osierocone pliki.

Najczęstsze pytania

Dlaczego małe grafiki wgrywają się bez problemu, a zdjęcia z telefonu nie?

Zdjęcie z telefonu ma wielokrotnie więcej pikseli niż ikona czy zrzut ekranu. Serwer musi otworzyć je w całości w pamięci i przygotować kilka mniejszych wersji, a na to potrzeba znacznie więcej pamięci i czasu. Gdy limity serwera są niskie, przetwarzanie zostaje przerwane i pojawia się błąd. Pomaga zmniejszenie zdjęcia przed wgraniem albo podniesienie limitu pamięci PHP.

Czy błąd HTTP oznacza, że strona została zainfekowana?

Sam ten komunikat nie świadczy o włamaniu. W ogromnej większości przypadków chodzi o zasoby serwera, wtyczkę albo uprawnienia. Niepokój powinny wzbudzić dopiero dodatkowe objawy: nieznane pliki w katalogu z mediami, nowi użytkownicy w kokpicie albo przekierowania na obce strony. Wtedy witrynę trzeba sprawdzić pod kątem złośliwego kodu.

Zdjęcie pojawiło się w bibliotece mimo błędu. Czy można go używać?

Lepiej tego nie robić. Taki plik został zapisany, ale serwer nie zdążył przygotować mniejszych wersji albo przygotował tylko część z nich. Na stronie będzie wczytywany oryginał w pełnym rozmiarze, co spowolni podstronę, a w niektórych miejscach motywu obrazek może nie wyświetlić się wcale. Po usunięciu przyczyny błędu plik należy usunąć z biblioteki i wgrać ponownie.

Czy przełączenie z Imagick na GD pogorszy jakość zdjęć na stronie?

Przy typowych zdjęciach na stronie firmowej różnica jest w praktyce niezauważalna. Imagick lepiej radzi sobie z niektórymi nietypowymi plikami i zachowuje więcej informacji o kolorach, co ma znaczenie głównie w serwisach fotograficznych. Jeśli jakość ma pierwszorzędne znaczenie, lepszym rozwiązaniem niż stałe przełączenie jest prośba do hostingu o zwiększenie limitów biblioteki Imagick.

Czy wystarczy zwiększyć maksymalny rozmiar wgrywanego pliku?

Zwykle nie. Limit wielkości pliku decyduje tylko o tym, czy serwer w ogóle przyjmie plik. Błąd HTTP pojawia się najczęściej na następnym etapie, czyli podczas przetwarzania obrazka, i wtedy liczą się limit pamięci, czas wykonywania skryptu oraz limity biblioteki graficznej. Podniesienie samego limitu wgrywania pomaga jedynie wtedy, gdy serwer odpowiada kodem 413 albo plik jest cięższy niż limit widoczny na ekranie „Stan witryny”.

Czy starsza wersja PHP może być powodem błędu?

Może się do niego przyczyniać. Nowsze wersje PHP działają szybciej i oszczędniej gospodarują pamięcią, więc ta sama operacja ma większe szanse zmieścić się w limitach. Wersję PHP pokazuje sekcja „Serwer” na ekranie „Stan witryny”, a karta „Status” ostrzega, gdy jest przestarzała. Zmiany dokonuje się w panelu hostingu, po wykonaniu kopii zapasowej i sprawdzeniu, czy motyw oraz wtyczki są zaktualizowane.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Szukanie przyczyny błędu, który sam nic o sobie nie mówi, potrafi zająć cały wieczór, zwłaszcza gdy trzeba przy tym zaglądać do plików na serwerze. Chętnie zrobię to od początku do końca: sprawdzę ustawienia serwera i bibliotekę obrabiającą obrazki, przetestuję wtyczki i motyw, przejrzę dziennik błędów, poprawię limity lub uprawnienia, a jeśli będzie trzeba, przygotuję zgłoszenie do firmy hostingowej. Na koniec upewnię się, że zdjęcia wgrywają się poprawnie, i opiszę prostymi słowami, co było przyczyną.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co dzieje się podczas wgrywania zdjęć.