Poznaj wp-config.php. „Ukryte” możliwości WordPress.
Jednym z najważniejszych plików instalacji WordPress jest plik wp-config.php. Znajduje się w katalogu głównym plików WordPress. Zawiera podstawowe dane konfiguracyjne twojej witryny, ale także daje możliwość wykorzystania „ukrytych” możliwości konfiguracji WordPress. Czy już o nich wiesz?
Zawiera on definicję stałych uruchamiających lub zmieniających wybrane funkcjonalności, które używane są przez WordPress. Stałe te dają możliwość dostosowania naszego WP do własnych potrzeb.
Jest on tworzony w procesie instalacji WordPress lub można go utworzyć ręczenie na podstawie przykładowego pliku wp-config-sample.php i edytując go zgodnie z wymogami.
Należy też wspomnieć, że plik wp-config.php jest plikiem, który nie jest nadpisywany przy aktualizacjach.
Domyślnie utworzony plik wygląda następująco:
define('DB_NAME', 'name db');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', ' ');
define('AUTH_KEY', '+g.0v}>vg^14lQ6|>>S DdpCqv.qNfgF:Yq^11^M(u_0]G_4Y!})8}*6mpU.[0Q}');
define('SECURE_AUTH_KEY', '@Es^xmIAo>C2N>qvCez`|:Op.Jj*.NyKZ/^6giX;$PqxLR9hT^U&qKClP1DH5T!7');
define('LOGGED_IN_KEY', 'b=FYw1eZ:7$v v&`Y+Pu:uwlot-:oB]`V}$G7Uac$zDS{*Qb[Wm*doBsaX*+wBeM');
define('NONCE_KEY', ' x%Iri3 S[[d^FZ:yxm+3=^OP:Z?(v.3Xgz3*N`J+JF,KzAX,~T AZ6R|3Np?k@!');
define('AUTH_SALT', 'jHa_j%8n=40E B-)XD -S|UV3V-?-:b[(PD_NQ7!&I<(vl}ZllQGw|5W{.H@y/<');
define('SECURE_AUTH_SALT', 'qs/E+y<-V9S1-%2zq6%w[KIS;Jv/),A*lrK|r >^<`jGGY-~Q1L6Ii~P$~j^C(&2');
define('LOGGED_IN_SALT', 'pndG UJ6KG7uE~6IU#4sUH=fl88{<M&vl2hkIUUg`=^Mt^=xOz[Fs$ }3u[P^*3A');
define('NONCE_SALT', 'Xf8j4Ry2[&FA$Nc}8.SYIIH/5_8VH2xSW6D;ly~:}}Zimvlcri}YI+g9~r}a');
$table_prefix = 'wp_';
define('WP_DEBUG', false);
/** Absolutna ścieżka do katalogu WordPressa. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/** Ustawia zmienne WordPressa i dołączane pliki. */
require_once(ABSPATH . 'wp-settings.php');
Zaczynamy zmiany!
Warto wiedzieć i pamiętać, że zanim zaczniemy zmiany należy zrobić kopię bezpieczeństwa (tak na wszelki wypadek, gdyby coś poszło źle). Najlepiej zmiany wprowadzać na środowisku testowym ew. localhost. Odradzamy zabawy i testy w środowisku produkcyjnym. Chyba wiemy co robimy. Nie dajmy się zwariować, zmiany wprowadzane w pliku wp-config.php są odwracalne, należy tylko zmienić treść odpowiednich linii i zapisać zmiany.
Rozpoczniemy od zmian związanych z bazą danych.
define('DB_NAME', 'database_name_here');
define('DB_USER', 'username_here');
define('DB_PASSWORD', 'password_here');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', ' ');Patrząc po kolei od góry, pierwsza stała DB_NAME określa nazwę bazy danych, DB_USER to nazwa użytkownika, który loguje się do bazy, DB_PASSWORD to kod użytkownika.
DB_HOST określa host do łączenia z bazą. Tu trzeba zaznaczyć, że wartość tej stałej możemy podać na kilka sposobów pokazanych poniżej:
define('DB_HOST', '127.0.0.1:3307');
define('DB_HOST', 'localhost:3307');
define('DB_HOST', 'mysql.serwer.com:3307');
// If your host uses Unix sockets or pipes, adjust the DB_HOST
define('DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock');
define('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock');
define('DB_HOST', 'mysql.serwer.com:/var/run/mysqld/mysqld.sock');Dwie ostatnie stałe DB_CHARSET i DB_COLLATE związane są ze standardem kodowania i metodą porównywania znaków.
Sortowanie odnosi się do kolejności sortowania liter, cyfr i symboli danego zestawu znaków. WordPress domyślnie używa zestawu znaków UTF-8 (utf8), a gdy tabele bazy danych MySQL WordPress są tworzone podczas procesu instalacji, MySQL przypisuje do tych tabel utf8_general_ci sortowanie.
Prefiks nazw tabel w bazie danych.
Kolejną stałą związaną z bazą danych jest $table_prefix . Określa ona prefiks w bazie danych, jaki zostanie utworzony przy instalacji WordPress.
$table_prefix = 'wp_';
Dodatkowo warto wiedzieć, że domyślnie wartość prefiksu jest ustawiona jako ‚wp_’. Zaleca się zmianę tej wartości na inną ze względów bezpieczeństwa. Zmianę taką można zrobić w czasie procesu instalacji lub poźniej, podając inną wartość. Tu trzeba pamiętać, że w tym wypadku nie wystarczy zmienić stałą $table_prefix, ale także trzeba dokonać zmian w bazie danych. Poprzez phpMyAdmin lub korzystając np. z wtyczki Better Search Replace. Do zmiany prefiksu możemy używać nastepujących znaków: liczby, litery i ‚ _ ’.
Jeśli używamy różnych prefiksów to możemy w jednej bazie mieć tabele z 2 lub więcej różnych instalacji WordPress. Nie jest to zalecane ze względów bezpieczeństwa.
Zmiana nazwy w tabeli użytkowników i opisu użytkowników.
Domyślnie dane użytkowników (login, hasło, i… itp) są trzymane w dwóch tabelach users i users_meta w bazie naszego WordPress. Aby to zrobić, należy zmienić nazwy wcześniej wspomnianych tabel w bazie na inne oraz podać te nazwy w pliku wp-config.php , używając dwóch stałych: CUSTOM_USER_TABLE i CUSTOM_USER_META_TABLE
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );
Jak już jesteśmy przy bazie danych, to należy wspomnieć o możliwości przeniesienia danych do połączenia z bazą do zewnętrznego pliku, który tylko dołączymy komendą require_once w pliku wp-config.php
require_once 'nazwa_pliku.php';Secret keys – Unikatowe klucze uwierzytelniania i sole.
Są to unikatowe klucze, które zabezpieczają dane przechowywane w ciasteczkach. Możemy je zmienić. Trzeba pamiętać, że zmiana któregokolwiek klucza spowoduje wylogowanie wszystkich zalogowanych użytkowników. 4 pierwsze są wymagane.
Jeśli chcemy samodzielnie zmienić klucze, pomocne może być narzędzie – generator kluczy
https://api.wordpress.org/secret-key/1.1/salt/
Poniżej przykładowe klucze.
define('AUTH_KEY', '+g.0v}>vg^14lQ6|>>S DdpCqv.qNfgF:Yq^11^M(u_0]G_4Y!})8}*6mpU.[0Q}');
define('SECURE_AUTH_KEY', '@Es^xmIAo>C2N>qvCez`|:Op.Jj*.NyKZ/^6giX;$PqxLR9hT^U&qKClP1DH5T!7');
define('LOGGED_IN_KEY', 'b=FYw1eZ:7$v v&`Y+Pu:uwlot-:oB]`V}$G7Uac$zDS{*Qb[Wm*doBsaX*+wBeM');
define('NONCE_KEY', ' x%Iri3 S[[d^FZ:yxm+3=^OP:Z?(v.3Xgz3*N`J+JF,KzAX,~T AZ6R|3Np?k@!');
define('AUTH_SALT', 'jHa_j%8n=4#0E B-)XD -S|UV3V-?-:b[(PD_NQ7!&I<(vl}ZllQGw|5W{.H@y/<');
define('SECURE_AUTH_SALT', 'qs/E+y<-V9S1-%2zq6%w[KIS;Jv/),A*lrK|r >^<`jGGY-~Q1L6Ii~P$~j^C(&2');
define('LOGGED_IN_SALT', 'pndG UJ6KG7uE~6IU#4sUH=fl88{<M&vl2hkIUUg`=^Mt^=xOz[Fs$ }3u[P^*3A');
define('NONCE_SALT', 'Ck:FXf8j4Ry2[&FA$Nc}8.SYIIH/5_8VH2xSW6D;ly~:}}Zimvlcri}YI+g9~r}a');Tryb debagowania.
Używamy go do wyszukiwania błędów i prac deweloperskich. Jeśli nie ma takiej konieczności lepiej nie używać go na produkcji. Aby włączyć tryb pokazywania błędów używamy stałej WP_DEBUG, poniżej przykładowy kod.
define('WP_DEBUG', true);WordPress daje nam tu więcej możliwości. Jeśli z kiegoś powodu chcemy zobaczyć błędy na wersji produkcyjnej serwisu, to tym przypadku lepiej jest błędy kierować do pliku niż pokazywać na ekranie, oczywiście ze względów bezpieczeństwa. Możemy to zrobić poniższymi liniami kodu. Pierwszą stałą WP_DEBUG włączamy tryb debugowania, drugą WP_DEBUD_DISPLAY blokujemy pokazywanie błędów na ekranie, trzecia natomiast powoduje, że błędy są zapisywane do pliku debug.log, który jest umieszczony w folderze /wp-content/
Ustawienia php muszą pozwalać na wyświetlanie błędów – można to zrobić w pliku php.ini
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
Plik debug.log jest ogólnodostępny, dlatego warto nadać upewnienia 600 tylko do odczytu i zablokować do niego dostęp z zewnątrz poprzez plik .htaccess, dodając do niego poniższy kod:
<Files debug.log>
Order allow,deny
Deny from all
</Files>Koleją stałą, którą możemy wykorzystać przy debugowaniu, jest SCRIPT_DEBUG – jest stałą pokrewną, która zmusi WordPress do używania wersji „dev” niektórych podstawowych plików CSS i JavaScript zamiast zminiaturyzowanych wersji, które normalnie są ładowane. Niektóre skrypty nie honorują SCRIPT_DEBUG. Domyślna wartość to fałsz.
define( 'SCRIPT_DEBUG', true );
SAVEQUERIES zapisuje zapytania do bazy danych do tablicy. Tablica może być wyświetlana, aby pomóc w analizowaniu tych zapytań.
Stała zdefiniowana jako true powoduje, że każde zapytanie zostanie zapisane, jak długo trwało wykonywanie tego zapytania i jaka funkcja je wywołała.
define( 'SAVEQUERIES', true ); Tablica jest przechowywana w globalnych zapytaniach $wpdb->queries. UWAGA: będzie to miało wpływ na wydajność witryny, więc pamiętaj, aby wyłączyć tę opcję, gdy nie debugujesz. Np. w pliku footer.php umieszczamy kod:
if ( current_user_can( 'administrator' ) ) {
global $wpdb;
echo "<pre>";
print_r( $wpdb->queries );
echo "</pre>";
}
Podsumowując tryb debugowania, możemy użyć poniższego przykładu do wersji testowej.
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );
Pamiętaj, że przedstawione zmiany powinny być w pliku wp-config.php przed linią z komentarzem:
/* That’s all, stop editing! Happy blogging. */
Debagowanie także możemy zrobić używając pluginów np:
Query Monitor, Debug Bar, Log Deprecated Notices
Wyłączenie edycji plików motywów i wtyczek.
Z poziomu panelu administracyjnego WordPress domyślnie mamy możliwość zobaczenia i edytowania plików, motywów i wtyczek. O ile dla admina ta opcja może być przydatna to w rękach niepowołanego użytkownika z prawami administracyjnymi może przysporzyć kłopotów, uszkodzić stronę. Aby temu zapobiec możemy wyłączyć możliwość edycji plików używając stałej DISALLOW_FILE_EDIT . Trzeba jednak pamiętać, że dostęp z poziomu ftp do edycji tych plików będzie możliwy.
define('DISALLOW_FILE_EDIT', true);
Kontrola nad mechanizmem automatycznych aktualizacji.
Aktualizacje, core WordPress, motywów i pluginów mogą mieć istotny wpływ na bezpieczeństwo i stabilność działania strony internetowej. Mamy możliwość kontroli mechanizmu aktualizacji poprzez nastepujące stałe: AUTOMATIC_UPDATER_DISABLED odpowiada za wyłączenie mechanizmu automatycznych aktualizacji. Natomiast druga stała WP_AUTO_UPDATE_CORE, określa czy aktualizacje WordPress mają być włączone dla wszystkich wersji true (wartość domyślna dla development site), wyłączone false lub włączone w ramach wersji głównej minor – wartość domyślna.
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', true );
Wyłączenie możliwość instalacji wtyczek i motywów.
define( 'DISALLOW_FILE_MODS', true );Blokuje możliwość instalacji wtyczek i motywów oraz edycji plików motywów i wtyczek po zalogowaniu się do kokpitu WordPress. Nie trzeba ustawiać razem DISALLOW_FILE_MODS i DISALLOW_FILE_EDIT, obie będą działały tak samo.
Zmiana adresu strony URL.
Kiedy chcemy przenieść stronę pomiędzy domenami, serwerami z pomocą przychodzą dwie zmienne: WP_SITEURL i WP_HOME. Pierwsza pozwala zdefiniować adres gdzie znajdują się pliki główne, w tym przypadku jest to katalog „wordpress”, druga pozwala zdefiniować adres, jaki wpisujemy w przeglądarce.
Należy pamiętać, że podane wartości tylko przesłaniają wartości podane w tabeli bazy danych ale ich nie nadpisują. Na początku definiowania podajemy http lub https, nie podajmy na końcu „/”.
define( 'WP_SITEURL', 'http://testowa.pl/wordpress' );
define( 'WP_HOME', 'http://testowa.pl' );
Opcjonalnie adres strony URL można ustawić dynamicznie w oparciu o php wartość nagłówka HTTP_HOST, gdy apache jest skonfigurowany jako UseCanonicalName, wartość „on”. SERVER_NAME jest ustawiony przez konfigurację serwera.
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME'].'/wordpress'); define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']);
Przenoszenie i zmiana nazw wybranych katalogów instancji WordPress.
Zmiany możemy wprowadzać dla nastepujących katalogów / folderów:
- wp-content – zawiera: motywy, wtyczki, pliki użytkownika. Stałe do zdefiniowania: WP_CONTENT_DIR (nazwa katalogu na serwerze) i WP_CONTENT_URL (adres URL katalogu),
- plugins – zawiera: wtyczki. Stałe do zdefiniowania: WP_PLUGIN_DIR, i WP_PLUGIN_URL,
- mu-plugins – zawiera: wtyczki „must-use”, takie których nie można zdezaktywować. Stałe do zdefiniowania: WPMU_PLUGIN_DIR, i WPMU_PLUGIN_URL
- uploads – tu trafiają pliki użytkownika przesłane do biblioteki mediów, także te zapisywane przez wtyczki. Stałe do zdefiniowania: UPLOADS
Poniżej przykładowa definicja zmiany nazw katalogów.
define('WP_CONTENT_DIR', dirname(__FILE__).'/newcontent');
define('WP_CONTENT_URL', ‚http://testowa.pl/newcontent');
define('WP_PLUGIN_DIR', WP_CONTENT_DIR.’/newplugins);
define( 'WP_PLUGIN_URL', 'http://testowa/newcontent/newplugins' );
define('WP_PLUGIN_URL', WP_CONTENT_URL.'/newplugins');
define('PLUGINDIR', WP_CONTENT_DIR.’/newplugins');
define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/mu-plugins' );
define('UPLOADS', 'newupload/media');
Warto wiedzieć:
- Zdefiniowanie tych stałych nie zmienia nazw katalogów na serwerze. Wprowadzając powyższe stałe musimy zrobić „ręcznie” zmianę nazw i lokalizacji katalogów do tych podanych powyżej np. przez ftp.
- Nie możemy przenieść katalogu/folderu themes (motywy).
- Możemy zdefiniować nowy katalog / folder w którym będziemy umieszczać nasze motywy / motywy potomne, szczegóły : https://codex.wordpress.org/register_theme_directory
Zmiana AutoSave Interval – zmiana czasu automatycznego zapisywania postów w trakcie edycji.
Podczas edytowania posta WordPress używa Ajax do automatycznego zapisywania poprawek do wpisu podczas edycji. Możesz zwiększyć to ustawienie, aby uzyskać dłuższe opóźnienia pomiędzy automatycznymi zapisami lub zmniejszyć ustawienie, aby upewnić się, że nigdy nie stracisz zmian. Wartość domyślna to 60 sekund.
define( 'AUTOSAVE_INTERVAL', 160 ); // SecondsUstawienia ilości kopii / wersji wpisów trzymanych w bazie danych.
WordPress domyślnie zapisuje kopie każdej edycji dokonanej w poście lub stronie, umożliwiając przywrócenie poprzedniej wersji tego postu lub strony. Zapisywanie wersji może zostać wyłączone lub można określić maksymalną liczbę wersji dla jednego postu lub strony.
define('WP_POST_REVISIONS', false);
// całkowicie wyłączamy wersjonowanie
define('WP_POST_REVISIONS', 3);
// przechowujemy tylko 3 ostatnie wersje wpisu
Automatyczne opróżnianie kosza.
Gdybyśmy chcieli aby kosz opróżniał się automatycznie:
define('EMPTY_TRASH_DAYS', 30);
// wpisy będą usuwane z kosza po 30 dniach Ustawienie tej zmiennej na 0 lub false nie spowoduje braku usuwania wpisów. Aby zablokować usuwanie wpisów należy podać możliwie długi czas np. 10 950 – to ok 30 lat. Drugą metodą jest możliwość ustawienia tego w pliku function.php
Włączanie kosza w bibliotece mediów.
define('MEDIA_TRASH', true);
// W bibliotece mediów zamiast usuń pojawi się kosz
define('MEDIA_TRASH', false);
// Wyłączenie kosza w bibliotece mediów [/php]Usuwanie nadmiarowych zestawów obrazków.
Domyślnie WordPress tworzy nowy zestaw obrazów za każdym razem, gdy edytujesz obraz, a po przywróceniu oryginału pozostawia wszystkie modyfikacje na serwerze. Definiowanie IMAGE_EDIT_OVERWRITE jako true zmienia to zachowanie. Tylko jeden zestaw zmian obrazu zostanie utworzony, a po przywróceniu oryginału zmiany zostaną usunięte z serwera.
define( 'IMAGE_EDIT_OVERWRITE', true );Włączenie Multisite.
Czasem jest potrzeba posiadania kilku stron w osobnych subdomenach lub subkatalogach naszej domeny, tak aby każda miała swój panel administracyjny. Tu WordPress ma dla nas duże ułatwienie, wystarczy włączyć tryb multisite i wybrać czy chcemy mieć subdomeny czy subkatalogi i to wszystko za pomocą jednej stałej WP_ALLOW_MULTISITE.
define( 'WP_ALLOW_MULTISITE', true ); Zmiana limitu pamięci.
Możemy zmień limit pamięci dla php. Zmiana jest możliwa jeśli hosting na to pozwala. Domyślna wartość 64MB. Dla panelu admina możemy ustawić osobny limit pamięci, jak w przykładzie poniżej.
define('WP_MEMORY_LIMIT', '64M');
// ustawiamy limit pamięci na 64 MB
define('WP_MAX_MEMORY_LIMIT', '128M');
//ustawiamy limit pamięci dla panelu na 128 MB [/php]WP Cache – cache w WordPress.
Ustawienie WP_CACHE, jeśli jest true, zawiera skrypt wp-content / advanced-cache.php podczas wykonywania wp-settings.php.
define( 'WP_CACHE', true ); Naprawianie uszkodzonych tabel w bazie danych.
WordPress posiada wbudowane narzędzie do sprawdzania i naprawy uszkodzonych tabel. Domyślnie jest wyłączone. 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. Narzędzie możemy uruchomić wpisując w przeglądarce adres: http://naszadomena.pl/wp-admin/maint/repair.php.
define('WP_ALLOW_REPAIR', true); Przekierowanie NOBLOGREDIRECT.
Przekieruj nieistniejące „blog…” NOBLOGREDIRECT może być użyty do przekierowania przeglądarki, jeśli użytkownik próbuje uzyskać dostęp do nieistniejącej witryny przy użyciu subdomeny lub podfolderu. Np. Http://nonexistent.naszadomena.pl lub http://naszadomena.pl/nonexistent/.
define( 'NOBLOGREDIRECT', 'http://naszadomena.pl' ); Mechanizm WP Cron & Cron timeout – kontrola nad czasem wykonywania skryptów.
define( 'DISABLE_WP_CRON', true );
define( 'WP_CRON_LOCK_TIMEOUT', 60 );Pierwsza linia wyłącza crona WordPress. Druga określa jak często mogą być uruchomiane procesy, czas w sekundach. Przykładowe zastosowanie crona np. publikowanie zaplanowanych wpisów, wykonywanie skryptów.
Uwaga ! Działanie WP Crona jest uzależnione od ruchu na stronie. Jeśli nie ma ruchu na stronie a chcemy korzystać z funkcjonalności crona to lepiej używać systemowego corn’a serwera.
WP Wymuszenie logowania dla admin SSL.
define('FORCE_SSL_ADMIN', true); Jeśli używamy ssl (https), to nie musimy tego ustawiać. Jeśli strona nie ma ssl, a chcemy wymusić połączenie szyfrowane, np. używając samodzielnie podpisanego certyfikatu, to ustawiamy wartość na true.
Wyłącz niefiltrowany HTML dla wszystkich użytkowników.
define( 'DISALLOW_UNFILTERED_HTML', true); Użytkownicy z rolami administratora lub edytora mogą publikować niefiltrowany kod HTML w postach i komentarzach. W WordPress Multisite tylko Super Admin może opublikować niefiltrowany HTML, ponieważ wszyscy inni użytkownicy są uznawani za niezaufanych. Aby wyłączyć niefiltrowany kod HTML dla wszystkich użytkowników, w tym dla administratorów, możesz dodać powyższą stałą.
Zastąpienie domyślnych uprawnień do plików.
define ('FS_CHMOD_DIR', (0755 ~ umask ()));
define ('FS_CHMOD_FILE', (0644 i ~ umask ())); Instrukcje definiowania FS_CHMOD_DIR i FS_CHMOD_FILE umożliwiają zastąpienie domyślnych uprawnień do plików. Te dwie zmienne zostały opracowane w odpowiedzi na problem polegający na tym, że funkcja aktualizacji rdzenia nie działa z hostami działającymi pod kontrolą suexec. Jeśli host używa restrykcyjnych uprawnień do plików (na przykład 400) dla wszystkich plików użytkownika i odmawia dostępu do plików z ustawionymi uprawnieniami grupowymi lub światowymi, te definicje mogą rozwiązać problem. ’0755′ jest wartością ósemkową. Wartości ósemkowe muszą być poprzedzone wartością 0 i nie są ograniczone pojedynczymi cudzysłowami (’).
Źródło, CODEX – https://codex.wordpress.org/
