WordPress:Editing wp-config.php

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.

Since WordPress:Version 2.6, wp-config can be moved to the directory directly above the WordPress application directory.

To change the wp-config.php file for your installation, you will need this information:

• Database Name
• Database Username
• Database Password
• Database Host

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).

Creating the file

Open the file wp-config-sample.php in a text editor.

Important: never use a word processor like Microsoft Word for editing WordPress files!

Database name

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

Database user name

define('DB_USER', 'usernamehere'); // Your MySQL username

Delete usernamehere and enter in your own username:

define('DB_USER', 'myDatabaseUser'); // Your MySQL username

Database password

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! :)

Database host

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.

Possible DB_HOST values

Some possible DB_HOST values for hosting companies:

• 1and1 - something similar to db12345678
• AN Hosting - localhost
• BlueHost - localhost
• DreamHost - (the database hostname you created; probably a subdomain like db.example.com)
• GoDaddy - something similar to h41mysql52.secureserver.net
• HostGator - localhost
• HostICan - localhost
• LaughingSquid - localhost
• one.com - localhost
• pair Networks - something similar to dbnnnx.pair.com
• Yahoo - mysql

• Hosts with cPanel - localhost
• Hosts with Plesk - localhost

Mysql Alternate Port

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.

Secret keys (2.6)

WordPress:Version 2.6 has 3 secret keys: AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY.

You don't have to remember them, so make them long and complicated. Make something up or use the secret key generator. Example:

 define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh j>k[.Nf$y7iGKdJ3c*[Kr5Bg');
 define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\\`39m_(');
 define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS<2V^$T])=8Xh2a:b:}U_E');

Secret Key (2.5; IMPORTANT)

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 WordPress: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.

Database character set

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 [[WordPress:#Database collation|DB COLLATE]] value for your language.

• Warning for those performing new installations: For most Western European languages, including English, there usually should be no reason to change the default value of DB_CHARSET. If your blog needs a different character set, please read Character Sets and Collations That MySQL Supports for the valid values for DB_CHARSET.
• Warning for those performing upgrades: If DB_CHARSET and DB_COLLATE do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand WordPress:Converting Database Character Sets. Adding DB_CHARSET and DB_COLLATE to the wp-config.php file, for an existing blog, can cause problems — as Ryan Boren says, "your queries will go boom!"

This example shows utf8 which is considered the WordPress default value:

   define('DB_CHARSET', 'utf8');

Database collation

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.

• Warning for those performing new installations: There usually should be no reason to change the default value of DB_COLLATE. Leaving the value blank (null) will insure the collation is automatically assigned by MySQL when the database tables are created.
• Warning for those performing upgrades: If DB_COLLATE and DB_CHARSET do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand WordPress:Converting Database Character Sets. Adding DB_COLLATE and DB_CHARSET to the wp-config.php file, for an existing blog, can cause problems — as Ryan Boren says, "your queries will go boom!"

This example is of the WordPress default DB_COLLATE value:

   define('DB_COLLATE', ); 

• Example if UTF-8 Unicode Turkish collation is needed (DB_CHARSET should be utf8):

   define('DB_COLLATE', 'utf8_turkish_ci'); 

$table_prefix

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.

Advanced Options

WordPress address (URL)

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 overrides the wp_options table value for siteurl and disables the WordPress address (URL) field in the Administration > Settings > General panel. It won't change the Database value though, and the url will revert to the old database value if this line is removed from wp-config.

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

Blog address (URL)

WP_HOME is another wp-config.php option added in WordPress Version 2.2. Similar to WP_SITEURL, WP_HOME overrides the wp_options table value for home but does not change it permanently. home 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.

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

Moving wp-content

Since WordPress:Version 2.6, you can move the wp-content directory, which holds your themes, plugins, and uploads, outside of the WordPress application directory.

Set WP_CONTENT_DIR to the full local path of this directory (no trailing slash), e.g.

 define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );

Set WP_CONTENT_URL to the full URI of this directory (no trailing slash), e.g.

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

Debug

   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.

Increasing memory allocated to PHP

Also released with WordPress: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');

Cache

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 and Usermeta Tables

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', $table_prefix.'my_users');

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

Language and Language Directory

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

Save queries for analysis

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.

Double Check Before Saving

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!

wp-config.php with Multiple Blogs

Multiple WordPress blogs require special handling of their configuration files. Check WordPress:Installing Multiple Blogs for more information.