A Guided Tour of WordPress’s wp-config.php File
The single most important file in your entire WordPress Installation is wp-config.php.
Your WordPress website is made up of two elements: a WordPress database, and your WordPress files.
wp-config.php is the one element that links the database and files together.
In this tutorial, we’re going to cover:
- Where you can locate your wp-config.php file.
- What each line affects and common settings.
- How you can use wp-config.php to improve your website security.
This is not a comprehensive coding guide, but a general reference to help you understand this file.
Please take a backup first
It doesn’t matter whether you’ve been using WordPress for 5 minutes or 5 years, always take a backup before you start altering files.
As with all major changes to a website, it is best to implement your changes on a test website first before applying them to a live website.
Caution: as mentioned in the WordPress Codex, the lines of code in your wp-config-sample.php (and therefore your wp-config.php) file are in a specific order. The order is important. Please note that rearranging the lines of code within this file may create errors.
Right, with all the housekeeping bits done, let’s take a look at what this marvelous file can do.
The wp-config-sample.php file
Funnily enough, this incredibly important file doesn’t actually exist in the downloaded copy of WordPress. Instead you are given a wp-config-sample.php as part of the download package, and WordPress kindly gives you the opportunity to “Create a Configuration File” (i.e. your wp-config.php file) as part of the install.
As most normal users choose to click the nice and easy “Create a Configuration File” button to create their wp-config.php file, the majority won’t have seen what the inside of this file looks like.
To do this, you’ll need an FTP login (you can get this from your website creator or your hosting company) and an FTP client, such as FileZilla.
Default Location of the wp-config.php File
By default, this file lives in your /public_html folder, along with all your other WordPress files and folders (as shown in the above FileZilla screenshot).
- For a normal setup the location would be: public_html/wp-config.php
- For a subdirectory the location would be: public_html/subdirectory/wp-config.php
The secure Location of your wp-config.php file
If you’ve done your security homework, then you’ll probably have already moved your wp-config.php file up one level and out of the /public_html folder. This puts your important wp-config.php file out of harms reach, and (more importantly) out of the reach of potential hackers.
Important note for subdomains: If you have a subdomain, moving the wp-config.php file up one level will not take it out of the /public_html folder. You may wish to investigate a more bespoke solution such as moving the majority of your wp-config file settings into a different file altogether, which is then called by an “include” statement in the wp-config.php file.
If you haven’t done so already, it’s time to move this important file out of the public_html folder, and in to a more secure resting place.
To do this is easy. Just open FileZilla (or your FTP program of choice), find your wp-config.php file, click on it and drag it all the way up to the top of your FTP window pane. When you’re hovering over the folder labelled “..” (as shown above), you can let go of your file, and “drop” it into the “..” folder.
You should now see your wp-config.php file disappear from the public_html folder, and appear in the folder one level above (to see this folder, click on the “..” folder).
Note: You might not have the permissions to do this yourself. If your FTP login takes you straight to the public_html folder, then you will have to ask your hosting company to do this for you.
If your FTP login takes to you one level above the public_html folder, but you still can’t “drag and drop” the wp-config.php file successfully, then check out your FTP log for more information (in FileZilla you can enable this by going to the “View” menu and clicking on “Message Log”).
What’s in the wp-config.php File?
Now that the security bit is done, let’s have a look at what’s actually in the wp-config.php file.
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 with define(‘DB_HOST’, $_ENV{DATABASE_SERVER});
If your hosting provider installed WordPress for you, they will be able to provide this information. If you manage your own hosting, you should already have this information as a result of creating the database and user.
- $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 do it for you.
Security Settings
- 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.
- 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. Do not 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 not leave 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.
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.
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:
- 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 for 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.)
Language Settings
- 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 the http:// 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 in Settings -> 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.
It’s important to note that some hosting companies have an overriding limit on the PHP memory available to you. If this addition doesn’t fix the problem, you may have to ask your hosting company very nicely to see if they’ll increase the limit in their php.ini file for you.
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.
Once you add this definition you will see a new “Network” page pop up in your wp-admin, which you can find in Tools > Network.
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?”
What happens if I update WordPress?
wp-config.php is one of the few files that is left untouched during normal WordPress upgrades, so you don’t need to worry about it being overwritten.
Why is there 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.
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!
So what to do about moving the file if you’re hosting multiple domains on one server…all using WordPress…won’t this muck up the works since all their “..” folders are the same?
Thanks for the article. Good stuff. 😀
Hello Rick,
Thanks for your feedback. Hosting multiple domains on the same server shouldn’t be a problem, as each domain should have it’s own control panel (CPanel or Plesk, etc) account and therefore be entirely separate from your other domains. If you’re not sure about your setup, make backups before you try the move, and test thoroughly afterwards.
If you can access all your domain folders using one FTP login, then this is not recommended, and to be honest is rather risky from a security point of view, as one breach of your FTP would grant access to all your domains. If your current system is set up in this way, and changing it isn’t feasible at the moment, then the sub-domain solution may work better for you in the meantime:
“moving the majority of your wp-config file settings into a different file altogether, which is then called by an “include” statement in the wp-config.php file.”
Best of luck,
Sara
This is a basic question- but I’m following the LaughingSquid tutorial for installing WordPress using FileZilla. I copied the WordPress folders into my ftp client and, per the tutorial, I need to duplicate the wp-config.php but, unlike the tutorial, when I right click on mine, there is no duplicate option. I tried to go ahead and edit the file with TextWrangler and that all went great…but when I go to my domain name, it’s still showing the domain host I used and not redirecting to the next step of WordPress install. The duplication of this file is the ONLY step of the tutorial I haven’t followed exactly. Any ideas?
Hello Allyson,
If you’ve followed the tutorial exactly, then it could be a browser cache issue.
Try clearing your browser cache (or use a different browser) and that may resolve your problem.
If you’re still having problems, you may wish to contact Laughing Squid directly, as they should be able to offer advice that is tailored to your setup.
Best of luck,
Sara
now this is useful 🙂
Thanks for your feedback @braankoo !
I am really grateful to have the information from this blog. I liked the blog as it has been written,the information i got from here. I am doing [url=http://traininginstitutegurgaon.com/wordpress-training/]Word press training in Gurgaon[/url] from [url=http://traininginstitutegurgaon.com/]training institute Gurgaon[/url] and i always follow tutorials also to enhance my knowledge. This blog is really helpful for me. Thanks.
Thanks for the info i am curious though, if I move the wp-config.php somewhere else is there some other config file that has to be modified so wp knows where to find it?
Thanks for information.
Thanks for this very informative post.
Hi Steve,
I am working on a photo-site and I am planning to provide the static content via cookieless subdomains. Searching the Internet I stumbled about you SUPER-page. I am a newbie in this thing, I just thought to ask – the best way to ask a Pro! Maybe you can help me.
The plan: to serve the static content (img., css, js) from three different subdomains. I allready set up the subdomains (pointet them to the content folder) and I learned from your site that I have to configure the wp-config.php.
Question: is the following syntax correct:
define(“COOKIE_DOMAIN”, “www.mydomain.com”);
define(“WP_CONTENT_URL”, “https://static.mydomain.com”);
define(“WP_IMG_URL”, “https://static-img.mydomain.com”);
define(“WP_CSS_URL”, “https://static-css.mydomain.com”);
define(“WP_JS_URL”, “https://static-js.mydomain.com”);
Do I have to change anything else?
How can I check if everything is proper set?
Thank you for your help!
Greetings from Germany
Robert