„Allowed memory size exhausted”. Jak bezpiecznie zwiększyć limit pamięci PHP?

Strona na WordPressie nagle pokazuje biały ekran, kokpit zatrzymuje się w połowie aktualizacji, a w dzienniku błędów pojawia się wiersz zaczynający się od słów „Allowed memory size of”. Ten komunikat oznacza jedno: skrypt PHP próbował zająć więcej pamięci, niż pozwala mu serwer, i został przerwany. Witryna nie została przez to uszkodzona, ale dopóki przyczyna nie zniknie, ta sama czynność będzie kończyła się tak samo.

Tekst jest przeznaczony dla właścicieli firm, którzy sami opiekują się swoją stroną lub sklepem i mają dostęp do kokpitu oraz do panelu hostingu. Nie wymaga znajomości programowania. Potrzebna jest tylko ostrożność przy edycji jednego lub dwóch plików.

Po lekturze czytelnik będzie umiał odczytać komunikat, sprawdzić, ile pamięci ma dziś do dyspozycji jego witryna, podnieść limit na kilka sposobów w kolejności od najbezpieczniejszego, potwierdzić, że zmiana zadziałała, oraz ustalić, co zrobić, gdy mimo wyższego limitu błąd wraca. To ostatnie jest równie ważne jak sama zmiana liczby, bo wyższy limit często tylko odsuwa problem w czasie.

Co oznacza komunikat „Allowed memory size exhausted” i po czym go rozpoznać?

Pełny komunikat wygląda zwykle tak:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /wp-content/plugins/nazwa-wtyczki/plik.php on line 215

Składa się z trzech informacji i każdą z nich należy odczytać osobno. Pierwsza liczba to obowiązujący limit pamięci podany w bajtach. Druga liczba, w nawiasie, to porcja pamięci, o którą skrypt poprosił w chwili, gdy limit został przekroczony. Na końcu znajduje się ścieżka pliku i numer wiersza, w którym praca została przerwana.

Limit w bajtach łatwo przeliczyć: wystarczy podzielić liczbę dwukrotnie przez 1024. Wartość 134217728 to 128 MB, a 268435456 to 256 MB. Dzięki temu od razu wiadomo, jaki limit faktycznie działał w chwili błędu, niezależnie od tego, co ktoś wpisał kiedyś w plikach konfiguracyjnych.

Ścieżka pliku jest wskazówką, ale nie wyrokiem. Pokazuje miejsce, w którym pamięć się skończyła, a nie zawsze to, co zużyło jej najwięcej. Jeśli jednak w kolejnych wpisach dziennika powtarza się katalog tej samej wtyczki lub tego samego motywu, jest to mocny trop.

Gdy komunikatu nie widać na ekranie

Na działającej publicznie stronie wyświetlanie błędów jest najczęściej wyłączone i tak powinno pozostać. Brak pamięci objawia się wtedy inaczej: pustą, białą stroną, błędem 500, ekranem „W witrynie wystąpił błąd krytyczny”, przerwanym wgrywaniem zdjęcia, niedokończoną aktualizacją wtyczki albo importem produktów, który staje zawsze w tym samym miejscu. Te same objawy mają też inne przyczyny, dlatego przed zmianą limitu trzeba potwierdzić, że chodzi właśnie o pamięć.

Potwierdzenie daje dziennik błędów. Większość paneli hostingowych udostępnia go w dziale dotyczącym PHP lub dzienników serwera, a w katalogu witryny bywa zapisywany jako plik error_log. Jeśli w dzienniku z godziny awarii znajduje się wiersz ze słowami „Allowed memory size”, diagnoza jest pewna. Gdy strona pokazuje wyłącznie pustą kartę, pomocna będzie też osobna instrukcja o tym, jak przywrócić stronę, gdy wyświetla się biały ekran.

Należy też odróżnić ten komunikat od podobnego, który zaczyna się od słów „Out of memory”. Pierwszy mówi o przekroczeniu ustawionego limitu, który można podnieść. Drugi oznacza, że pamięci zabrakło całemu serwerowi lub kontu, i wtedy zmiana ustawień w plikach witryny nic nie da. Taką sytuację rozwiązuje wyłącznie dostawca hostingu albo zmiana pakietu.

Dwa limity pamięci: serwera i WordPressa. Czym się różnią?

Pamięcią skryptów zarządza PHP, czyli oprogramowanie serwera, na którym działa WordPress. Jego ustawienie nazywa się memory_limit i określa, ile pamięci może zająć jeden uruchomiony skrypt. Według dokumentacji PHP wartość domyślna to 128 MB, ale każdy dostawca hostingu ustawia ją po swojemu i zwykle zależy ona od wykupionego pakietu.

WordPress ma własne dwa ustawienia, które działają w granicach wyznaczonych przez serwer. Stała WP_MEMORY_LIMIT dotyczy zwykłego działania witryny. Jeśli nikt jej nie określił, WordPress próbuje zapewnić sobie 40 MB na pojedynczej witrynie i 64 MB w sieci witryn. Stała WP_MAX_MEMORY_LIMIT dotyczy zadań administracyjnych, takich jak praca w kokpicie czy obróbka obrazków, i domyślnie wynosi 256 MB.

Z tego układu wynikają trzy praktyczne wnioski. Po pierwsze, WordPress nie obniża limitu serwera: jeśli PHP ma przydzielone więcej, niż wskazuje stała, witryna korzysta z wyższej wartości. Po drugie, WordPress może podnieść limit tylko wtedy, gdy serwer na to pozwala. Dokumentacja WordPressa zaznacza wprost, że część dostawców blokuje taką zmianę i wtedy pozostaje kontakt z hostingiem. Po trzecie, błąd w kokpicie i błąd w publicznej części strony mogą wynikać z dwóch różnych ustawień, więc trzeba wiedzieć, gdzie dokładnie wystąpił.

Ważna jest jeszcze jedna rzecz. Limit dotyczy jednego skryptu, a nie całej witryny. Jeśli stronę otwiera jednocześnie wiele osób, każda wizyta może zająć pamięć aż do tej granicy. Dlatego ustawienie bardzo wysokiej wartości na tanim pakiecie hostingowym potrafi zamienić pojedynczy błąd w spowolnienie lub niedostępność całego konta.

Jak sprawdzić, ile pamięci witryna ma dziś do dyspozycji?

Jeżeli kokpit działa, najszybciej zrobi to narzędzie wbudowane w WordPressa. Pokazuje ono wartości faktycznie obowiązujące, a nie te, które ktoś zamierzał ustawić.

1. Po zalogowaniu do kokpitu należy wejść w menu „Narzędzia” i wybrać „Stan witryny”.
2. Na górze ekranu trzeba przejść na kartę „Informacje”.
3. Po rozwinięciu sekcji „Serwer” należy odszukać wiersz „Limit pamięci PHP”. To wartość ustawiona po stronie serwera.
4. Po rozwinięciu sekcji „Stałe WordPressa” należy odczytać wiersze WP_MEMORY_LIMIT oraz WP_MAX_MEMORY_LIMIT.
5. Wszystkie trzy wartości warto zanotować razem z liczbą z komunikatu błędu. Będą punktem odniesienia po zmianie.

W sklepie na WooCommerce te same dane pokazuje raport stanu systemu dostępny w menu „WooCommerce” i „Status”. Znajduje się tam osobny wiersz dla limitu PHP w części o środowisku serwera i osobny dla limitu WordPressa.

Gdy kokpit jest niedostępny, pozostają dwa źródła. Pierwszym jest sam komunikat błędu: liczba bajtów po przeliczeniu mówi, jaki limit zadziałał. Drugim jest panel hostingu, w którym ustawienia PHP dla domeny pokazują bieżącą wartość memory_limit. Nie radzę wgrywać na serwer własnych plików testowych wyświetlających pełną konfigurację PHP. Jeśli ktoś o takim pliku zapomni, zostawia publicznie dostępny opis swojego serwera.

Co przygotować, zanim cokolwiek zostanie zmienione?

Zmiana limitu jest prosta, ale wykonuje się ją w plikach, od których zależy działanie całej witryny. Jeden brakujący znak w pliku wp-config.php wyłącza stronę w całości. Dlatego przed edycją trzeba mieć pod ręką trzy rzeczy.

• Dostęp do plików witryny: menedżer plików w panelu hostingu albo konto FTP lub SFTP. Sam kokpit nie wystarczy, bo po błędzie w pliku może przestać działać.
• Kopię każdego pliku, który ma być zmieniony, pobraną na komputer przed edycją. W razie pomyłki wystarczy wgrać ją z powrotem.
• Aktualną kopię całej witryny, jeśli błąd pojawił się w trakcie aktualizacji, importu lub innej operacji zmieniającej dane.

Pliki należy edytować w zwykłym edytorze tekstu lub w edytorze wbudowanym w menedżer plików. Edytory biurowe, takie jak programy do pisania dokumentów, dodają do treści niewidoczne znaki i zamieniają proste cudzysłowy na drukarskie, co powoduje błąd składni. Osobom, które nie mają pewnej kopii, polecam najpierw sprawdzić, jak wykonać kopię zapasową WordPressa i upewnić się, że da się z niej odtworzyć stronę.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: sprawdzę, który limit został przekroczony, podniosę go we właściwym miejscu i ustalę, co w witrynie zużywa tyle pamięci.

Jak zwiększyć limit pamięci w pliku wp-config.php?

To pierwsza metoda, którą wskazuje dokumentacja WordPressa, i od niej należy zacząć. Plik wp-config.php znajduje się w głównym katalogu instalacji, obok katalogów wp-admin, wp-content i wp-includes. Zmiana polega na dopisaniu jednego lub dwóch wierszy.

1. Po zalogowaniu do menedżera plików lub przez FTP należy otworzyć główny katalog witryny i pobrać plik wp-config.php na komputer jako kopię.
2. Plik na serwerze trzeba otworzyć do edycji i sprawdzić, czy nie zawiera już wiersza ze słowem WP_MEMORY_LIMIT. Jeśli taki wiersz istnieje, zmienia się w nim wartość. Drugiego wiersza z tą samą stałą dopisywać nie wolno.
3. Następnie należy odszukać wiersz komentarza zaczynający się od słów „That’s all, stop editing!”. W spolszczonych instalacjach komentarz bywa zapisany po polsku i zaczyna się od słów „To wszystko”.
4. Bezpośrednio nad tym komentarzem wpisuje się wiersz: define( 'WP_MEMORY_LIMIT’, '256M’ );
5. Jeśli błąd występuje w kokpicie, a nie w publicznej części strony, pod spodem dopisuje się drugi wiersz: define( 'WP_MAX_MEMORY_LIMIT’, '512M’ );
6. Plik należy zachować, a potem od razu otworzyć stronę główną i kokpit w przeglądarce, żeby upewnić się, że obie części się wczytują.

Po zmianie odpowiedni fragment pliku powinien wyglądać tak:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

/* That's all, stop editing! Happy publishing. */

Miejsce wpisu nie jest dowolne. Dokumentacja zaznacza, że stałe muszą znaleźć się przed dołączeniem pliku wp-settings.php, czyli przed końcową częścią wp-config.php. Wiersz dopisany na samym dole pliku zostanie odczytany za późno i nie przyniesie skutku.

Wartość zapisuje się liczbą z literą M bez spacji, w prostych apostrofach, a wiersz kończy się średnikiem. Zapis „256MB” jest błędny. Jeśli po zachowaniu pliku witryna pokazuje błąd lub pustą stronę, przyczyną jest prawie zawsze literówka w dopisanym wierszu. Wystarczy wtedy wgrać na serwer pobraną wcześniej kopię pliku i powtórzyć zmianę uważniej.

Ta metoda ma jedno ograniczenie. Stała w wp-config.php jest prośbą WordPressa skierowaną do serwera. Jeśli dostawca hostingu nie pozwala skryptom podnosić limitu albo ustawił górny pułap dla pakietu, wpis pozostanie bez efektu, choć nie wywoła żadnego błędu. Widać to w narzędziu „Stan witryny”: wartość stałej się zmieni, a rzeczywisty limit z komunikatu błędu pozostanie ten sam. Wtedy trzeba przejść do ustawień serwera.

Jak podnieść limit po stronie serwera, gdy wpis w wp-config.php nie wystarcza?

Ustawienie memory_limit można zmienić w kilku miejscach. Które z nich jest dostępne, zależy od dostawcy i od sposobu, w jaki uruchamia on PHP. Poniższe metody są ułożone od najbezpieczniejszej do tej, która wymaga największej ostrożności.

Ustawienia PHP w panelu hostingu

Większość dostawców udostępnia w panelu klienta dział z ustawieniami PHP dla wybranej domeny. Nazywa się on różnie, najczęściej zawiera słowa „PHP”, „Ustawienia PHP” lub „Konfiguracja PHP”. Na liście opcji znajduje się pozycja memory_limit z polem do wpisania wartości albo z listą wartości do wyboru.

To najlepsza droga, ponieważ nie wymaga edycji plików, a panel nie pozwoli wpisać wartości wyższej niż dopuszczalna w danym pakiecie. Po zachowaniu ustawień zmiana zaczyna działać od razu lub po kilku minutach. Jeśli panel nie ma takiej opcji, dostawca zwykle opisuje w swojej pomocy, której z poniższych metod należy użyć.

Plik .user.ini w katalogu witryny

Na serwerach, które uruchamiają PHP w trybie CGI lub FastCGI, czyli na dużej części współczesnych hostingów, PHP odczytuje dodatkowy plik ustawień o nazwie .user.ini. Umieszcza się go w głównym katalogu witryny, tam gdzie leży wp-config.php. Jeśli plik już istnieje, dopisuje się do niego wiersz, a jeśli nie, tworzy się nowy plik tekstowy o tej nazwie, z kropką na początku.

memory_limit = 256M

Według dokumentacji PHP pliki tego typu są odczytywane ponownie co 300 sekund, o ile dostawca nie zmienił tego ustawienia. Oznacza to, że na efekt trzeba poczekać do 5 minut i dopiero potem oceniać, czy metoda działa. Sprawdzanie od razu po zachowaniu pliku prowadzi do błędnego wniosku, że zmiana nie ma skutku.

Plik php.ini

Część dostawców pozwala umieścić w katalogu konta własny plik php.ini albo edytować go przez panel. Wpis jest taki sam jak w pliku .user.ini. Dokumentacja WordPressa przypomina, że php.ini nie jest plikiem WordPressa, więc jego położenie i zasady działania ustala wyłącznie hosting. Jeśli w pomocy dostawcy nie ma o nim mowy, nie należy tworzyć go na próbę w przypadkowych katalogach.

Plik .htaccess – tylko na wybranych serwerach

W wielu opisach pojawia się rada, by do pliku .htaccess dopisać wiersz php_value memory_limit 256M. Ta metoda działa wyłącznie wtedy, gdy PHP pracuje jako moduł serwera Apache i gdy dostawca zezwala na takie dyrektywy. Na serwerach, które uruchamiają PHP w inny sposób, ten sam wiersz wywołuje błąd 500 na całej witrynie, łącznie z kokpitem.

Dlatego traktuję tę drogę jako ostatnią i tylko po potwierdzeniu u dostawcy, że jest obsługiwana. Jeśli po dopisaniu wiersza strona przestała działać, naprawa jest natychmiastowa: wystarczy usunąć ten jeden wiersz z pliku albo wgrać kopię pobraną przed edycją.

Zgłoszenie do dostawcy hostingu

Gdy żadna z metod nie zmienia rzeczywistego limitu, oznacza to, że dostawca ustawił go na stałe dla pakietu. Pozostaje zgłoszenie do pomocy technicznej. Dobrze napisane zgłoszenie skraca wymianę wiadomości do jednej odpowiedzi. Można użyć takiej treści:

Dzień dobry, na domenie [adres strony] pojawia się błąd PHP „Allowed memory size of [liczba] bytes exhausted”. Proszę o informację, jaki limit memory_limit obowiązuje w moim pakiecie, czy można go podnieść do 256 MB oraz w jaki sposób należy to zrobić na tym hostingu (panel, plik .user.ini lub inna metoda). W załączeniu przesyłam fragment dziennika błędów z godziny awarii.

Odpowiedź dostawcy rozstrzyga sprawę. Albo limit zostanie podniesiony, albo okaże się, że wymaga to wyższego pakietu. W drugim przypadku przed zmianą pakietu należy jeszcze ustalić, czy witryna rzeczywiście potrzebuje tyle pamięci, o czym mowa w dalszej części.

Ile pamięci ustawić i dlaczego nie warto wpisywać wartości „na zapas”?

Nie istnieje jedna właściwa liczba, ale są rozsądne punkty odniesienia. Dokumentacja WooCommerce przyjmuje 256 MB jako wartość, poniżej której podniesienie limitu może usunąć błędy i problemy z wydajnością. Dla zwykłej strony firmowej z kilkunastoma wtyczkami taki limit w zupełności wystarcza. Sklep z dużą liczbą produktów, rozbudowany kreator stron lub import dużych plików mogą potrzebować więcej podczas zadań administracyjnych i do tego służy osobna stała WP_MAX_MEMORY_LIMIT.

Limit najlepiej podnosić stopniowo: z wartości odczytanej w komunikacie do najbliższego wyższego progu, czyli na przykład ze 128 MB do 256 MB. Jeśli błąd znika, nie ma powodu iść dalej. Jeśli wraca przy tej samej czynności, a liczba w komunikacie odpowiada już nowemu limitowi, kolejne podwojenie rzadko pomaga na długo i trzeba szukać przyczyny w samej witrynie.

Dokumentacja PHP dopuszcza wartość -1, która całkowicie znosi limit. Na publicznie działającej stronie nie należy jej używać. Limit istnieje po to, by wadliwy skrypt nie zajął całej pamięci serwera. Bez niego jedna zapętlona wtyczka potrafi zablokować wszystkie witryny na koncie, a dostawca hostingu może w takiej sytuacji czasowo wyłączyć usługę.

Sama dokumentacja WordPressa ostrzega zresztą, że podniesienie limitu może ukryć źródło problemu, który wróci po dodaniu kolejnych wtyczek lub funkcji. Wyższy limit należy więc traktować jako sposób na przywrócenie działania strony, a nie jako ostateczną naprawę.

Po czym poznać, że zmiana zadziałała?

Zachowanie pliku bez komunikatu o błędzie niczego jeszcze nie dowodzi. Skuteczność zmiany potwierdzają dopiero trzy sprawdzenia wykonane po kolei.

1. W kokpicie należy ponownie otworzyć „Narzędzia”, „Stan witryny” i kartę „Informacje”, a następnie porównać wiersz „Limit pamięci PHP” oraz obie stałe z zanotowanymi wcześniej wartościami.
2. Trzeba powtórzyć dokładnie tę czynność, która wywoływała błąd: otworzyć tę samą podstronę, wgrać ten sam plik, uruchomić tę samą aktualizację lub ten sam import.
3. Po wykonaniu czynności należy zajrzeć do dziennika błędów i upewnić się, że nie pojawił się nowy wiersz ze słowami „Allowed memory size”.
4. Przez kilka kolejnych dni warto zaglądać do dziennika raz dziennie. Brak nowych wpisów przy zwykłym ruchu na stronie oznacza, że limit jest wystarczający.

Jeśli błąd pojawił się ponownie, najważniejsza jest pierwsza liczba w nowym komunikacie. Gdy pokazuje starą wartość, zmiana nie została przez serwer przyjęta i trzeba sięgnąć po inną metodę albo napisać do dostawcy. Gdy pokazuje nową, wyższą wartość, limit został podniesiony, ale witryna zużywa jeszcze więcej. To zupełnie inna sytuacja i dotyczy jej następna część.

Zdarza się też, że stara wartość utrzymuje się przez chwilę z przyczyn technicznych. Plik .user.ini jest odczytywany z opóźnieniem, a niektóre panele wprowadzają zmiany ustawień PHP po kilku minutach. Ocenę warto więc powtórzyć po krótkiej przerwie, zanim metoda zostanie uznana za nieskuteczną.

Co zrobić, gdy błąd wraca mimo wyższego limitu?

Powracający błąd oznacza, że w witrynie działa coś, co zużywa pamięć ponad miarę. Najczęściej jest to jedna z kilku rzeczy: wtyczka wczytująca naraz bardzo duże zbiory danych, konflikt dwóch wtyczek prowadzący do zapętlenia, motyw lub kreator stron z rozbudowanymi szablonami, obróbka zdjęć o bardzo dużych wymiarach, import lub eksport tysięcy rekordów w jednym przebiegu albo wtyczka niedostosowana do używanej wersji PHP.

Odczytanie tropu z dziennika

Pierwszym źródłem informacji jest ścieżka pliku z końca komunikatu. Katalog /wp-content/plugins/ z nazwą wtyczki albo /wp-content/themes/ z nazwą motywu wskazuje, gdzie zacząć. Jeśli ścieżka prowadzi do katalogu wp-includes, nie oznacza to wady samego WordPressa. Znaczy tylko, że pamięć skończyła się w chwili, gdy wtyczka korzystała z jego funkcji.

Gdy dziennik serwera jest niedostępny, WordPress może prowadzić własny. Do pliku wp-config.php, nad tym samym komentarzem co poprzednio, dopisuje się trzy wiersze:

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

Od tej chwili błędy trafiają do pliku debug.log w katalogu wp-content, a odwiedzający nie widzą ich na ekranie. Dokumentacja WordPressa odradza pozostawianie trybu diagnostycznego na publicznie działającej stronie, dlatego po zebraniu informacji te trzy wiersze należy wykreślić z pliku, a dziennik usunąć z serwera. Zawiera on ścieżki i szczegóły, które nie powinny być dostępne dla osób postronnych.

Wyłączanie wtyczek po kolei

Jeśli dziennik nie wskazuje jednoznacznie przyczyny, pozostaje metoda kolejnych wyłączeń. Najbezpieczniej wykonać ją na kopii testowej witryny, a jeśli takiej nie ma, w godzinach najmniejszego ruchu.

1. W kokpicie, w menu „Wtyczki”, należy wyłączyć jedną wtyczkę, zaczynając od tej, której katalog pojawił się w dzienniku.
2. Trzeba powtórzyć czynność wywołującą błąd i zajrzeć do dziennika.
3. Jeśli błąd wystąpił ponownie, wtyczkę włącza się z powrotem i wyłącza następną.
4. Gdy po wyłączeniu którejś wtyczki błąd znika, przyczyna jest ustalona. Dla pewności warto włączyć ją ponownie i sprawdzić, czy błąd wraca.
5. Jeśli wyłączenie wszystkich wtyczek nie pomaga, należy na chwilę przełączyć witrynę na jeden z domyślnych motywów WordPressa i powtórzyć próbę.

Gdy kokpit jest niedostępny, tę samą próbę wykonuje się przez menedżer plików: zmiana nazwy katalogu wtyczki w /wp-content/plugins/ powoduje jej wyłączenie, a przywrócenie nazwy pozwala włączyć ją ponownie w kokpicie. Dokładny przebieg takiego szukania opisałem w tekście o tym, jak znaleźć wtyczkę, która wywołała błąd krytyczny.

Co zrobić po znalezieniu przyczyny

Dalsze postępowanie zależy od tego, co zostało wykryte. Wtyczkę należy najpierw zaktualizować, bo nadmierne zużycie pamięci bywa błędem poprawionym w nowszym wydaniu. Jeśli aktualizacja nie pomaga, pozostaje zgłoszenie do autora wtyczki z fragmentem dziennika albo zastąpienie jej inną o tej samej funkcji.

Przy imporcie i eksporcie pomaga dzielenie pracy na mniejsze części: kilka plików po kilkaset pozycji zamiast jednego z kilkoma tysiącami. Przy zdjęciach rozwiązaniem jest zmniejszenie ich wymiarów przed wgraniem do biblioteki mediów. Zdjęcie prosto z aparatu wymaga podczas tworzenia miniatur wielokrotnie więcej pamięci, niż wynosi rozmiar pliku na dysku.

Jeśli pamięć kończy się podczas zwykłego wyświetlania stron, a nie przy jednej czynności, witryna jest po prostu przeciążona liczbą lub jakością dodatków. Wtedy potrzebny jest przegląd całości, a pomocą będzie opis tego, jak sprawdzić, co spowalnia WordPressa, ponieważ te same elementy zwykle odpowiadają i za czas wczytywania, i za zużycie pamięci.

Jakich błędów unikać przy zmianie limitu pamięci?

Większość kłopotów przy tej naprawie nie wynika z samego limitu, lecz ze sposobu wprowadzania zmiany. Poniższe pomyłki powtarzają się najczęściej.

• Edycja pliku bez pobrania kopii. Jedna literówka w wp-config.php wyłącza całą witrynę, a bez kopii trzeba szukać błędu znak po znaku.
• Dopisanie stałej poniżej wiersza dołączającego wp-settings.php. Wpis jest poprawny, lecz odczytywany za późno, więc nie działa.
• Dwa wiersze z tą samą stałą w jednym pliku. Obowiązuje pierwszy, a drugi powoduje ostrzeżenia w dzienniku.
• Wklejanie wiersza skopiowanego ze strony, na której proste apostrofy zostały zamienione na drukarskie. Taki wiersz wygląda dobrze, a wywołuje błąd składni.
• Wpis php_value w pliku .htaccess bez potwierdzenia, że serwer go obsługuje. Skutkiem bywa błąd 500 na całej stronie.
• Ustawianie kilku metod naraz. Gdy limit zmienia się jednocześnie w panelu, w pliku .user.ini i w wp-config.php, nie wiadomo później, która wartość obowiązuje i skąd pochodzi.
• Zniesienie limitu wartością -1 albo wpisywanie wartości wielokrotnie wyższych od potrzeb. Chwilowo usuwa to komunikat, a naraża całe konto na przeciążenie.
• Pozostawienie włączonego trybu diagnostycznego i pliku debug.log po zakończeniu naprawy.

Do tej listy dodałbym jeszcze jedną uwagę. Po udanej zmianie warto zapisać w notatkach firmy, gdzie i na jaką wartość limit został ustawiony. Przy następnej zmianie hostingu lub wersji PHP ta informacja oszczędza sporo czasu.

Najczęstsze pytania

Czy zwiększenie limitu pamięci może uszkodzić stronę?

Sama wyższa wartość limitu niczego nie uszkadza i można ją w każdej chwili cofnąć. Ryzyko wiąże się wyłącznie z pomyłką podczas edycji pliku, na przykład z usuniętym średnikiem lub wierszem dopisanym w niewłaściwym pliku. Dlatego przed zmianą pobiera się kopię pliku, a po zmianie od razu otwiera stronę i kokpit.

Po wpisaniu 256M w wp-config.php komunikat nadal pokazuje 134217728 bajtów. Dlaczego?

Oznacza to, że serwer nie pozwolił WordPressowi podnieść limitu i nadal obowiązuje 128 MB ustawione po stronie PHP. Wpis w wp-config.php jest poprawny, ale nieskuteczny w tym środowisku. Należy zmienić memory_limit w panelu hostingu lub w pliku .user.ini, a jeśli i to nie działa, napisać do dostawcy.

Czym różni się WP_MEMORY_LIMIT od WP_MAX_MEMORY_LIMIT?

Pierwsza stała określa pamięć dla zwykłego działania witryny, w tym dla stron oglądanych przez odwiedzających. Druga dotyczy zadań administracyjnych, takich jak praca w kokpicie i obróbka obrazków, i domyślnie jest wyższa. Jeśli błąd pojawia się tylko podczas pracy w kokpicie, zwykle wystarcza zmiana drugiej z nich.

Czy limit pamięci to to samo co pojemność dysku albo pamięć serwera z oferty hostingu?

Nie. Pojemność dysku mówi, ile plików zmieści się na koncie, i nie ma z tym błędem nic wspólnego. Limit pamięci PHP to ilość pamięci operacyjnej, jaką może zająć jeden uruchomiony skrypt. W ofertach hostingowych bywa podawany osobno, pod nazwą memory_limit lub „limit pamięci PHP”, i to tej pozycji należy szukać przy porównywaniu pakietów.

Błąd pojawia się tylko przy wgrywaniu zdjęć. Czy trzeba podnosić limit?

Najpierw warto zmniejszyć zdjęcia przed wgraniem, ponieważ tworzenie miniatur z bardzo dużego obrazu wymaga dużo pamięci bez żadnej korzyści dla strony. Jeśli po zmniejszeniu wymiarów błąd znika, zmiana limitu nie jest potrzebna. Gdy pojawia się także przy zdjęciach o rozsądnych wymiarach, należy podnieść WP_MAX_MEMORY_LIMIT.

Po jakim czasie od zmiany nowy limit zaczyna działać?

Wpis w wp-config.php działa od następnego wczytania strony. Zmiana w pliku .user.ini jest odczytywana z opóźnieniem, które według dokumentacji PHP wynosi domyślnie 300 sekund. Ustawienia zmieniane w panelu hostingu zaczynają obowiązywać od razu albo po kilku minutach, zależnie od dostawcy.

Czy wtyczka do zwiększania limitu pamięci rozwiąże problem?

Takie wtyczki zmieniają te same ustawienia, które można wpisać ręcznie, więc podlegają tym samym ograniczeniom serwera. Dodatkowo każda kolejna wtyczka sama zajmuje trochę pamięci. Uważam, że przy jednorazowej zmianie jednego wiersza ręczna edycja z kopią pliku jest prostsza i czystsza.

Kiedy wyższy pakiet hostingu jest naprawdę potrzebny?

Wtedy, gdy witryna po uporządkowaniu wtyczek i motywu nadal potrzebuje więcej pamięci, niż dopuszcza obecny pakiet, a dostawca potwierdził, że limitu nie da się podnieść. Dotyczy to zwłaszcza sklepów z dużą liczbą produktów i stron z rozbudowanymi kreatorami. Zmiana pakietu przed ustaleniem przyczyny bywa wydatkiem, który niczego nie naprawia.

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

Nie każdy chce edytować pliki własnej strony i w pełni to rozumiem. Mogę zająć się tym od początku do końca: odczytam dziennik błędów, sprawdzę ustawienia serwera i WordPressa, podniosę limit w miejscu, które na danym hostingu rzeczywiście działa, a potem ustalę, która wtyczka lub czynność zużywa zbyt dużo pamięci, i zaproponuję trwałe rozwiązanie. Na koniec przekażę krótki opis tego, co zostało zmienione i gdzie.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz treść komunikatu, jeśli jest znana. Resztę informacji zbiorę już sam.