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 pliki który nie jest nadpisywany przy aktualizacjach.

Domyślnie utworzony plik wygląda następująco:

   
/** Konfiguracja połączenia z Bazą danych */

define('DB_NAME', 'name db');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', ' ');

/** Salty - secret keys */
define('AUTH_KEY',         '{ip-*olYz8wJtF+E<q;nR5vo@:d?:jlIWo%T;<&l7Kl]V`gVF%/ken)mP6+JKQ2(');
define('SECURE_AUTH_KEY',  'I}DH71YM36Ia=S4G9fM6#}qo;UDk8p^<([c`XnS/+dDTFTtA>jn2-MmfAzy|7FE<'); 
define('LOGGED_IN_KEY', '7:Q;2(-Ij:~>4&2vyco_O|Wru _G}/#b3sPme&T&M#]{DNiCK8(qu=j]J3-F|qF&');
define('NONCE_KEY',        '@K+;={P~,9{^T;l$ 0-{Jzsa6|2xDs oz$+tvS6HJ!.izuKT#0C_@szm&1(dS?pt');
define('AUTH_SALT',        'Y|T^BDrqfVfhlDyma|P3=Nt&A-|1n^XBZXbfqPOZaYrit>9Jim5VL`:]Y;(=WF.;');
define('SECURE_AUTH_SALT', '|a?2>KLE_t}>xNZu|l%L{zBH8ZQyqJx1w-@<,AJ+gA1JU4R}@ok,&-/0()_$*~~}'); 
define('LOGGED_IN_SALT', 'nq!i(eoJJQL>e>DvVZ>iUhVYhgv=-h~A<o]p{OozL?GMoU-y1|-AC`K!HTKAM-)8');
define('NONCE_SALT',       'oF76 (U|E]_ANU:zeM2+M23AWK_m}MJRn?(q1ynUe2DqC-@$Z0<NZX)@gTkq^*]:');

/** Prefiks bazy danych. */ 
$table_prefix= 'wp_'; 

/** Wyłączone debugowanie. */ 
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 wiem 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.

 

/** Konfiguracja połączenia z Bazą danych */
define('DB_NAME', 'name db');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', ' ');

Patrzą 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');

/**Jeśli używamy host Unix sockets lub pipes, możemy przypisać w następujący sposób 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.


/** Prefiks bazy danych. */
$table_prefix= 'wp_';

Dodatkowo warto wiedzieć. 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 to zrobić w czasie procesu instalacji podając inną wartość lub poźniej. 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 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ą trzyma 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_TABLECUSTOM_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 w 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.

 

/** Salty - secret keys */
define('AUTH_KEY',         '{ip-*olYz8wJtF+E<q;nR5vo@:d?:jlIWo%T;<&l7Kl]V`gVF%/ken)mP6+JKQ2(');
define('SECURE_AUTH_KEY',  'I}DH71YM36Ia=S4G9fM6#}qo;UDk8p^<([c`XnS/+dDTFTtA>jn2-MmfAzy|7FE<'); 
define('LOGGED_IN_KEY', '7:Q;2(-Ij:~>4&2vyco_O|Wru _G}/#b3sPme&T&M#]{DNiCK8(qu=j]J3-F|qF&');
define('NONCE_KEY',        '@K+;={P~,9{^T;l$ 0-{Jzsa6|2xDs oz$+tvS6HJ!.izuKT#0C_@szm&1(dS?pt');
define('AUTH_SALT',        'Y|T^BDrqfVfhlDyma|P3=Nt&A-|1n^XBZXbfqPOZaYrit>9Jim5VL`:]Y;(=WF.;');
define('SECURE_AUTH_SALT', '|a?2>KLE_t}>xNZu|l%L{zBH8ZQyqJx1w-@<,AJ+gA1JU4R}@ok,&-/0()_$*~~}'); 
define('LOGGED_IN_SALT', 'nq!i(eoJJQL>e>DvVZ>iUhVYhgv=-h~A<o]p{OozL?GMoU-y1|-AC`K!HTKAM-)8');
define('NONCE_SALT',       'oF76 (U|E]_ANU:zeM2+M23AWK_m}MJRn?(q1ynUe2DqC-@$Z0<NZX)@gTkq^*]:');

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 daj 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->queriesUWAGA: 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 nie powoł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 aktualizacja 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 zminne: WP_SITEURLWP_HOME. Pierwsza pozwala zdefiniować adres gdzie znajdują się pliki główne, w tym przypadku jest to katalog „wordpress”, druga poozwala 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 );
// Seconds


Ustawienia 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 na 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

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

Cache 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 &amp; ~ 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/