Блоґ про WordPress

wp-config.php – все, про що треба знати.

Привіт, впевнений, що багато з Вас знають, що WP-config.php, це основний "файл налаштувань" у WordPress.

Як ми зазвичай використовуємо файл wp-config.php? Коли ми інсталюємо вордпрес, у цей файл записується інформація для встановлення з’єднання з базою даних, та й забуваємо про нього майже назавжди.

На мою думку - Дарма. В цій "чарівній скриньці" є безліч функцій і можливостей для оптимізації сайту, захисту та інші приховані корисні "хаки" - добре продуманий конфігураційний файл допоможе зробити сайт швидшим та безпечнішим, відключити функції, які Вам не потрібні і навпаки.

Так давайте розглянемо, що ж за звір оцей конфігураційний файл , та як Ви можете налаштувати його, щоб Ваш сайт WordPress відповідав усім Вашим потребам.

Що таке wp-config.php файл і з чим його їдять?

Згідно з документацією до WordPress, конфігураційний файл є одним з найважливіших файлів для роботи/встановлення WordPress. Він знаходиться у кореневому каталозі та містить таку важливу інформацію, як дані з’єднання з базою даних (ім’я користувача, пароль і т.д.) і різні додаткові опції.

Але насправді WP-config.php не є частиною файлів, які поставляються з WordPress. Після завантаження WordPress Ви не знайдете цей файл серед інших. Замість нього Ви знайдете файл WP-config-sample.php.

Під час встановлення WordPress Ви можете перейменувати цей файл  на wp-config.php і внести "руками" усі опції, або ж WordPress створить цей конфігураційний файл, базуючись на інформації , яку Ви даєте йому під час інсталяції.

налаштування з'єднання з базою даних WordPress

Базовий вміст конфігураційного файлу.

Розглянути вміст базового конфігураційного файлу Ви можете у цьому прикладі на GitHub. Це той самий wp-config-sample.php. Файл досить добре задокументований, але давайте подивимось докладніше.

Багато параметрів у файлі використовують PHP константи, тобто певним "параметрам" ми встановлюємо певні значення , що мають силу для усього сайту. Значення не може бути зміненим під час роботи сайту, тільки якщо виправите у файлі. Загальний формат встановлення значення для параметрів -  define( 'назва константи', 'значення' ).

Отже пройдемося по значеннях у коді wp-config.php.

Конфігурація бази даних
У перших шести налаштуваннях – все про підключення до бази даних. WordPress зберігає публікації та іншу інформацію в базі даних, тож йому потрібен доступ до цієї бази, щоб нормально функціонувати. З'єднання з базою даних, як правило, вимагає хост, ім'я користувача, пароль та ім'я бази даних.

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', ''); // порядок сортування символів

Перші чотири рядки визначають чотири параметри, які ми згадували трішки вище по тексту.

Набір символів і порядок сортування - слід залишити "як є", якщо не знаєте, що це таке (два параметри, що відповідають за кодування "тексту" під час роботи з базою). UTF8 - хороший вибір, він містить особливі символи і повністю підтримує українську та інші кирилічні мови.

Salts та ключі.

Наведені вісім налаштувань дуже важливі для безпеки Вашого WordPress. Ключі аутентифікації використовуються для перевірки авторизації, а salts використовуються для хешування/шифрування пароля. Ми вже писали про це у серії "Безепечний WordPress".

define('AUTH_KEY', 'w^f{6KRGRuaHF<v]un;?&6]>23[kA-3x|WoQ{W8SNv:!');
define('SECURE_AUTH_KEY', ':)xuZ-p)a:(Ij|-8AtCt1ds4lBm=uD/y}d!FOkZi&7-Y');
define('LOGGED_IN_KEY', '} Oc.qOa5bbSqh(~Tiu,[`Sda!P(5%l9{5ebmT-3=_`:');
define('NONCE_KEY', 'C;xA<Q|h=S`77L+:`mA&Fx(LKG|s6$6zm:gH!+EMI0zl');
define('AUTH_SALT', 'f [Q-$3A4,?F{G>F{ZRDKIc:Mg~Z&fw2/,mA5^YTWOnL');
define('SECURE_AUTH_SALT', 'FT1#6+2=eX <}AnrgpumT6~Hb/vS|}11+ZIx]ha.{R]{');
define('LOGGED_IN_SALT', 'HPW;?Iy%gnhbuzQ:>r&5BD]jsjc}<<0P*N|V$9QVK?fF');
define('NONCE_SALT', 'VAR!;oueIhLK{RvZ@$|f+uHc8iFbo.7O2 r~JV+k-,~]');

Якщо є час та натхнення, можна заповнити ці поля самотужки, та нагальної потреби у цьому немає. Швидше та зручніше використовувати для цього скрипт генерації секретних ключів.

Буде не зайвим регулярно змінювати ці ключі для посилення безпеки сайту.

Інші налаштування.

$table_prefix  = 'h8h3_'; //префікс таблиць
define('WP_DEBUG', false); // режим відладки/дебаг 

У файлі присутні ще дві опції - префікс таблиць баз даних та режим "дебаг/відладка". Префікс каже вордпресу, з яких символів починаються назви його таблиць у базі даних, за замовчуванням це wp_ , для прикладу це означає, що таблиця з публікаціями матиме назву wp_posts.

Один з найкращих способів захисту від атак – бути непередбачуваним та загадковим ))). Насправді, варто замислитись над тим, щоб використовувати параметри "за замовчуванням" якомога рідше, особливо якщо від них залежить безпека баз даних.

Тож слід спробувати використання ось таких неясних префіксів Jbh8h3dD_oj3e_ , у зазначеній вище серії статей про безпеку ми описували, як коректно змінити ці префікси на сайті, що вже працює.

Друга опція вимикає/вмикає режим "debug" , у деактивованому стані зі значенням false повідомлення про помилки не будуть відображатись на сайті. FALSE - це стандартне значення, і встановлено на більшості "працюючих" сайтів , а от при розробці часто необхідно увімкнути відображення помилок, тоді встановлюємо опцію WP_DEBUG у значення TRUE

Кастомізуємо

Конфігураційний файл є звичайним PHP-файлом окрім іншого, тож у нього можна додати будь-який коректний код PHP. Але зауважте, що цей файл є своєрідним сердцем вордпресу, тобто зміни у ньому вплинуть на роботу усього сайту!

У WordPress Codex (офіційній документації) вже описано багато "хаків" для цього файлу, ми спробуємо описати ще кілька.

1. URL
Є дві опції, що можна прописати у файлі, і змінити адресу Вашого сайту - WP_HOME та WP_SITEURL

Обидві опції зазвичай можна змінити через адмінку у меню "Налаштування - загальне":

WP_HOME та WP_SITEURL

Перша опція з адресою сайту - WP_HOME, друга - WP_SITEURL. Якщо ці опції прописати у конфігураційному файлі, змінити через адмінку їх не буде можливості (на зображенні, наприклад, перша опція не доступна для редагування)

WP_HOME - це адреса, що люди вводять, аби потрапити на Ваш сайт, а ось WP_SITEURL - це адреса, де розміщено WordPress (іноді він може бути у піддиректорії).

2. Зміна адрес директорій сайту
У конфігураційному файлі можна вказати нові адреси для "системних" директорій WordPress. Наприклад, можна змінити адресу директорії з плагінами, з файлами, що завантажуються через адмінку, і т.д. Це чудовий додатковий захист для сайту. Кілька прикладів:

// Зміна шляху до директорії wp-content

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/extensions' );

define( 'WP_CONTENT_URL', 'http://mywebsite.com/extensions' );

// Зміна шляху до директорії з плагінами

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/extensions/plugins' );

define( 'WP_PLUGIN_URL', 'http://mywebsite.com/extensions/plugins' );

define( 'PLUGINDIR', dirname(__FILE__) . '/extensions/plugins' );

// Зміна шляху до директорії з шаблонами

register_theme_directory( dirname( __FILE__ ) . '/themes-dev' );

// Зміна шляху до директорії із завантаженнями

define( 'UPLOADS', 'myfiles' );

// Зміна шляху до директорії із must-use плагінами

define( 'WPMU_PLUGIN_DIR', dirname(__FILE__) . '/extensions/builtin' );

define( 'WPMU_PLUGIN_URL', 'http://mywebsite.com/extensions/builtin' );

Зауважте кілька важливих моментів - для зміни адреси директорії wp-content потрібно вказати абсолютний шлях на сервері до неї та повний URL. Для папки з плагінами діє те саме правило, але додатково варто вказати константу PLUGINDIR (для сумісності із застарілим кодом).

З директорією для шаблонів ситуація трохи складніша. В коді WordPress "зафіксована" її адреса, це завжди папка з іменем themes всередині директорії wp-content. Але Ви можете додати додаткову директорію для шаблонів.

Шлях до папки завантажень вказується відносно кореневої папки з WordPress. У прикладі вище директорія myfiles буде розміщена у корені сайту.

Ще є така специфічна папка з "обов'язковими" плагінами, називається mu-plugins, якщо коротко - ці плагіни завжди завантажуються на сайті раніше за інші. В останніх двох рядках прикладу вказано, як змінити їх розташування.

3. Інший шаблон за замовчуванням
Зазвичай стандартним шаблоном є один з twenty-щось. У WordPress 4.0 це буде Twenty Fourteen. Якщо Ви бажаєте це змінити, пропишіть назву папки з потрібним шаблоном в опції WP_DEFAULT_THEME:
define('WP_DEFAULT_THEME', 'twentyeleven');

Ця опція досить корисна, якщо з Вашою основною темою щось трапиться - вордпрес перемкнеться автоматично на шаблон за замовчуванням.

4. Зміна назв таблиць
Є можливість використовувати відмінні від стандартних назви для таблиць користувачів та їх "додаткових полів" - users та usermeta. Це також додатковий рівень захисту, хоча якщо хтось вже отримає доступ до Вашої бази даних - це не врятує. Отже для зміни потрібно прописати:

define( 'CUSTOM_USER_TABLE', $table_prefix.'cossacks' );

define( 'CUSTOM_USER_META_TABLE', $table_prefix.'cossacksmeta' );

Якщо Ви все ж наважитесь на це, то перед зміною варто ознайомитись з цим посиланням.

5. Ревізії, автозбереження та кошик
Є така інформація, що більшість користувачів не використовують функціонал "ревізій", хоча ця фішка з'явилась ще у WordPress 2.6 . На щастя, WordPress дає можливість обмежити кількість створення ревізій чи взагалі від них відмовитись, вказавши значення для WP_POST_REVISIONS:

// Вимкнути ревізії

define( 'WP_POST_REVISIONS', false );

// Зберігати не більше трьох

define( 'WP_POST_REVISIONS', 3 );

Зауважте, потрібно використовувати лише один з варіантів, ми показали два для прикладу.

На відміну від ревізій - функція автозбереження досить зручна, за замовчуванням публікації зберігаються раз у 60 секунд. За потреби можна змінити цю цифру:

define( 'AUTOSAVE_INTERVAL', 120 );

При видаленні записів - вони потрапляють у "кошик", можна налаштувати, аби з кошику видалявся покладений у нього запис після певної кількості днів, для цього вказуємо цю кількість у параметрі EMPTY_TRASH_DAYS. Якщо ж вказати 0 (нуль), то функція кошику буде вимкнена взагалі:

define( 'EMPTY_TRASH_DAYS', 3 );

5. WordPress Multisite
Multisite - це такий режим роботи , коли в рамках однієї інсталяції WordPress працює ціла мережа сайтів. Вони використовують одні теми і плагіни, усі сайти в певному сенсі "віртуальні", тобто не мають своїх окремих директорій на сервері та окремих баз даних.

Аби почати працювати з цією функцією, потрібно додати наступне:

define( 'WP_ALLOW_MULTISITE', true );

Після додавання цієї опції зайдіть в адмінку наново і побачите підменю "Налаштування мережі" у меню "Інструменти".

Ми можемо також додати таку опцію як NOBLOGREDIRECT , вона вказує адресу, куди перенаправити відвідувача, якщо він намагається відкрити один з сайтів мережі, якого не існує.

define( 'NOBLOGREDIRECT', 'http://mainwebsite.com' );

6. Редагування файлів

Мабуть Ви знаєте, що через адмінку можна редагувати певні файли шаблонів та плагінів. Цю можливість можна також  вимкнути, вказавши для параметру DISALLOW_FILE_EDIT значення TRUE. А от якщо таке значення вказати для опції DISALLOW_FILE_MODS , то не тільки редагувати, ще й встановлювати та оновлювати плагіни з темами не можна буде:

define( 'DISALLOW_FILE_EDIT', true );

define( 'DISALLOW_FILE_MODS', true );

Зауважте, що наявність опції DISALLOW_FILE_MODS є достатнім для вимкнення редагування/оновлення/встановлення, при цьому опцію DISALLOW_FILE_EDIT вже не потрібно вказувати.

7. Для ботаніків розробників
Для тих, хто віддає перевагу розробці, а не покемонам :) , є також кілька корисних налаштувань. Зокрема вони допомагають відловити помилки та писати кращий код. Найпопулярніша константа - це WP_DEBUG , якщо встановити для неї значення "True" , на екран будуть виводитись помилки та зауваження.

Якщо потрібно подивитись, чи є якісь проблеми зі скриптами та стилями - пропишіть наступне:

define( 'SCRIPT_DEBUG', true );

define( 'CONCATENATE_SCRIPTS', false );

Зазвичай WordPress об'єднує та зменшує/мініфікує скрипти. Аби не підгружати одразу 100500 скриптів, все це об'єднується в один, та ще і "стискається/мініфікується". Мініфіковані скрипти читати просто немає можливості, щось типу "матриці" ;) , але якщо прописати вище наведений код - ситуація виправиться на краще.

Якщо Ви не дуже хочете, аби помилки виводились на екран і їх бачив хто завгодно, спробуйте записувати їх у файл, це робити можна через константу WP_DEBUG_LOG:

define( 'WP_DEBUG_LOG', true );

Якщо таке прописати, помилки мають записуватися у файл error.log в папці wp-content .

Вважаєте себе перфекціоністом  , тоді константа SAVEQUERIES саме для Вас. Bстановіть значення цієї константи у true і отримаєте детальну інформацію щодо SQL запитів на Вашому сайті :

define( 'SAVEQUERIES', true );

Після встановлення Ви можете вивести десь вміст $wpdb->queries і отримати усі запити. Приблизно так:

global $wpdb;
echo "
<pre>";
print_r( $wpdb->queries );
echo "</pre>
";

8. Чарівний "пендель"
Іноді WordPress потребує трохи більше оперативної пам'яті, Ви можете бачити в таких випадках помилки на зразок Fatal error: Out of memory (allocated 4666) (tried to allocate 37.... У певних технічних середовищах можна спробувати "відкусити" для себе трохи більше, ніж Вам виділено. Для цього потрібно прописати потрібне значення у константи WP_MEMORY_LIMIT та WP_MAX_MEMORY_LIMIT (остання визначає розмір пам'яті, що використовується адмінкою):

define( 'WP_MEMORY_LIMIT', '128M' );

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

9. Cron (планувальник)
Є така штука, Cron, яка дозволяє за розкладом запускати певні процеси. Зокрема саме завдяки їй Ваш сайт час від часу перевіряє наявність оновлень для плагінів, тем, ядра.
Одна з найбільш популярних задач, для якої потрібен Cron - заплановані публікації, тобто коли Ви після написання статті встановлюєте дату публікації "на завтра".

Вбудований у вордпрес Cron іноді просто не працює )) . Коли таке трапилось, перше, що Ви можете спробувати для вирішення питання - таке налаштування:

define( 'ALTERNATE_WP_CRON', true );

Більш правильним, на мою думку, буде вимкнути вбудований планувальник взагалі, а налаштувати його на стороны хостингу (зверніться до свого хостера):

define( 'DISABLE_WP_CRON', true );

10. Оновлення глобальних таблиць
Під час оновлення ядра може викликатись функція dbDelta() , яка перевіряє, чи відповідає Ваша база усім потребам/специфікаціям нової версії вордпресу. Якщо Ваша база має дуже великі розміри, особливо таблиця з користувачами, це може принести певні проблеми. Вимкнути цю функцію можна таким параметром:

define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

11. Вимкнення автоматичного оновлення
На дану тему ми вже писали у статті про Безпеку . Тож я не бачу особливого сенсу зупинятися на цьому докладніше.

На останок додам лише таку цікаву деталь, більшість з Вас про неї і не здогадувались. Для підвищення рівня безпеки сайту та захисту цього чудового файлу wp-config.php Ви можете просто перенести його у директорію на один рівень вище тої, де знаходиться Ваш сайт. При цьому немає потреби щось додатково прописувати, змінювати чи налаштовувати, WordPress самостійно буде шукати цей файл або у директорії з сайтом, або на один рівень вище.

Навряд, хтось з Вас зможе додати щось до цього майже вичерпного списку чудових хаків. Якщо ж я помиляюсь - чекаю на коментарі, які краще починати зі слів "Дмитро, Привіт! )))"

Зверніть увагу: ця публікація побачила світ більше року тому, з того часу багато чого могло змінитися ;)
Дмитро Кондрюк
Дмитро Кондрюк
В веб-індустрії з 2003 року. В 2009р. заснував проект Український WordPress (що у подальшому став офіційним сайтом команди локалізації WordPress в Україні). З 2010 року засновник і технічний директор проекту Український хостинг для WordPress (WPHost.me) - повноцінного хостинг-сервісу, максимально оптимізованого на використання CMS WordPress.

Поки всі мовчать...

Поділіться з друзями.

Ми впевнені, що це може бути корисним для інших і для нашого сайту також )