The items that come with the default wp-config-sample.php file are in blue.
All extra items that you can add are in black, as normal (only add these if you're going to use them).
Database Settings
- DB_NAME : Database Name used by WordPress
- DB_USER : Username used to access Database
- DB_PASSWORD : Password used by Username to access Database
- DB_HOST : The hostname of your Database Server. This is normally localhost, but if you're not sure you can either ask your hosting company, or use a neat little trick of replacing the line withdefine('DB_HOST', $_ENV{DATABASE_SERVER});
- $table_prefix : These are the letters that are attached to the beginning of all your WordPress table names, within your WordPress database. If you didn't change this as part of your WordPress install, then the likelihood is that you're using the default of wp_ . From a security perspective, this is very insecure (as hackers will know to target database table names starting with wp_) and should be changed as soon as possible. If you're an advanced user, and you know what you're doing, you can change it manually by replacing wp_ with something random like pahfh_ and then updating your database tables (and some elements within those tables) with the same change. If you're not an advanced user, get yourself a good security plugin such as Better WP Security, which can easily do it for you.
Security Settings
- AUTH_KEY: Added to ensure better encryption of information stored in the user's cookies. Do notleave these set to the default values. See the instructions below.
- SECURE_AUTH_KEY: Added to ensure better encryption of information stored in the user's cookies. Do not leave these set to the default values. See the instructions below.
- LOGGED_IN_KEY: Added to ensure better encryption of information stored in the user's cookies. Donot leave these set to the default values. See the instructions below.
- NONCE_KEY: Added to ensure better encryption of information stored in the user's cookies. Do notleave these set to the default values. See the instructions below.
- AUTH_SALT: Used to make the AUTH_KEY more secure.
- SECURE_AUTH_SALT: Used to make the SECURE_AUTH_KEY more secure.
- LOGGED_IN_SALT: Used to make the LOGGED_IN_KEY more secure.
- NONCE_SALT: Used to make the NONCE_KEY more secure.
From a security perspective, one of the absolute basics is to replace the put your unique phrase here items with some unique phrases, and pronto.
The easy way to do this, is go to https://api.wordpress.org/secret-key/1.1/salt/ and copy the randomly generated lines into your wp-config.php file.
The easy way to do this, is go to https://api.wordpress.org/secret-key/1.1/salt/ and copy the randomly generated lines into your wp-config.php file.
You don't need to remember these, just set them up once, and then you can forget about them.
You can change them at any point (especially if you get hacked), and if you do it will invalidate all existing user cookies, which will just mean that all users have to log in again.
You can change them at any point (especially if you get hacked), and if you do it will invalidate all existing user cookies, which will just mean that all users have to log in again.
Some of you may remember that WordPress used to have an area where you could define where your media uploads went to. It may have disappeared from the WordPress administrator, but you can still make the change using the wp-config.php file.
If you don’t want to use the ‘wp-content’ directory then you can use this code instead:
If you don’t want to use the ‘wp-content’ directory then you can use this code instead:
- DISALLOW_FILE_EDIT: In the WordPress Administrator area (Appearance -> Editor), it is possible to edit a range of your WordPress files (mainly Theme related). Most users will never use this area (it's for advanced users only), and leaving it open for hackers is a security risk. You can lock down this area with the value set to true and open it again by changing the value to false.
If you have SSL enabled on your website, then it's an awful shame to waste it. Enable SSL on your Administrator area with these two settings
- FORCE_SSL_LOGIN: Forces WordPress to use a secure connection when logging in. Set to true to enable.
- FORCE_SSL_ADMIN: Forces WordPress to use a secure connection when browsing any page in your Administrator area. Set to true to enable.
File Permissions of wp-config.php
Really, this is part of the security of your website, however this is such an important aspect, that it earned its own little section.
Nobody (apart from you) would ever need to access this file, so it's best to lock it away as much as you can. The final padlock on the security of your wp-config.php file is to change the access permissions. You can do this through FTP by right-clicking on the file, selecting File Permissions and then changing the permissions by unchecking the relevant boxes (ideally the Numeric value at the bottom should be 400, but this may need to be 440 depending on your hosting provider).
(Side note - don't forget to protect your wp-config.php file using your .htaccess file.)
Nobody (apart from you) would ever need to access this file, so it's best to lock it away as much as you can. The final padlock on the security of your wp-config.php file is to change the access permissions. You can do this through FTP by right-clicking on the file, selecting File Permissions and then changing the permissions by unchecking the relevant boxes (ideally the Numeric value at the bottom should be 400, but this may need to be 440 depending on your hosting provider).
(Side note - don't forget to protect your wp-config.php file using your .htaccess file.)
Language Settings
These two items were added in WordPress v2.2.
WARNING: If you have just upgraded from a version earlier than 2.2, please refer to the upgrades section below, as these two items should not be added to your wp-config.php without some additional work first.
WARNING: If you have just upgraded from a version earlier than 2.2, please refer to the upgrades section below, as these two items should not be added to your wp-config.php without some additional work first.
- DB_CHARSET: Used for the database character set. The default is utf8 which supports any language, so this should not be altered unless absolutely necessary. DB_COLLATE should be used for your language value instead.
- DB_COLLATE: Used to define the sort order of the database character set. Normally this is left blank, which allows MySQL to automatically assign the value for you, based on the value of DB_CHARSET. If you do decide to change this value, make sure it is set to a UTF-8 character set, such as utf8_general_ci or utf8_spanish_ci.
English is the default language of WordPress, but it can easily be changed using these two settings:
- WPLANG : Name of the language translation (.mo) file that you want to use. If you're working in English, you can leave this blank. If you're working in a language other than English, you can look up your language code here: http://codex.wordpress.org/WordPress_in_Your_Language. For Spanish, this would become define('WPLANG', 'es_ES');
- WP_LANG_DIR : WordPress will look for your language translation files (.mo) in two places: firstly wp-content/languages and (if no luck) then wp-includes/languages. If you want to store your language translation files somewhere else, you can define that location here.
Performance Settings
- WP_HOME : This overrides the wp_options table value for home, reducing calls to the WordPress database and therefore increasing performance. Set the value to your full website domain, including thehttp:// and leaving out any trailing slash " / ".
- WP_SITEURL : This overrides the wp_options table value for siteurl (reducing calls to the WordPress database and therefore increasing performance) and disables the WordPress address (URL) field inSettings -> General. Set the value to your full website domain, including the http:// and leaving out any trailing slash " / ".
- WP_POST_REVISIONS : By default, WordPress autosaves all the previous versions of your posts, just in case you decide that you'd like to go back to a version you wrote last week, or last year. Most people don't use this feature, in fact most people don't know this feature exists. As you can imagine, having this on by default creates a lot of extra load on the database. Give your poor database a rest, and either set this definition to false, or if you really like the revisions feature just replace false with the number of revisions you'd like to keep (between 2 and 5 is normally a good number).
- WP_MEMORY_LIMIT : Used to increase the maximum memory that can be used by PHP A popular fix for "fatal memory exhaustion" errors. 64M is a good starting point, but you can increase this if needed.
Debug Settings
- WP_DEBUG : Controls the display of certain errors and warnings (for developer use). Default is false, but any developers wishing to debug code should set this to true.
- CONCATENATE_SCRIPTS : For a faster Administrator area, WordPress concatenates all Javascript files into one URL. The default for this parameter is true, but if Javascript is failing to work in your administration area, you can disable this feature by setting it to false.
Multisite Settings
- WP_ALLOW_MULTISITE : To enable WordPress Multisite (previously done through WordPress MU), you have to add this definition to your wp-config.php file. The setting must be true to be enabled.
Follow the directions on this new page to continue the setup.
Site Settings
This is basically detailing the absolute path to the WordPress directory, and then setting up the WordPress variables and files that need to be included.
There should be no need to change this code, but it comes as part of the standard wp-config-sample.php file, so I'm just popping it in in case someone says "Hey, where's that bit of code at the end?"
There should be no need to change this code, but it comes as part of the standard wp-config-sample.php file, so I'm just popping it in in case someone says "Hey, where's that bit of code at the end?"
Upgrades
wp-config.php is one of the few files that is left untouched during normal WordPress upgrades (if you use Fantastico, see note below), so you don't need to worry about it being overwritten.
Why No Closing PHP Tag?
The observant amongst you will have noticed that whilst there's an opening php tag, there's no closing php tag.
This is not a mistake, and your wp-config.php file can be happily left without a closing tag.
Why?
Well, believe it or not a very simple issue of "spaces after closing PHP tags" are known to cause a range of various issues including "headers already sent" errors, and breaking other bits and bobs within perfectly well behaved websites.
Several years ago, WordPress decided to make life a little bit easier for everyone by removing the ending PHP tag from the wp-config.php file.
More recently, they did the same with several other core files.
This is not a mistake, and your wp-config.php file can be happily left without a closing tag.
Why?
Well, believe it or not a very simple issue of "spaces after closing PHP tags" are known to cause a range of various issues including "headers already sent" errors, and breaking other bits and bobs within perfectly well behaved websites.
Several years ago, WordPress decided to make life a little bit easier for everyone by removing the ending PHP tag from the wp-config.php file.
More recently, they did the same with several other core files.
Final Tip
Hopefully this has provided an insight on the numerous things you can do with the wp-config.php file.
The most commonly used definitions are here, however if you're looking for something very bespoke, you can find a full list of definitions in the WordPress Codex here: http://codex.wordpress.org/Editing_wp-config.php.
Happy coding!
The most commonly used definitions are here, however if you're looking for something very bespoke, you can find a full list of definitions in the WordPress Codex here: http://codex.wordpress.org/Editing_wp-config.php.
Happy coding!
0 comments:
Post a Comment