WordPress używa stałych PHP jako warstwy konfiguracyjnej. Zamiast przechowywać ustawienia w bazie danych lub panelu administracyjnym, kluczowe parametry systemu definiuje się w kodzie — jako niezmienne wartości wczytywane przy każdym uruchomieniu strony.
Co to są stałe systemowe
Stała w PHP to wartość zadeklarowana raz funkcją define(), której nie można nadpisać w dalszej części działania skryptu:
define( 'WP_DEBUG', true );
Stałe systemowe WordPressa to predefiniowane nazwy, na które WordPress reaguje podczas inicjalizacji. Ich wartości wpływają na tryb debugowania, limity zasobów, ścieżki plików i wiele innych zachowań systemu.
Gdzie definiuje się stałe
Głównym miejscem jest plik wp-config.php, który WordPress wczytuje jako jeden z pierwszych — zanim załaduje rdzeń systemu, wtyczki i motyw. Dzięki temu stałe zdefiniowane w wp-config.php obowiązują przez cały cykl życia żądania.
Niektóre stałe można też definiować w pliku functions.php motywu — ale tylko te, które nie są potrzebne zanim motyw zostanie załadowany. Dla stałych wpływających na bazę danych, limity pamięci czy tryb debugowania, wp-config.php to właściwe miejsce.
Najczęściej używane stałe
Debugowanie
define( 'WP_DEBUG', true ); // włącza tryb debugowania
define( 'WP_DEBUG_LOG', true ); // kieruje błędy do pliku debug.log
define( 'WP_DEBUG_DISPLAY', false );// nie wyświetla błędów na stronie
Stała WP_DEBUG_DISPLAY ustawiona na false ukrywa błędy przed odwiedzającymi — szczególnie ważne na stronach produkcyjnych, gdzie wyświetlanie komunikatów PHP mogłoby ujawnić ścieżki serwera i strukturę kodu. Więcej o pliku debug.log: Dziennik błędów w WordPress.
Limity pamięci
define( 'WP_MEMORY_LIMIT', '256M' ); // limit dla frontendu
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // limit dla panelu admina
Stałe te informują WordPressa, ile pamięci RAM może próbować zaalokować. Ważne zastrzeżenie: jeśli serwer narzuca niższy limit w pliku php.ini, wartość z wp-config.php nie przyniesie efektu — obowiązuje bardziej restrykcyjne z dwóch ustawień. Więcej o ograniczeniach serwera: Plik php.ini w WordPress.
Ścieżki i adresy URL
define( 'ABSPATH', dirname(__FILE__) . '/' ); // bezwzględna ścieżka do WP
define( 'WP_CONTENT_DIR', '/var/www/html/wp-content' ); // niestandardowy katalog
define( 'WP_CONTENT_URL', 'https://example.com/wp-content' );
ABSPATH jest jedną z najważniejszych stałych — WordPress używa jej do budowania ścieżek do plików rdzenia. Wiele wtyczek sprawdza jej obecność jako zabezpieczenie przed bezpośrednim dostępem do pliku.
Diagnostyka bazy danych
define( 'SAVEQUERIES', true );
Stała SAVEQUERIES instruuje WordPress, by zapisywał wszystkie zapytania SQL w tablicy diagnostycznej. Przydatna przy profilowaniu wydajności bazy danych — ale należy jej używać wyłącznie w środowiskach testowych. Na stronie produkcyjnej może wyraźnie obciążać serwer.
Ograniczenia stałych
Stałe systemowe działają na poziomie aplikacji PHP — nie zastępują ograniczeń narzucanych przez serwer. Jeśli hosting współdzielony ustawia memory_limit = 128M w php.ini, zadeklarowanie WP_MEMORY_LIMIT = '512M' nie przebije tego limitu.
W praktyce oznacza to, że przy błędach „Allowed memory size exhausted” często potrzebna jest zmiana na poziomie konfiguracji serwera (lub planu hostingowego), a nie tylko edycja wp-config.php.
Stałe zdefiniowane raz nie mogą być nadpisane przez wtyczki ani kod motywu w dalszej części wykonywania skryptu. To cecha PHP, nie WordPressa.
Stałe a opcje bazy danych
Stałe to nie to samo co opcje przechowywane w tabeli wp_options. Opcje można zmieniać przez panel administracyjny i są zapisywane w bazie danych. Stałe są „twardo” wpisane w kod — zmiana wymaga edycji pliku.
Stałe sprawdzają się dla ustawień infrastrukturalnych (tryb debugowania, ścieżki, dane logowania do bazy). Opcje — dla ustawień konfigurowanych przez właściciela strony przez interfejs.