Codex tools: Log in / create account
As part of the WordPress installation, you must modify the wp-config.php file to define the WordPress configuration settings required to access your MySQL database.
This file, wp-config.php, does not exist in a downloaded copy of WordPress; you need to create it. The wp-config-sample.php file is provided as an example to work from.
To change the wp-config.php file for your installation, you will need this information:
If your hosting provider installed WordPress for you, get the information from them. If you manage your own web server or hosting account, you will have this information as a result of creating the database and user (see Installing WordPress, Create the Database and User).
Contents |
Open the file wp-config-sample.php in a text editor.
Important: never use a word processor like Microsoft Word for editing WordPress files!
Find the line that says:
define('DB_NAME', 'putyourdbnamehere'); // The name of the database
(NOTE: Everything on these lines you see after the // are comments for information purposes only.)
Where it says 'putyourdbnamehere', delete putyourdbnamehere and enter the name of your database. Make sure that you don't accidentally delete the single quotation marks!
The line should look like this:
define('DB_NAME', 'myDatabasename'); // The name of the database
define('DB_USER', 'usernamehere'); // Your MySQL username
Delete usernamehere and enter in your own username:
define('DB_USER', 'myDatabaseUser'); // Your MySQL username
On to the next one:
define('DB_PASSWORD', 'yourpasswordhere'); // ...and password
Delete yourpasswordhere and enter in your MySQL password:
define('DB_PASSWORD', 'MyOwnPassword'); // ...and password
This is only an example password, of course! :)
The next line under the password line defines the host for your database. There is a 99% chance you will NOT have to change it unless your web host tells you otherwise. In other words, you can likely leave it as the default value of 'localhost'.
If your database host is different than 'localhost', move down to the next line:
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
Delete localhost and enter in your database host as directed by your web host:
define('DB_HOST', 'mysql34.myhostserver'); // 99% chance you won't need to change this value
Of course, the mysql34.myhostserver will be different for you.
Some possible DB_HOST vales for hosting companies:
Also if your database host uses an alternate port number you'll need to change to reflect the alternate port:
define('DB_HOST', 'mysql34.myhostserver:3307'); // 99% chance you won't need to change this value
You'll need to change 3307 to reflect what your host provides you as the alternate port number.
It is most important to change the default SECRET_KEY value to something other than 'put your unique phrase here'. Visit the WordPress secret key generation site to get a SECRET_KEY generated for you.
Released with Version 2.5, this new, optional entry, called SECRET_KEY, causes better encryption of information stored in the user's cookies. The secret key is a unique phrase.
// Change SECRET_KEY to a unique phrase. You won't have to remember it later,
// so make it long and complicated. You can visit https://www.grc.com/passwords.htm
// to get a phrase generated for you, or just make something up.
define('SECRET_KEY', 'put your unique phrase here'); // Change this to a unique phrase.
Here's a detailed explanation on the wp-hackers email list from Mark Jaquith in response to the question, "What is the SECRET_KEY for?"
It is a hashing salt that is not readable through the database. "And what is a salt?" A salt is something that adds randomness to a hash input and makes it much harder to crack. For example:
In these examples, consider that the password is "test", but that the cracker does not know this (indeed, this is what he's trying to determine). And yes, I'm glossing over some stuff, but this is the simplistic explanation.
Easy to crack: md5('test');
Since 'test' is a short dictionary word, crackers who have the output hash can easily use rainbow tables (dictionary lookup table) to crack that password in seconds, or minutes.
Harder to crack: md5('test' . $known_salt);
In this case, the cracker has to generate a new rainbow table that adds the $known_salt value to their table's hashes. This slows them down.
Even harder to crack: md5('test' . $unknown_salt);
In this case, they don't know the salt. And since a good salt is something very random, like "888a7da62429ba6ad3cb3c76a09641fc" -- they can't use rainbow tables to help them. They have to just "brute force" their way through all the possible combinations. This is a huge hurdle. Something that might take 10 minutes before could now take years.
As of WordPress Version 2.2, DB_CHARSET was made available to allow designation of the database character set (e.g. tis620 for TIS620 Thai) to be used when defining the MySQL database tables. The default value of utf8 (Unicode UTF-8) should NOT BE CHANGED without careful understanding of the outcome. Please note that UTF-8 supports many European languages so leave DB_CHARSET at utf8 and use the appropriate DB COLLATE value for your language.
This example shows utf8 which is considered the WordPress default value:
define('DB_CHARSET', 'utf8');
As of WordPress Version 2.2, DB_COLLATE was made available to allow designation of the database collation (i.e. the sort order of the character set). In most cases, this value should be left blank (null) so the database collation will be automatically assigned by MySQL based on the database character set (i.e. DB_CHARSET). Set DB_COLLATE to one of the UTF-8 values defined in Unicode character sets (utf8 section) for most Western European languages.
This example is of the WordPress default DB_COLLATE value:
define('DB_COLLATE', );
define('DB_COLLATE', 'utf8_turkish_ci');
The $table_prefix is the value placed in the front of your database tables. Change the value if you want to use something different than wp_ for your database prefix. Typically this is changed if you are installing multiple WordPress blogs in the same database.
Another new wp-config.php option, added as of WordPress Version 2.2, is WP_SITEURL. This allows the WordPress address (URL) to be defined. The valued defined is the address where your WordPress core files reside. It should include the http:// part too. Do not put a slash "/" at the end. Setting this value in wp-config.php causes the wp_options table option_value of siteurl to be set and disables the WordPress address (URL) field in the Administration > Settings > General panel.
If you have installed WordPress into a directory called "wordpress" in a domain name called "example.com", define WP_SITEURL as this example does:
define('WP_SITEURL', 'http://example.com/wordpress');
WP_HOME is another wp-config.php option added in WordPress Version 2.2. This allows the Blog address (URL) to be defined. This is the address you want people to type in their browser to reach your WordPress blog. It should include the http:// part. Also, do not put a slash "/" at the end. Setting this value in wp-config.php causes the wp_options table option_value of home to be set, and disables the Blog address (URL) field in the Administration > Settings > General panel.
define('WP_HOME', 'http://example.com/wordpress');
If you are using the technique described in Giving WordPress Its Own Directory then follow the example below. Remember, you will also be placing an index.php in your web-root directory if you use a setting like this.
define('WP_HOME', 'http://example.com');
define('WP_DEBUG', true);
define('WP_DEBUG', false);
The WP_DEBUG option, added in WordPress Version 2.3.1, controls the display of some errors and warnings. If this setting is absent from wp-config.php, then the value is assumed to be false. Note that the true and false values are not set in apostrophes (').
In Wordpress versions since 2.3.2, database errors are printed only if WP_DEBUG is set to true. In earlier versions, database errors were always printed. (Database errors are handled by the wbdb class and are not affected by PHP's error settings.)
In WordPress version 2.5, setting WP_DEBUG to true also raises the error reporting level to E_ALL and activates warnings when deprecated functions or files are used; otherwise, WordPress sets the error reporting level to E_ALL ^ E_NOTICE ^ E_USER_NOTICE.
Also released with Version 2.5, the WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as "Allowed memory size of xxxxxx bytes exhausted".
This setting increases PHP Memory only for WordPress, not other applications. By default, WordPress will attempt to increase memory allocated to PHP to 32MB (code is at beginning of wp-settings.php), so the setting in wp-config.php should reflect something higher than 32MB.
Please note, this setting may not work if your host does not allow for increasing the PHP memory limit--in that event, contact your host to increase the PHP memory limit. Also, note that many hosts set the PHP limit at 8MB.
Increase PHP Memory to 64MB
define('WP_MEMORY_LIMIT', '64M');
Increase PHP Memory to 96MB
define('WP_MEMORY_LIMIT', '96M');
The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.
define('WP_CACHE', true);
CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designated that the user and usermeta tables normally utilized by WordPress are instead, these values.
define('CUSTOM_USER_TABLE', 'my_user_table');
define('CUSTOM_USER_META_TABLE', 'my_usermeta_table');
WPLANG defines the name of the language translation (.mo) file. LANGDIR defines what directory the WPLANG .mo file resides. If LANGDIR is not defined WordPress looks first to wp-content/languages and then wp-includes/languages for the .mo defined by WPLANG file.
define('WPLANG', 'de_DE');
define('LANGDIR', 'mylanguagedirectory');
The SAVEQUERIES definition saves the database queries to a array and that array can be displayed to help analyze those queries. The information saves each query, what function called it, and how long that query took to execute.
First, put this in wp-config.php:
define('SAVEQUERIES', true);
Then in the footer of your theme put this:
<?
if (current_user_can('switch_themes')){
global $wpdb;
echo "<pre>";
print_r($wpdb->queries);
echo "</pre>";
}
The code above uses the switch_themes capability so only visitors with that capability will see the query results.
Be sure to check for leading and/or trailing spaces around any of the above values you entered, and DON'T delete the single quotes!
Before you save the file, be sure to double-check that you have not accidentally deleted any of the single quotes around the parameter values. Be sure there is nothing after the closing PHP tag in the file. The last thing in the file should be ?> and nothing else. No spaces.
To save the file, choose File > Save As > wp-config.php and save the file in the root of your WordPress install. Upload the file to your web server and you're ready to install WordPress!
Multiple WordPress blogs require special handling of their configuration files. Check Installing Multiple Blogs for more information.