Sekrety pliku wp-config.php

Sekrety wp-config.php

Znajdujący się w katalogu głównym WordPressa plik wp-config.php zawiera (jak sama nazwa wskazuje) podstawową konfigurację tego CMSa. Domyślnie znajdują się w nim dane niezbędne do nawiązania połączenia z bazą danych oraz klucze służące do szyfrowania danych przechowywanych w ciasteczkach. Jego podstawowa zawartość jest generowana automatycznie podczas instalacji i spora część użytkowników nie tylko nic w nim nie zmienia, ale często nawet do niego nie zagląda.

Jednak plik ten daje bardzo duże możliwości. Za jego pomocą możemy zmienić wiele parametrów WordPressa, a także rozwiązać kilka często spotykanych problemów.

Oczywiście sam plik wp-config.php nie robi nic niezwykłego. Wszystkie opisane w dalszej części wpisu ustawienia to tak naprawdę definicje stałych, które później są używane w kodzie WordPressa. wp-config.php jest po prostu dobrym miejscem na umieszczenie tych definicji – plik ten jest ładowany jako jeden z pierwszych, a poza tym nigdy nie jest nadpisywany ani usuwany w trakcie aktualizacji WordPressa.

Stałe, za pomocą których możemy modyfikować „ukryte” ustawienia WordPressa, definiuje się za pomocą funkcji define(). Może to wyglądać na przykład tak:

define('DB_NAME', 'nazwa_bazy_danych');

DB_NAME to nazwa stałej, a nazwa_bazy_danych to jej wartość. Proste.

Wszystkie dodatkowe opcje konfiguracyjne najbezpieczniej jest umieszczać zaraz przed tą linią:
/* That's all, stop editing! Happy blogging. */

Zobaczmy więc, jakie tajemnice kryje przed nami wp-config.php.

Dane bazy danych

To jedne z podstawowych i zawsze obecnych ustawień – bez nich WordPress nie będzie po prostu działał. Dane te są umieszczane w pliku wp-config.php podczas instalacji. Jeśli przenosimy stronę na inny serwer albo po prostu zmieniliśmy bazę danych, to musimy te ustawienia zmodyfikować.

  • define('DB_NAME', 'nazwa_bazy_danych'); – nazwa naszej bazy danych
  • define('DB_USER', 'nazwa_uzytkownika_bazy_danych'); – nazwa użytkownika (login) bazy danych
  • define('DB_PASSWORD', 'haslo'); – hasło do bazy danych
  • define('DB_HOST', 'localhost'); – nazwa hosta; najczęściej będzie to localhost, a jeśli nie, to trzeba zajrzeć do dokumentacji udostępnianej przez firmę hostingową lub do panelu naszego serwera

Jeśli musimy skorzystać z niestandardowego portu MySQL (innego niż 3306), to dodajemy go po dwukropku do hosta, na przykład tak: localhost:3307.

Dwie kolejne stałe są związane ze standardem kodowaniem znaków (DB_CHARSET – utf8 lub utf8mb4 od wersji 4.2) i z metodą porównywania znaków (DB_COLLATE). Tych parametrów po prostu nie ruszamy, chyba że naprawdę wiemy, co robimy.

Ostatnim parametrem związanym z bazą danych, zdefiniowanym nieco inaczej i w innym miejscu, jest prefiks nazw tabel w bazie danych. Znajduje się on w zmiennej $table_prefix i również jest tworzony podczas instalacji WordPressa. Można go oczywiście zmienić, ale do tego nie wystarczy po prostu modyfikacja zawartości tej zmiennej – trzeba jeszcze zmienić nazwy tabel w bazie danych i poszukać w niej miejsc, w których nazwy te zostały zapisane.

Klucze zabezpieczające dane przechowywane w ciasteczkach

Kluczy tych jest osiem i są one generowane w sposób pseudo-losowy podczas instalacji WordPressa. Za ich pomocą szyfrowane są dane przechowywane w ciasteczkach na komputerach naszych użytkowników. Jeśli mamy chociażby cień podejrzenia, że nasza strona mogła paść ofiarą ataku lub infekcji, należy te klucze zmienić.

define('AUTH_KEY',         'rU_~-C3FwMl6t*1J>-Rx*AIb9a7tj)[hMmGi@#CK.Jv,Vf6FE6a(S*WHU;(*AV@n');
define('SECURE_AUTH_KEY',  '}b7`l+u&Qj0F>+^[^Zu3JcHZ+CL/cY@h`aG;$G|R56e.D~sub!$A>-Y2Fhq9+uzo');
define('LOGGED_IN_KEY',    '-FBEqh:XOc,]ANjj4D-x@H5+XO!zL]-vM@>A-f,k&3{N>?[Q+o-6*9.NwK<3&q_v');
define('NONCE_KEY',        'RQSpz Ie?>z.Jv%pmXSougI$*nmo;@<d|],;Xa=s<A-x=,+L>/gl&R:[`n%44Nb/');
define('AUTH_SALT',        'ZPgo&+Ymf9>|Tyn8NQ-r_Lo2/IFf{PomhT3|j$@$0:sR6uLE Aw&S?i-6x?t^Fq5');
define('SECURE_AUTH_SALT', 'DK5+NXIg?>9a8]s&La;%#G5_-|4|+) X>qJCqAV>5EYoFqinyvR|>=AfzUR<x`g3');
define('LOGGED_IN_SALT',   ',&KAtvE-LgqDA;*SD+:n@-w?f=*_d-:N=>+VO(H+]Q<u.7!)mLTGH|`+ z]$LF@0');
define('NONCE_SALT',       'a3Ak`,*L-r9W%MP%*2>{-U|(GP+B(=x]+!|&M{7A+2Ed drW2/pVn%vv.}|,%sCH');

Do generowania kluczy służy specjalne narzędzie, ale oczywiście można te losowe ciągi znaków wymyślić sobie samodzielnie. Trzeba pamiętać, że zmiana któregokolwiek z kluczy spowoduje automatyczne wylogowanie wszystkich zalogowanych użytkowników.

Tak naprawdę tylko cztery pierwsze klucze są wymagane – jeśli nie podamy pozostałych czterech (których nazwy kończą się na _SALT) lub je usuniemy z pliku wp-config.php, to zostaną one wygenerowane automatycznie przez WordPressa.

Tryb debugowania

WordPress z włączonym trybem debugowania wyświetla na stronie wszystkie błędy, ostrzeżenia i informacje zwracane przez interpreter PHP. Pracując nad serwisem koniecznie należy włączyć ten tryb – dzięki temu jesteśmy w stanie wychwycić część błędów, w tym te najgłupsze, czyli literówki. Natomiast na dostępnej publicznie stronie tryb ten powinien być wyłączony (jest to zresztą ustawienie domyślne).

Gdy tryb debugowania jest wyłączony, wszystkie wspomniane komunikaty są ukryte. Jeśli na naszej stronie wystąpi jakiś krytyczny (czyli przerywający działanie skryptu) błąd, to zwykle zobaczymy po prostu białą stronę. W takiej sytuacji pierwszą czynnością, jaką powinniśmy wykonać, jest właśnie włączenie trybu debugowania.

Tryb debugowania włącza się przez nadanie stałej WP_DEBUG wartości true, a wyłącza nadając jej wartość false:

define('WP_DEBUG', true);  // włączamy tryb debugowania
define('WP_DEBUG', false); // wyłączamy tryb debugowania

Tryb debugowania ma kilka dodatkowych ustawień, które w pewnych sytuacjach mogą ułatwić znalezienie przyczyn problemów.

Na początek dwie opcje, które przydają się do debugowania skryptów JavaScript w panelu administracyjnym (nie na stronie). SCRIPT_DEBUG ładuje nieskompresowane wersje skryptów JavaScript, a CONCATENATE_SCRIPTS wyłącza scalanie skryptów JavaScript. Dzięki temu łatwiej możemy znaleźć w kodzie miejsce, w którym występuje problem.

Dość często zdarza się, że problem występuje tylko na wersji produkcyjnej naszej strony i po skopiowaniu jej na inny serwer (albo na nasz własny komputer) nie jesteśmy w stanie go odtworzyć. Nie jest zalecane włączanie trybu debugowania na dostępnej publicznie stronie, ale jakoś musimy przecież znaleźć przyczynę problemów. Posłużą nam do tego opcje WP_DEBUG_LOG i WP_DEBUG_DISPLAY, dzięki którym wszystkie komunikaty o błędach zamiast zostać wyświetlone na naszej stronie trafią do pliku logu na serwerze. Najprostszy sposób wykorzystania tych opcji wygląda tak:

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

Po dodaniu tych linii do pliku wp-config.php wszystkie komunikaty zostaną zapisane do pliku debug.log, znajdującego się w katalogu wp-content. Na wszelki wypadek możemy zablokować dostęp do tego pliku z zewnątrz dodając do pliku .htaccess następującą regułę:

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

Bardzo pomocną w analizowaniu problemów z wydajnością opcją jest SAVEQUERIES. Ustawienie jej na true spowoduje, że WordPress będzie zapisywał szczegółowe informacje o każdym zapytaniu do bazy danych. Informacje te można później analizować korzystając na przykład z wtyczki Debug Bar lub po prostu wyświetlić je na stronie dodając do pliku functions.php naszego motywu następujący kod:

function wpzen_display_queries() {
	if(current_user_can('manage_options')) { // wyświetlamy informacje tylko administratorom
		global $wpdb;
		echo "<pre>";
		print_r($wpdb->queries);
		echo "</pre>";
	}
}
add_action('wp_footer', 'wpzen_display_queries', 9999);

Aktualizacje WordPressa, motywów i wtyczek

W wersji 3.7 wprowadzono mechanizm automatycznych aktualizacji WordPressa, wtyczek i motywów. Domyślnie opcja ta jest włączona tylko dla samego WordPressa i działa tylko w ramach wersji głównej – czyli zaktualizuje na przykład wersję 4.2.1 do 4.2.2, ale 4.2.2 do 4.3 już nie.

Dostępnych jest kilka opcji, które dają nam kontrolę nad mechanizmem automatycznych aktualizacji. Możemy całkowicie je wyłączyć ustawiając wartość stałej AUTOMATIC_UPDATER_DISABLED na true. Z kolei opcja WP_AUTO_UPDATE_CORE określa, czy aktualizacje WordPressa mają być wyłączone (false), włączone dla wszystkich wersji (true) czy też włączone tylko w ramach wersji głównej (minor).

Na bardziej zaawansowaną konfigurację automatycznych aktualizacji pozwala darmowa wtyczka Update Control.

Mamy również możliwość wpływania na działanie samego mechanizmu aktualizacji, odpowiedzialnego za uaktualnianie WordPressa, motywów i wtyczek z poziomu panelu administracyjnego. W znacznej większości przypadków nie ma potrzeby korzystania z tych opcji, bo WordPress automatycznie powinien wybrać najlepsze ustawienia. Zdarzają się jednak sytuacje, gdy aktualizacje po prostu nie działają – wtedy zmiana tych ustawień może pomóc.

Najważniejszą opcją jest FS_METHOD, która określa sposób, w jaki WordPress będzie próbował umieścić pliki na naszym serwerze. Domyślnym ustawieniem jest direct i w większości przypadków to działa. Czasem jednak (najczęściej przez konfigurację serwera lub nieprawidłowe uprawnienia katalogów) metoda ta się nie sprawdza. Co ciekawe, spotkałem się już z przypadkiem, gdy pomimo poprawnej konfiguracji serwera aktualizacje nie działały, a rozwiązaniem było… nadanie stałej FS_METHOD wartości direct, czyli domyślnej.

Stała FS_METHOD może przyjmować następujące wartości:

  • ssh2 – korzysta z SSH i wymaga zainstalowania na serwerze modułu SSH dla PHP,
  • ftpext – korzysta z protokołu FTP i wymaga zainstalowania na serwerze modułu FTP dla PHP,
  • ftpsockets – korzysta z protokołu PHP, ale nie wymaga dodatkowych modułów.

Nie będę tu dokładnie opisywał konfiguracji poszczególnych metod, bo instrukcje można znaleźć w dokumentacji.

Adres URL naszej strony

Stałe WP_SITEURL i WP_HOME pozwalają na „nadpisanie” adresów URL naszej strony, które normalnie wprowadzamy w ustawieniach WordpPressa (opcje Ustawienia → Ogólne → Adres WordPressa i Ustawienia → Ogólne → Adres witryny). O różnicach pomiędzy tymi dwoma adresami pisałem we wpisie o przenoszeniu plików WordPressa do podkatalogu.

define('WP_SITEURL', 'http://nasza-domena.pl/wp');
define('WP_HOME', 'http://nasza-domena.pl');

Trzeba jednak pamiętać, że zmiany te nie zostaną zapisane w bazie – po usunięciu deklaracji tych stałych z pliku wp-config.php wszystko wróci do stanu poprzedniego. Aby wprowadzone w pliku konfiguracyjnym adresy zostały zapisane w bazie należy nadać stałej RELOCATE wartość true.

Co ciekawe, można ustawiać te dwie stałe dynamicznie, w taki sposób, aby zawsze przyjmowały adres wpisany w przeglądarce. Ułatwia to na przykład korzystanie z tej samej konfiguracji na serwerze lokalnym i testowym.

define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME'].'/wp');
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']);

Przenoszenie i zmiana nazw katalogów WordPressa

Za pomocą odpowiednich stałych zdefiniowanych w pliku wp-config.php możemy zmienić nazwę i lokalizację niektórych katalogów WordPressa. Zmian tych możemy dokonać dla następujących katalogów:

  • wp-content – w tym katalogu znajdują się wtyczki, motywy oraz wszystkie pliki użytkownika; stałe: WP_CONTENT_DIR (nazwa katalogu na serwerze) i WP_CONTENT_URL (adres URL katalogu),
  • plugins – katalog, w którym znajdują się wtyczki; stałe: WP_PLUGIN_DIR, PLUGINDIR (dla zachowania wstecznej kompatybilności) i WP_PLUGIN_URL,
  • mu-plugins – katalog, w którym znajdują się wtyczki „must-use”, czyli takie, których nie da się dezaktywować (są zawsze włączone); stałe: WPMU_PLUGIN_DIR, MUPLUGINDIR (dla zachowania wstecznej kompatybilności) i WPMU_PLUGIN_URL,
  • uploads – katalog, do którego trafiają wszystkie pliki użytkownika (przesłane do biblioteki mediów lub zapisywane przez różne wtyczki); stała: UPLOADS.

Przykładowy kod zmieniający położenie tych katalogów może wyglądać tak:

define('WP_CONTENT_DIR', dirname(__FILE__).'/assets');
define('WP_CONTENT_URL', 'http://nasza-domena.pl/assets');
define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/extensions');
define('PLUGINDIR', WP_CONTENT_DIR.'/extensions');
define('WP_PLUGIN_URL', WP_CONTENT_URL.'/extensions');
define('UPLOADS', 'assets/media');

Warto zwrócić uwagę na katalog podany w stałej UPLOADS – znajduje się on zawsze wewnątrz katalogu WordPressa (stała ABSPATH).

Niestety, nie ma możliwości przeniesienia katalogu z motywami, ale za pomocą funkcji register_theme_directory() możemy dodać kolejny katalog, w którym WordPress będzie szukał motywów i w którym możemy umieścić na przykład stworzony przez nas motyw potomny.

Trzeba pamiętać, że samo ustawienie odpowiednich stałych nie spowoduje automatycznego przeniesienia odpowiednich katalogów ani zmiany ich nazw na serwerze – musimy to zrobić ręcznie.

Wersjonowanie wpisów

Mechanizm wersjonowania przechowuje kolejne wersje naszych wpisów i pozwala na odtworzenie dowolnej z nich oraz porównanie poszczególnych rewizji pod kątem wprowadzonych zmian. W pliku wp-config.php możemy wyłączyć całkowicie ten mechanizm nadając stałej WP_POST_REVISIONS wartość false lub ograniczyć liczbę przechowywanych wersji wpisując do tej stałej odpowiednią liczbę.

define('WP_POST_REVISIONS', false); // całkowicie wyłączamy wersjonowanie
define('WP_POST_REVISIONS', 5); // przechowujemy tylko 5 ostatnich wersji wpisu

Kosz w bibliotece mediów

Domyślnie biblioteka mediów nie ma kosza, do którego trafiają usunięte elementy, przez co kasowanie multimediów jest nieodwracalne. Można jednak włączyć tę funkcję nadając stałej MEDIA_TRASH wartość true. Więcej na ten temat znajdziecie w tym wpisie.

Częstotliwość automatycznego zapisywania wpisów

Edytor WordPressa co jakiś czas automatycznie zapisuje edytowany przez nas wpis, tak aby nagłe wyłączenie komputera czy zamknięcie okna przeglądarki nie spowodowało utraty efektów naszej pracy. Domyślnie taki zapis jest wykonywany co 60 sekund, ale czas ten można wydłużyć lub skrócić nadając odpowiednią wartość stałej AUTOSAVE_INTERVAL.

define('AUTOSAVE_INTERVAL', 300); // automatyczny zapis co 300 sekund (5 minut)

Automatyczne opróżnianie kosza

Usuwane wpisy i strony są przenoszone do kosza, z którego w każdej chwili możemy je przywrócić. Nie leżą one tam jednak wiecznie – kosz jest okresowo opróżniany. Domyślnie usuwane są wpisy, które znajdują się w koszu dłużej niż 30 dni. Okres ten możemy zmienić korzystając ze stałej EMPTY_TRASH_DAYS.

define('EMPTY_TRASH_DAYS', 60); // wpisy będą usuwane z kosza po 60 dniach

Wydawać by się mogło, że ustawienie wartości tej stałej na 0 (zero) lub false spowoduje, że wpisy nie będą w ogóle usuwane z kosza. Nic bardziej mylnego – efektem będzie całkowite wyłączenie funkcji kosza. Wpisy będą usuwane od razu, na dodatek bez żadnego ostrzeżenia – jedyną zauważalną zmianą będzie inna treść linku usuwającego wpis: Usuń na zawsze zamiast Do kosza.

Aby wyłączyć automatyczne opróżnianie kosza można ustawić wartość stałej EMPTY_TRASH_DAYS na jakąś bardzo dużą liczbę (na przykład 18250 – czyli 50 lat) lub dodać do pliku functions.php motywu lub do pliku wtyczki następujący kod:

function wpzen_remove_scheduled_delete() {
    remove_action('wp_scheduled_delete', 'wp_scheduled_delete');
}
add_action('init', 'wpzen_remove_scheduled_delete');

Zwiększenie limitu pamięci dla PHP

W dużym uproszczeniu, im bardziej rozbudowana jest nasza strona, tym więcej pamięci serwera potrzebuje. Z różnych przyczyn serwery mają ustawiony limit pamięci, którą może „zużyć” interpreter PHP. Domyślnie WordPress próbuje (bo nie każdy serwer na to pozwala) ustawić ten limit na 40 MB, co w dzisiejszych czasach nie jest dużą wartością. Jednak wystarczy zainstalować jakąś większą wtyczkę czy bardziej rozbudowany (a raczej wypchany zbędnymi funkcjami) motyw premium, aby limit ten okazał się zbyt niski i nasza strona przestała działać (więcej na ten temat znaleźć można w tym wpisie). W takim przypadku możemy spróbować zwiększyć limit pamięci korzystając ze stałej WP_MEMORY_LIMIT:

define('WP_MEMORY_LIMIT', '64M'); // ustawiamy limit pamięci na 64 MB

Co ciekawe, istnieje jeszcze stała WP_MAX_MEMORY_LIMIT, która ustawia osobny limit pamięci dla panelu administracyjnego (niektóre jego elementy mogą być nieco bardziej „zasobożerne”):

define('WP_MAX_MEMORY_LIMIT', '128M'); // ustawiamy limit pamięci dla panelu na 128 MB

Naprawianie uszkodzonych tabel w bazie danych

Okazjonalnie (a tak naprawdę bardzo rzadko) tabele w bazie danych ulegają uszkodzeniu, co objawia się komunikatem o nieudanym połączeniu z bazą danych lub o braku możliwości odczytu danych z którejś z tabel. Przyczyn tego zjawiska może być kilka, ale chyba najczęstszą jest brak miejsca na dysku serwera. Więcej na ten temat pisałem w tym wpisie.

WordPress posiada wbudowane narzędzie do sprawdzania i naprawy uszkodzonych tabel. Jest ono jednak domyślnie wyłączone – aby je włączyć należy ustawić wartość stałej WP_ALLOW_REPAIR na true.

define('WP_ALLOW_REPAIR', true);

Teraz możemy uruchomić wspomniane narzędzie wpisując w przeglądarce adres http://nasza-domena.pl/wp-admin/maint/repair.php. Wykona ono sprawdzenie tabel w bazie danych (CHECK), naprawę tych, które zostały rozpoznane jako uszkodzone (REPAIR) oraz analizę (ANALYZE) i optymalizację (OPTIMIZE) wszystkich tabel. Warto dodać, że dostęp do tego narzędzia nie wymaga autoryzacji, dzięki czemu działa ono nawet gdy uszkodzona zostanie tabela z danymi użytkowników i nie można zalogować się do panelu administracyjnego.

Wyłączenie WordPressowego crona

WordPress posiada wbudowany mechanizm automatycznego uruchamiania różnych procesów w określonych interwałach (np. co godzinę lub raz dziennie). W ten sposób są na przykład publikowane zaplanowane wpisy. Mechanizm ten jest bardzo przydatny, szczególnie że wtyczki mogą dodawać do niego własne procesy.

Działanie tego mechanizmu jest jednak uzależnione od ruchu na naszej stronie – proces zostanie uruchomiony tylko wtedy, gdy ktoś wejdzie na naszą witrynę. Dlatego też jeśli nasz serwis ma niewielką oglądalność lub chcemy uruchamiać zaplanowane procesy z najlepszą możliwą dokładnością, możemy sami zadbać o jego prawidłowe działanie.

W tym celu najpierw należy wyłączyć WordPressowego crona:

define('DISABLE_WP_CRON', true);

A następnie w panelu administracyjnym naszego serwera dodać do systemowego crona wywołanie co na przykład 15 minut takiego polecenia:

wget -q -O - http://nasza-domena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Jeśli jednak korzystamy z domyślnego sposobu działania tego mechanizmu, to pomocna może okazać się stała WP_CRON_LOCK_TIMEOUT, za pomocą której ustalimy jak często mogą być uruchamiane procesy.

define('WP_CRON_LOCK_TIMEOUT', 60); // proces może być uruchamiany co najwyżej raz na minutę

Dzięki temu unikniemy sytuacji, w której jakaś wtyczka wymusi uruchamianie skryptu co 10 sekund, co może spowodować niepotrzebne obciążenie serwera (na przykład gdy co 10 sekund uruchamiany jest proces wykonujący się dłużej, niż 10 sekund).

Ustawienia ciasteczek (cookies)

WordPress pozwala na zmianę kilku parametrów ciasteczek, ale tak naprawdę przydatne jest tylko jedno ustawienie: COOKIE_DOMAIN.

define('COOKIE_DOMAIN', 'nasza-domena.pl');

Opcja ta pozwala na „wymuszenie” domeny, dla której ustawiane są ciasteczka. Dodawanie tej stałej do wp-config.php ma sens tylko wtedy, gdy korzystamy z subdomen do serwowania statycznych treści (na przykład obrazków czy innych multimediów) i nie chcemy, aby dla tych subdomen były ustawiane ciasteczka.

Wyłączenie edytora motywów i wtyczek w panelu administracyjnym

Zarówno z przyczyn związanych z bezpieczeństwem, jak i z możliwością łatwego zepsucia naszej strony, nie powinniśmy używać dostępnego w panelu administracyjnym WordPressa edytora wtyczek i motywów. Aby nikogo nie kusiła możliwość skorzystania z tego narzędzia, najlepiej jest po prostu je wyłączyć:

define('DISALLOW_FILE_EDIT', true);

Nieco bardziej restrykcyjną opcją jest DISALLOW_FILE_MOD, która wyłącza nie tylko edytor motywów i wtyczek, ale również możliwość ich instalacji i aktualizacji.

define('DISALLOW_FILE_MOD', true);

Wymuszenie logowania przez połączenie szyfrowane SSL

Jeśli cała nasza strona jest dostępna przez połączenie szyfrowane, to opcja ta nie ma dla nas większego znaczenia (co nie znaczy, że nie możemy jej – na wszelki wypadek – włączyć). Jeśli jednak nie posiadamy certyfikatu SSL, a mimo to chcielibyśmy wymusić logowanie i korzystanie z panelu administracyjnego przez połączenie szyfrowane (na przykład używając samodzielnie podpisanego certyfikatu), wystarczy ustawić stałą FORCE_SSL_ADMIN na true:

define('FORCE_SSL_ADMIN', true);

UWAGA: jeśli korzystamy z samodzielnie podpisanego certyfikatu SSL lub z certyfikatu SSL naszej firmy hostingowej, to przy pierwszym otwarciu strony w połączeniu szyfrowanym (https) przeglądarka wyświetli ostrzeżenie.

Blokowanie komunikacji z zewnętrznymi serwisami

Wiele wtyczek i motywów wysyła żądania HTTP do różnych zewnętrznych serwisów. Mogą one służyć do pobierania jakichś danych, sprawdzania uaktualnień czy wysyłania informacji o naszej stronie. Dotyczy to głównie produktów komercyjnych, bo wtyczki i motywy dostępne w oficjalnym repozytorium nie mogą tego robić (przynajmniej teoretycznie). Zwykle taka komunikacja nie stanowi żadnego zagrożenia, ale możemy zwyczajnie nie chcieć, aby coś takiego działo się na naszej stronie. Zdarza się też, że spowalnia to działanie naszej strony, na przykład gdy czas odpowiedzi zewnętrznego serwera jest zbyt długi lub gdy wysyłanych żądań jest zbyt dużo.

Za pomocą stałej WP_HTTP_BLOCK_EXTERNAL możemy całkowicie zablokować wysyłanie żądań HTTP do zewnętrznych serwisów. Możemy też odblokować wybrane domeny (np. api.wordpress.org) za pomocą stałej WP_ACCESSIBLE_HOSTS.

define('WP_HTTP_BLOCK_EXTERNAL', true);
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com'); // zezwalamy na wysyłanie żądań do api.wordpress.org i całej domeny github.com

UWAGA: opcje te działają tylko dla żądań HTTP wykonywanych za pomocą HTTP API WordPressa. Nie mają one żadnego wpływu na inne metody komunikacji z serwerami zewnętrznymi (jak na przykład cURL), przez co w praktyce nie można na nich całkowicie polegać.

Usuwanie niepotrzebnych wersji obrazków

WordPressowy edytor obrazków po każdej edycji zapisuje na dysku serwera nowy zestaw (wszystkie rozmiary) plików i nie usuwa ich nawet gdy przywrócimy oryginalną wersję obrazka. Jeśli intensywnie korzystamy z tego narzędzia, to z czasem na serwerze możemy zgromadzić całkiem sporą kolekcję niepotrzebnych plików.

Stała IMAGE_EDIT_OVERWRITE zmienia działanie edytora. Po ustawieniu jej wartości na true na serwerze zapisywany jest tylko jeden komplet plików po edycji, który po przywróceniu oryginału jest automatycznie usuwany.

Bezpośredni link