WordPress - Настройка на wp-config.php

Най-важният от файловете за управление на WordPress, е wp-config.php и сега ще ви покажем какво може да се постигне с него. По-интересното е, че файлът не присъства в самия WordPress, а се генерира на място по време на инсталацията. Така всеки един wp-config.php файл във всички инсталации на WordPress е уникален, в зависимост от параметрите, които сте указали по време на инсталацията. Ако обаче искате да инсталирате WordPress на ръка, то Automattic предоставят файл wp-config-sample.php. Така можете да преименувате този файл като wp-config.php и да го настроите за вашите конкретни нужди.

Преди да започнем ще ви покажем съдържанието на реален wp-config.php от реална инсталация на WordPress.

<?php
/**
* The base configuration for WordPress
*
* The wp-config.php creation script uses this file during the
* installation. You don't have to use the web site, you can
* copy this file to "wp-config.php" and fill in the values.
*
* This file contains the following configurations:
*
* * MySQL settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @link https://codex.wordpress.org/Editing_wp-config.php
*
* @package WordPress
*/

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'jumptest_wp375');

/** MySQL database username */
define('DB_USER', 'jumptest_wp375');

/** MySQL database password */
define('DB_PASSWORD', '4Sa[r4]2mR');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'ibdyhfty8qkkxd4j2enzztn3d4yfcadycdfdzcgffa3yz0jcqpzu9n1dyxhwfpwj');
define('SECURE_AUTH_KEY', '6pz76bfoypqzvfzprccenmqhnemchjpt2bbt1fezovrusmcsxix32oba0bpbaam3');
define('LOGGED_IN_KEY', 'dngrkcrzaj4f6whlsxiqmvisyec3zx3windlanxkyyxddtq8lumz1e1ywhkqjy5u');
define('NONCE_KEY', 'oqsy68uljezcpgmxyk6ps0uhv8gk1d4f8zsktjox5cniwry1ystdernvdcn2ujzd');
define('AUTH_SALT', 'hxxvvghietbb2gtvmpdhlmbztmyg26ebcpqf9quqqe3se1ehvg7h86wvaebd4czz');
define('SECURE_AUTH_SALT', 'kosgh4nvhl35tkjgcu5gwsxudifv1qlkwpjfxfwysmpenw7wdoizdezslnv1gfri');
define('LOGGED_IN_SALT', 'rxrlzj0vmv0ogglbi1yo1izj1ebe8yno3nd5hdcghvorn1tkztnj74ea3zzcho8o');
define('NONCE_SALT', 'jurulpjgptkt17izpkqz8axmlsqtdvw1sv3mzygzjldhf7glxsobf1lxvfpepmby');

/**#@-*/

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wpkp_';

/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the Codex.
*
* @link https://codex.wordpress.org/Debugging_in_WordPress
*/
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

ВАЖНО! Файлът е много специфичен и е от критично значение и самата подредба в него. Ако се налага да добавите нещо към него е най-добре да се прибави преди този ред:

/* That's all, stop editing! Happy blogging. */

или да се коригира на място, ако съществува съответния ред.

Файлът е съставен от редове като този:

define ('параметър', 'стойност');
или
$параметър = стойност;

където ''параметър'' е името на параметъра, който искаме да използваме, а ''стойност'' е стойността, която искаме да му присвоим. Стойността може да бъде набор от символи (стринг), число, буквено-цифрова комбинация или двоична стойност (истина/лъжа). Изключително важно е на всеки един параметър да се прибавя стойността, от която се нуждае. Някои от тях искат само двоични стойности, други стрингове, трети числа.

ВАЖНО! Както много пъти сме напомняли - преди да правите промени направете архив на файловете, които искате да модифицирате. В дадения случай просто архивирайте файла с FTP клиент като го смъкнете локално или му направете копие. В никакъв случай не го преименувайте, защото това ще предизвика грешка в WordPress и ще направи системата неработоспособна.

1.Първото и най-важно нещо във файла е секцията за връзка към базата от данни. Това се управлява със следните задължителни параметри:

• DB_NAME - това е името на базата от данни, която WordPress ще използва за съхранение на своите данни;
• DB_USER - това е потребителят, който WordPress ще използва за връзка към базата от данни;
• DB_PASSWORD - паролата на потребителя;
• DB_HOST - това е местоположението на сървъра, където е разположена базата от данни.

При Jump Хостинг параметърът DB_HOST е винаги localhost, защото там се намира MySQL сървъра.Параметрите на DB_NAME, DB_USER, DB_PASSWORD се управляват от cPanel и можете да ги настоите ето от тук. Ако ги промените от cPanel ще трябва да редактирате и този файл с новите стойности. И обратното - ако ги промените тук ще трябва да редактирате и cPanel с обновените стойности.

Съществуват и алтернативни начини за връзка с MySQL. Един от тях е когато сървъра се намира на нестандартен порт. Стандартно сървъра работи на порт 3306, но ако администраторите използват друг, ще трябва да направите промяна ето така:

define('DB_HOST', 'localhost:3330');

define('DB_HOST', '127.0.0.1:3330');

define('DB_HOST', 'my.db.server.com:3330');

В примерите сме използвали порт 3330.

Другият случай е когато сървъра не работи през TCP/IP контакт (TCP/IP socket), а използва Unix контакти (unix sockets) или тръби (named pipes):

define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );

define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );

define( 'DB_HOST', 'my.db.server.com:/var/run/mysqld/mysqld.sock' );

Тук приемаме, че сървъра работи през /var/run/mysqld/mysqld.sock

ВАЖНО! Нашите клиенти със споделен хостинг не използват нестандартни портове или тръби. Просто localhost като стойност на DB_HOST върши работа.

И незадължителните параметри:

• DB_CHARSET - това указва какъв е наборът от символи, използван за съхранението на буквено-цифровите символи в базата от данни;
• DB_COLLATE - това указва каква е подредбата на символите в базата от данни за специфичния език.

ВАЖНО! DB_CHARSET и DB_COLLATE може и да не съществуват във вашия файл. Използването на погрешни стойности може да повреди базата от данни. WordPress използва като charset utf8 и collate utf8_general_ci. И точно поради това е съвместим с всички налични езици (unicode) още от версия 2.2. Възможно е стойностите да са малко по-различни при вас, но ако ще правите промени по тези два параметъра е по-добре да се консултирате с поддръжката на хостинга.

2. Второто, и не по-малко важно в този файл, е секцията за уникалните ключове. Тези ключове се използват за кодиране на паролите и бисквитките (cookies). За тях отговарят параметрите:

• AUTH_KEY
• SECURE_AUTH_KEY
• LOGGED_IN_KEY
• NONCE_KEY
• AUTH_SALT
• SECURE_AUTH_SALT
• LOGGED_IN_SALT
• NONCE_SALT

По време на инсталация се вземат уникални стойности оттук и се използват за тази инсталация на WordPress. Всяко едно извикване на горния адрес връща различни стойности, което гарантира, че всяка инсталация ще е абсолютно уникална и че стойностите, с които ще се кодират паролите, ще са уникални. Така дори и на два различни WordPress сайта да използваме еднакви пароли, техните стойности в базата от данни ще са различни.

ВАЖНО! Понякога след хакване на WordPress е хубаво (т.е. задължително!) да се генерират нови пароли на потребителите. Още по-добре е да се генерират и нови ключове за защитата на тези пароли. За целта можете да използвате горния линк и да вземете нови комбинации, след което можете да генерирате и нови пароли за потребителите.

3. И последната задължителна секция от този файл е за префикс име на таблиците, които WordPress ще използва за съхранение в базата от данни:

$table_prefix  = 'wpkp_';

Това указва, че всички таблици ще бъдат със wpkp_ преди тях. Например wpkp_users или wpkp_settings.

Тук има няколко сценария:

• Една база данни (DB_NAME), много WordPress инсталации - тогава се налага всички инсталации да използват абсолютно уникални префикси, за да се избегне презаписването на данни между тях.
• Много бази данни (DB_NAME), много WordPress инсталации - тогава изборът на префикси не е фатален и може да се използват едни и същи.

Но при втората ситуация би възникнал проблем ако се наложи да се премине към първия сценарий. Затова е добра практика и префиксите да са уникални.

Четвъртата секция на файла след реда:

/* That's all, stop editing! Happy blogging. */

е за зареждане на самия WordPress и редакции след него са неприемливи. Затова, ако някъде прочетете как да сложите нещо в този файл, добро място е да го сложите преди горния ред.

Други параметри, които могат да се добавят са WP_SITEURL и WP_HOME - това са два параметъра, указващи на кой сайт се намира WordPress и в коя директория. Първият параметър SITEURL указва на кой сайт се намира самото ядро на WordPress (core). Вторият параметър HOME указва на кой сайт крайните потребителите виждат WordPress. В голяма част от случаите, двата параметъра са еднакви. В много редки случаи може да се различават.  Използват се ето така:

define( 'WP_SITEURL', 'http://example.com/wordpress' );
define( 'WP_HOME', 'http://example.com/wordpress' );

В случаите, когато сайта се намира на горния адрес.

Адресите се записват в директориите без наклонена черта. Само домейна се изписва с наклонена черта. Така 'https://адрес.бг/директория/' е неправилно и трябва да се премахне последната наклонена черта, докато 'http://адрес.бг/' е правилно.

ВАЖНО! Използването на тези променливи има приоритет пред аналогичните им стойности, които се използват от базата от данни. Предимно се използват по време на миграция на сайтове между различни адреси или към сигурни връзки, както ви описахме тук.

WP_CONTENT_DIR и WP_CONTENT_URL - това са два параметъра, които указват къде се намира директорията wp-content. Първият указва директорията на сървъра, а втория - интернет адреса. Ето и пример:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content-nov' );

define( 'WP_CONTENT_URL', 'http://primer/blog/wp-content-nov' );

WP_PLUGIN_DIR и WP_PLUGIN_URL - указват къде се намират плъгините, също като горните параметри. Ето и примери:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins-nov' );

define( 'WP_PLUGIN_URL', 'http://primer/blog/wp-content/plugins-nov' );

Ако някой плъгин не работи ефективно, може да се използва и този параметър:

define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins-nov' );

Можете да укажете theme_root и UPLOADS, което ще промени мястото на съхранение на темите и на файловата библиотека. Те се указват ето така:

$theme_root = WP_CONTENT_DIR . '/temi;

define( 'UPLOADS', 'wp-content/fajlove' );

ВАЖНО! theme_root може да бъде само поддиректория на wp_content. Така че може само името да се смени, но не и положението във файловата система.

AUTOSAVE_INTERVAL - това указва през какъв параметър WordPress да записва автоматично съдържанието на текстовия редактор. Ако изрично не е указано това се прави на 60 секунди (минута). Но вие можете да редактирате това в секунди ето така:

define( 'AUTOSAVE_INTERVAL', 180 );

При което записа ще се извършва на 180 секунди или 3 минути.

WP_POST_REVISIONS - това позволява да се настрои по-фино системата за версии на постовете или статиите. По дефиниция WordPress записва всяка една промяна в нова версия и пази абсолютно всичко. И това предизвиква хаос в базата от данни ако се правят много промени. Можете да използвате това:

define( 'WP_POST_REVISIONS', false );

За забрана на тази система от версии или това:

define( 'WP_POST_REVISIONS', 5 );

За да ограничите версиите на не-повече от 5 броя.

EMPTY_TRASH_DAYS - този параметър указва след колко дни да се изтриват автоматично постовете, статиите, коментарите, файловете и други обекти които се намират в коша. По подразбиране стойността е 30 дена. Но може да се редактира ето така:

define( 'EMPTY_TRASH_DAYS', 7 );

При което триенето ще последва след седмица. Или така:

define( 'EMPTY_TRASH_DAYS', 0 );

При което функцията на кошчето ще бъде забранена и обектите ще се трият без изчакване.

WP_DEBUG - този параметър позволява да се визуализират грешките или предупрежденията, които WordPress скрива. Стандартно е “false” и всичко е скрито. Може да се използва така:

define( 'WP_DEBUG', true );

или така

define( 'WP_DEBUG', false );

Ако се интересувате до какво води това прочетете предната ни публикация тук.

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