Memory limit w WordPressie i konfiguracja PHP. Kompletny poradnik

Krótka odpowiedź, zanim wejdziemy w szczegóły

Limit pamięci w WordPressie zwiększasz najszybciej wpisem w wp-config.php, nad linią /* That's all, stop editing! Happy publishing. */:

// Limit pamieci dla calej witryny (frontend + admin)
define( 'WP_MEMORY_LIMIT', '256M' );

I tu jest haczyk, którego większość poradników nie tłumaczy. Ten wpis nie podniesie limitu ponad to, co pozwala Twój serwer. WordPress traktuje WP_MEMORY_LIMIT jak podłogę, a nie jak sufit. Jeśli PHP na hostingu ma memory_limit ustawiony na 128M, a Ty wpiszesz 256M, WordPress spróbuje wywołać ini_set(). Zadziała to tylko wtedy, gdy hosting w ogóle na to pozwala.

Dlatego kolejność działań jest inna: najpierw sprawdź realny limit PHP, potem podnieś go tam, gdzie serwer faktycznie go czyta, a wp-config.php potraktuj jako uzupełnienie. Poniżej masz wszystkie metody z informacją, kiedy która nie zadziała i dlaczego.

WordPress ma dwa limity pamięci. To źródło większości nieporozumień

Kiedy szukasz „memory limit wordpress”, mieszają się trzy różne rzeczy. Rozdzielmy je raz na zawsze.

1. memory_limit w PHP

To ustawienie samego PHP, nie WordPressa. Mówi, ile pamięci może zużyć pojedynczy skrypt PHP, zanim interpreter go zabije. Domyślna wartość w PHP to 128M (php.net). Hosting może ją podnieść albo obniżyć.

To jest twardy sufit. Nic w WordPressie nie przeskoczy tej wartości, jeśli hosting zablokował jej zmianę w locie.

2. WP_MEMORY_LIMIT

Stała WordPressa. Definiuje, ile pamięci WordPress próbuje sobie zapewnić na normalną pracę, czyli frontend i większość operacji. Domyślnie:

• 40M dla pojedynczej witryny,
• 64M dla multisite.

3. WP_MAX_MEMORY_LIMIT

Druga stała WordPressa, domyślnie 256M. Używana przy operacjach cięższych niż zwykłe wyświetlenie strony: ekrany administracyjne, przetwarzanie obrazków, zadania WP-Cron.

Skąd to wiadomo. Kod źródłowy

Nie musisz mi wierzyć na słowo. Oto realny fragment z wp-includes/default-constants.php, funkcja wp_initial_constants():

$current_limit     = ini_get( 'memory_limit' );
$current_limit_int = wp_convert_hr_to_bytes( $current_limit );

// Define memory limits.
if ( ! defined( 'WP_MEMORY_LIMIT' ) ) {
	if ( false === wp_is_ini_value_changeable( 'memory_limit' ) ) {
		define( 'WP_MEMORY_LIMIT', $current_limit );
	} elseif ( is_multisite() ) {
		define( 'WP_MEMORY_LIMIT', '64M' );
	} else {
		define( 'WP_MEMORY_LIMIT', '40M' );
	}
}

// Set memory limits.
$wp_limit_int = wp_convert_hr_to_bytes( WP_MEMORY_LIMIT );
if ( -1 !== $current_limit_int && ( -1 === $wp_limit_int || $wp_limit_int > $current_limit_int ) ) {
	ini_set( 'memory_limit', WP_MEMORY_LIMIT );
}

Zwróć uwagę na dwie rzeczy. Po pierwsze: jeśli wp_is_ini_value_changeable( 'memory_limit' ) zwróci false, czyli hosting zablokował zmianę w locie, WordPress po prostu przyjmuje wartość serwera i przestaje kombinować. Po drugie: ini_set() odpala się tylko wtedy, gdy limit WordPressa jest wyższy od aktualnego. Wpisanie w wp-config.php wartości niższej niż serwerowa nie zrobi absolutnie nic.

Podobnie działa WP_MAX_MEMORY_LIMIT. Wywołuje ją funkcja wp_raise_memory_limit(), obsługująca konteksty admin, image i cron (developer.wordpress.org). W wp-admin/admin.php wygląda to tak:

if ( current_user_can( 'manage_options' ) ) {
	wp_raise_memory_limit( 'admin' );
}

Czyli: podbicie limitu w panelu dostają wyłącznie użytkownicy z uprawnieniem manage_options. Redaktor wgrywający duże zdjęcie takiego bonusu nie dostanie. To detal, który potrafi wyjaśnić dziwną sytuację „u mnie działa, u redaktora się wywala”.

Ustawienie	Kto to kontroluje	Domyślnie	Czy jest sufitem
memory_limit (PHP)	serwer / hosting	128M	Tak, to jest twardy sufit
WP_MEMORY_LIMIT	wp-config.php	40M (64M multisite)	Nie, to podłoga
WP_MAX_MEMORY_LIMIT	wp-config.php	256M	Nie, to podłoga dla admina, obrazków i crona

Pięć metod zwiększenia limitu, krok po kroku

Metoda 1 – wp-config.php

Najszybsza i najbezpieczniejsza. Otwórz wp-config.php w katalogu głównym WordPressa. Znajdź linię:

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

W polskiej wersji może brzmieć podobnie, ale zawsze jest to komentarz tuż przed require_once ABSPATH . 'wp-settings.php';. Wszystko, co dopiszesz poniżej tej linii, zostanie zignorowane. To najczęstszy błąd przy tej metodzie.

// Limit pamieci dla frontendu i normalnej pracy
define( 'WP_MEMORY_LIMIT', '256M' );

// Limit dla panelu admina, obrobki obrazkow i WP-Cron
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

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

Oficjalna dokumentacja potwierdza, że WP_MAX_MEMORY_LIMIT musi znaleźć się przed dołączeniem wp-settings.php (developer.wordpress.org).

Metoda 2 – php.ini

Działa, gdy hosting pozwala na własny plik php.ini w katalogu strony albo gdy masz VPS i edytujesz plik systemowy.

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

Na VPS po zmianie musisz przeładować PHP-FPM albo cały serwer WWW. Na hostingu współdzielonym plik wgrywasz do katalogu, do którego skierowana jest domena. Tak działa to w home.pl, gdzie dokumentacja podaje własny php.ini jako podstawową metodę zmiany parametrów.

Metoda 3 – .user.ini

To metoda, o której polskie poradniki milczą, a dziś jest najczęściej właściwa. PHP przetwarza pliki .user.ini wyłącznie w SAPI CGI i FastCGI, czyli praktycznie wszędzie tam, gdzie działa PHP-FPM (php.net).

Utwórz plik .user.ini w katalogu strony:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 5000

Dwie rzeczy warto wiedzieć. W .user.ini zadziałają tylko dyrektywy o trybie INI_PERDIR i INI_USER. Ustawienia INI_SYSTEM, na przykład max_file_uploads, trzeba zmienić w głównym php.ini. Druga rzecz: PHP cache’uje te pliki. Domyślny user_ini.cache_ttl to 300 sekund, więc po edycji odczekaj pięć minut, zanim uznasz, że nie zadziałało.

LH.pl podaje .user.ini jako jedyną oficjalną metodę zmiany konfiguracji PHP na swoich serwerach.

Metoda 4 – .htaccess

Klasyka, która coraz częściej nie działa. Wpis wygląda tak:

php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 120
php_value max_input_vars 5000

Uwaga, to jest pułapka. Dyrektywy php_value rozumie wyłącznie Apache z PHP jako modułem (mod_php) oraz komercyjny LiteSpeed Web Server. Przy PHP-FPM Apache nie wie, co to php_value, i zwraca błąd 500 z komunikatem „Invalid command ‘php_value’”. Dokumentacja DirectAdmin mówi o tym wprost: PHP-FPM to samodzielny serwer PHP i nie obsługuje zmian z .htaccess (docs.directadmin.com).

Nginx w ogóle nie czyta .htaccess. OpenLiteSpeed obsługuje z tego pliku praktycznie tylko reguły przepisywania adresów.

Jeśli po dodaniu tych linii strona zwróciła 500, usuń je i przejdź do .user.ini. To nie jest awaria, to informacja o tym, jak działa Twój serwer.

Są hostingi, które .htaccess obsługują świadomie i to dokumentują. Zenbox wymienia wprost obsługiwane zmienne: max_execution_time, max_input_time, memory_limit, post_max_size, upload_max_filesize, max_file_uploads, max_input_vars . dhosting też podaje .htaccess jako metodę oficjalną.

Metoda 5 – panel hostingu

Najbezpieczniejsza opcja, jeśli hosting ją daje. Wtedy nie musisz zgadywać, który plik serwer czyta.

• cPanel: Home > Software > MultiPHP INI Editor. W trybie Basic Mode masz listę najpopularniejszych dyrektyw, w Editor Mode wpisujesz dowolne. Ważne: w menu wyboru pliku Home Directory oznacza zmianę dla całego konta, a nazwa domeny tylko dla tej domeny. cPanel zapisuje zmiany do php.ini, .user.ini i .htaccess naraz, o ile dany plik obsługuje daną dyrektywę (docs.cpanel.net).
• Direct admin: Serwer WWW > Strony WWW > Edytuj > Ustawienia PHP > Edycja parametrów PHP. Zmiana jest per strona. W dokumentacji wymienione są memory_limit, upload_max_filesize, post_max_size i max_input_vars .
• Zenbox: Zaawansowane > Zmiana wersji PHP, wybierasz domenę i edytujesz parametry. Uwaga na pułapkę: mimo wyboru domeny zmiana konfiguracji modułów PHP dotyczy całego konta i wszystkich domen korzystających z tej wersji PHP. Na liście edytowalnych parametrów nie ma max_input_vars, ten trzeba dorzucić przez .htaccess.
• home.pl: w panelu ustawiasz wersję PHP (Usługi WWW > nazwa usługi > Serwer WWW > Ustawienia > Preferencje serwera > Interpreter PHP), a parametry przez własny php.ini. Dokumentacja podaje domyślne wartości: memory_limit 128M, upload_max_filesize i post_max_size po 64M, z możliwością podniesienia pamięci do 512 MB na serwerach Linii profesjonalnej.
• DirectAdmin: wersję PHP wybierasz per domena. Przy PHP-FPM parametry ustawiasz przez .user.ini, nie przez .htaccess.
• Mikr.us: to nie jest jeden produkt. Pod tą marką jest VPS, na którym PHP konfigurujesz sam przez SSH, oraz osobne usługi współdzielone. Zanim zaczniesz szukać panelu, ustal, którą usługę masz.

Która metoda zadziała na Twoim serwerze

Metoda	Gdzie wpisać	Kiedy działa	Kiedy nie zadziała
wp-config.php	katalog główny WP, nad „stop editing”	zawsze, gdy hosting pozwala na ini_set()	gdy hosting zablokował zmianę memory_limit w locie; gdy chcesz zmienić upload_max_filesize (WP tego nie ustawia)
php.ini	katalog strony lub systemowy	własny php.ini dozwolony przez hosting; VPS	hosting ignoruje pliki użytkownika; brak przeładowania PHP-FPM po zmianie
.user.ini	katalog strony	PHP jako CGI / FastCGI / PHP-FPM	PHP jako moduł Apache; dyrektywy INI_SYSTEM
.htaccess	katalog strony	Apache z mod_php, LiteSpeed Enterprise	PHP-FPM (błąd 500), nginx (plik ignorowany), OpenLiteSpeed
panel hostingu	panel klienta	gdy hosting udostępnia edytor parametrów	gdy panel daje tylko wybór wersji PHP; gdy parametru nie ma na liście

Nie wiesz, w jakim trybie działa Twoje PHP? Sprawdź to w phpinfo() w polu Server API. Wartości FPM/FastCGI lub CGI/FastCGI oznaczają .user.ini. Wartość Apache 2.0 Handler oznacza, że .htaccess zadziała.

Jak sprawdzić, czy limit faktycznie się zmienił

Stan witryny

Najprostsza droga bez wychodzenia z panelu: Narzędzia > Stan witryny > Informacje, sekcja Serwer. Znajdziesz tam memory_limit, max_execution_time, upload_max_filesize, post_max_size i wersję PHP. To wartości realnie widziane przez WordPressa, więc jeśli tu nic się nie zmieniło, zmiana po prostu nie doszła.

phpinfo()

Bardziej szczegółowo. Wgraj do katalogu strony plik z jedną linią:

<?php phpinfo();

Otwórz go w przeglądarce i szukaj kolumn Local Value oraz Master Value. Master to wartość serwera, Local to wartość po nadpisaniu przez Twój plik. Jeśli Local pokazuje starą wartość, nadpisanie nie zadziałało.

Po sprawdzeniu natychmiast usuń ten plik. phpinfo() wystawia publicznie pełną konfigurację serwera, ścieżki i listę modułów. To gotowy materiał rozpoznawczy dla kogoś, kto szuka luk.

WP-CLI

Jeśli masz dostęp do SSH, to najszybszy sposób:

# Co jest zdefiniowane w wp-config.php
wp config get WP_MEMORY_LIMIT --type=constant

# Co PHP realnie widzi w tym momencie
wp eval "echo ini_get('memory_limit');"

# Kilka parametrow naraz
wp eval "echo ini_get('upload_max_filesize') . ' / ' . ini_get('post_max_size') . ' / ' . ini_get('max_input_vars');"

Uwaga: WP-CLI działa w SAPI CLI, które bardzo często ma zupełnie inne limity niż PHP obsługujące ruch WWW. Sprawdzenie przez WP-CLI mówi Ci o kontekście CLI, nie o tym, co widzi przeglądarka. Do weryfikacji frontendu użyj Stanu witryny albo phpinfo().

Pozostałe dyrektywy, które psują WordPressa

Pamięć to tylko jeden z limitów. Reszta psuje rzeczy w sposób znacznie mniej oczywisty.

Dyrektywa	Domyślnie w PHP	Tryb zmiany	Co psuje, gdy jest za niska
memory_limit	128M	INI_ALL	biały ekran, „Allowed memory size exhausted”
upload_max_filesize	2M	INI_PERDIR	nie wgrasz większego pliku do Biblioteki mediów
post_max_size	8M	INI_PERDIR	formularz wraca pusty, wgrywanie ucina się bez błędu
max_execution_time	30	INI_ALL	„Maximum execution time exceeded” przy imporcie, backupie, aktualizacji
max_input_time	-1	INI_PERDIR	timeout przy wysyłaniu dużych plików na wolnym łączu
max_input_vars	1000	INI_PERDIR	gubione pozycje menu, znikające pola ACF, ucięte ustawienia motywu
max_file_uploads	20	INI_SYSTEM	wgrywasz 30 zdjęć naraz, zapisuje się 20

Źródło wartości domyślnych: lista dyrektyw php.ini na php.net.

post_max_size musi być większe lub równe upload_max_filesize

To zasada, o której zapomina połowa osób podnoszących limit uploadu. post_max_size ogranicza całe żądanie POST, razem z plikiem i wszystkimi polami formularza. Jeśli ustawisz upload_max_filesize na 64M, a zostawisz post_max_size na 8M, WordPress nadal odmówi przyjęcia pliku 20 MB. Ustaw post_max_size co najmniej równe, w praktyce lekko wyższe.

max_input_vars i znikające menu

To najbardziej podstępny z tych limitów, bo nie generuje żadnego błędu. PHP po prostu przestaje przetwarzać pola formularza po przekroczeniu limitu i idzie dalej, jakby nic się nie stało.

Objawy: zapisujesz menu z 80 pozycjami, po odświeżeniu zostaje 60. Zapisujesz wpis z rozbudowanym zestawem pól ACF, część wraca pusta. Zapisujesz ustawienia motywu, zapisuje się połowa. Wygląda to jak błąd wtyczki, a to zwykły limit PHP.

Jeden element menu to kilkanaście zmiennych POST, więc przy 1000 limit kończy się szybciej, niż się wydaje. Ustaw 5000 i problem znika.

Jakie wartości ustawić

To są rozsądne punkty wyjścia, nie prawa fizyki. Zawsze zaczynaj od niższej wartości i podnoś, gdy realnie brakuje.

Typ strony	memory_limit	upload_max_filesize / post_max_size	max_execution_time	max_input_vars
Blog, wizytówka	128M	32M / 32M	60	1000
Strona firmowa z page builderem	256M	64M / 64M	120	3000
WooCommerce do ~500 produktów	256M	64M / 64M	180	5000
Duży sklep, tysiące produktów, feedy	512M	128M / 128M	300	10000
Multisite	256M i więcej	64M / 64M	180	5000

Dlaczego akurat tak. Page buildery i biblioteki bloków trzymają w pamięci sporo struktur i to one najczęściej wywalają limit 128M. WooCommerce dokłada sesje, koszyk i podatki liczone w locie. Duże sklepy potrzebują długiego czasu wykonania, bo import idzie partiami, a każda partia to osobne żądanie. Multisite startuje z wyższą podłogą, bo WordPress daje mu domyślnie 64M zamiast 40M.

Czego nie robić: ustawiania memory_limit na 1024M albo -1 na hostingu współdzielonym. Hosting i tak najczęściej to zignoruje. A jeśli nie zignoruje, jeden proces z wyciekiem pamięci potrafi zjeść zasoby całego konta i skończy się to jego wstrzymaniem.

Co realnie znaczą komunikaty błędów

„Fatal error – Allowed memory size of 134217728 bytes exhausted”

Skrypt PHP chciał więcej pamięci, niż mu wolno. Liczba w bajtach to Twój aktualny limit. 134217728 bajtów to dokładnie 128 MB, czyli domyślna wartość PHP. Jeśli widzisz tę liczbę, prawdopodobnie nikt nigdy nie ruszał konfiguracji.

Komunikat zwykle podaje też plik i numer linii. To bardzo mocna wskazówka. Jeśli ścieżka prowadzi do wp-content/plugins/nazwa-wtyczki/, masz podejrzanego.

„Maximum execution time of 30 seconds exceeded”

Skrypt działał dłużej niż max_execution_time. Typowe przy imporcie produktów, generowaniu kopii zapasowej, regeneracji miniatur, migracji. To nie jest problem z pamięcią, więc podnoszenie memory_limit nic tu nie da.

„The uploaded file exceeds the upload_max_filesize directive in php.ini”

Ten komunikat jest szczery. Plik jest większy niż upload_max_filesize. Podnieś go, a razem z nim post_max_size.

Biały ekran bez żadnego komunikatu

To zwykle ten sam błąd pamięci, tylko z wyłączonym wyświetlaniem błędów. Włącz logowanie w wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Log wyląduje w wp-content/debug.log. WP_DEBUG_LOG przyjmuje też ścieżkę, więc na produkcji lepiej wskazać plik poza katalogiem publicznym:

define( 'WP_DEBUG_LOG', '/home/uzytkownik/logs/wp-errors.log' );

Ustawienie WP_DEBUG_DISPLAY na false jest tu kluczowe. Chcesz zobaczyć błąd w logu, a nie pokazać go odwiedzającym razem ze ścieżkami serwera.

Podbijanie limitu to leczenie objawu

Poprawnie zbudowana strona na WordPressie mieści się w 128M bez najmniejszego problemu. Jeśli Twoja potrzebuje 512M, żeby w ogóle się otworzyć, to nie jest kwestia limitu. Coś zjada pamięć i podniesienie sufitu tylko odsuwa moment, w którym znowu w niego uderzysz. Za miesiąc wrócisz po 1024M.

Typowe przyczyny: wtyczka z wyciekiem pamięci, zapytanie ciągnące kilka tysięcy postów naraz zamiast paginować, wtyczka ładująca całą bibliotekę mediów do pamięci przy każdym żądaniu, trzydzieści wtyczek, z których dziesięciu nie używasz od dwóch lat. Do tego dochodzi cała warstwa wydajnościowa, którą rozbieramy w osobnym wpisie o tym, dlaczego WordPress bywa wolny mimo wtyczek cache.

Jak znaleźć winowajcę

Krok 1. Zainstaluj Query Monitor. Query Monitor to darmowa wtyczka deweloperska z ponad 200 000 aktywnych instalacji. W panelu Overview pokazuje szczytowe zużycie pamięci i procent limitu, jaki zjada dane żądanie. W panelu Queries grupuje zapytania do bazy według odpowiedzialnej wtyczki, motywu lub rdzenia WordPressa. Jeśli jedna wtyczka odpowiada za 400 zapytań, masz odpowiedź w minutę.

Krok 2. Sprawdź log. W debug.log szukaj powtarzających się ścieżek. Ten sam plik wtyczki w kilku fatalach to nie przypadek.

Krok 3. Wyłącz wtyczki metodą połówkową. Nie po kolei, to za wolno. Wyłącz połowę, sprawdź. Jeśli problem zniknął, winowajca jest w wyłączonej połowie. Podziel ją znowu. Przy 32 wtyczkach znajdziesz sprawcę w pięciu próbach zamiast trzydziestu dwóch. Rób to na kopii testowej, nie na produkcji.

Krok 4. Zrób porządek. Wtyczka nieużywana od roku, dwa page buildery na jednej stronie, trzy wtyczki robiące to samo. To wszystko kosztuje pamięć przy każdym żądaniu. Regularny przegląd stacku jest częścią opieki nad WordPressem właśnie dlatego, że sam się nie zrobi.

Krok 5. Rozważ zmianę hostingu. Jeśli hosting nie pozwala wyjść poza 128M, blokuje .user.ini i każda zmiana wymaga zgłoszenia do supportu, to nie jest problem konfiguracji. Warto wtedy przemyśleć, co realnie kupujesz w pakiecie hostingowym oraz jaka jest różnica między domeną a hostingiem.

Częste błędy

Wpisanie define() poniżej linii „That’s all, stop editing”. Kod jest ignorowany, bo WordPress w tym momencie już wczytał wp-settings.php. Klasyk numer jeden.

Brak jednostki. define( 'WP_MEMORY_LIMIT', '256' ); to 256 bajtów, nie megabajtów. PHP interpretuje liczbę bez sufiksu jako bajty. Zawsze pisz 256M.

Ustawienie limitu niższego niż serwerowy. WordPress wywoła ini_set() tylko wtedy, gdy jego wartość jest wyższa od aktualnej. Wpisanie 64M przy serwerowych 256M nie zrobi nic.

Konflikt php.ini z .user.ini. Ustaw wartość w jednym miejscu i trzymaj się go. W cPanelu pamiętaj, że MultiPHP INI Editor zapisuje do php.ini, .user.ini i .htaccess naraz, więc późniejsza ręczna edycja jednego z tych plików robi bałagan.

Zapominanie o cache .user.ini. Domyślnie 300 sekund. Odczekaj pięć minut przed wyciąganiem wniosków.

Zostawienie phpinfo.php na serwerze. Widzieliśmy takie pliki na stronach działających od lat. To publiczna instrukcja obsługi Twojego serwera.

Podniesienie upload_max_filesize bez post_max_size. Efekt: nadal nie wgrasz pliku, tylko teraz bez sensownego komunikatu.

Wpisanie php_value do .htaccess na PHP-FPM. Strona zwraca 500 i wygląda na padniętą. Usuń wpis, użyj .user.ini.

Podsumowanie

Konfiguracja PHP pod WordPressa sprowadza się do trzech kroków. Sprawdź, co masz teraz, w Stanu witryny. Zmień wartość tam, gdzie Twój serwer faktycznie ją czyta, czyli w panelu hostingu, .user.ini albo php.ini, a wp-config.php potraktuj jako uzupełnienie. Potem zweryfikuj, czy zmiana weszła.

I najważniejsze: jeśli strona potrzebuje coraz więcej pamięci, żeby w ogóle działać, limit jest tylko termometrem. Prawdziwa robota polega na znalezieniu tego, co pamięć zjada.

Jeśli utknąłeś na „zrobiłem wszystko i nic nie działa” albo podejrzewasz, że problem siedzi głębiej niż w jednym pliku konfiguracyjnym, napisz do nas. Robimy audyt techniczny strony, który pokazuje konkretnie, gdzie ucieka wydajność i co z tym zrobić.

FAQ

Ile powinien wynosić memory limit w WordPressie?

Dla bloga i strony wizytówki wystarczy 128M. Strona z page builderem albo sklep WooCommerce komfortowo działa na 256M. Powyżej 512M schodzisz w rejony, w których warto najpierw sprawdzić, co zjada pamięć, zamiast podnosić limit dalej.

Czym różni się WP_MEMORY_LIMIT od memory_limit w PHP?

memory_limit to twardy limit serwera i nic go nie przeskoczy. WP_MEMORY_LIMIT to wartość, którą WordPress próbuje sobie ustawić przez ini_set(), ale tylko wtedy, gdy jest wyższa od aktualnej i gdy hosting w ogóle na to pozwala. To podłoga, nie sufit.

Zwiększyłem limit w wp-config.php, a nic się nie zmieniło. Dlaczego?

Najczęściej z jednego z trzech powodów: wpis trafił poniżej linii „That’s all, stop editing”, hosting zablokował zmianę memory_limit w locie, albo wartość jest niższa od serwerowej i WordPress ją pomija. Sprawdź realny stan w Narzędzia > Stan witryny > Informacje > Serwer.

Dlaczego po dodaniu php_value do .htaccess strona zwraca błąd 500?

Bo Twój serwer używa PHP-FPM albo nginx, a te nie rozumieją dyrektyw php_value. Apache widzi nieznaną komendę i zwraca 500. Usuń wpis i przenieś ustawienia do .user.ini.

Dlaczego WordPress gubi pozycje menu przy zapisie?

To prawie zawsze max_input_vars, domyślnie 1000. PHP po przekroczeniu limitu po cichu ucina resztę pól formularza, bez żadnego błędu. Ustaw 5000 i sprawdź ponownie.

Jak sprawdzić, ile pamięci zużywa moja strona?

Zainstaluj Query Monitor. W panelu Overview zobaczysz szczytowe zużycie pamięci dla danego żądania i procent limitu, jaki zjada. W panelu Queries zobaczysz, która wtyczka odpowiada za jakie zapytania do bazy.

Czy ustawienie memory_limit na -1 to dobry pomysł?

Nie na hostingu współdzielonym. Brak limitu oznacza, że jeden zapętlony skrypt może zjeść zasoby całego konta, a hosting ma prawo taką stronę wstrzymać. Na VPS bywa uzasadnione przy zadaniach jednorazowych, ale nie jako stałe ustawienie produkcyjne.

Czy wyższy limit pamięci przyspieszy stronę?

Nie. Limit określa tylko górną granicę zużycia, nie przydziela pamięci na start ani nie zmienia szybkości wykonania. Podniesienie limitu sprawia, że skrypt się nie wywali, a nie że wykona się szybciej.

—