Everything about WordPress Configuration (wp-config.php)

Editing configuration files is often considered a daunting task by all of us. We always try our best to avoid modifying the default settings. What if something goes wrong? WordPress installation brings with it about a 1000 files amongst which is the trickiest one – wp-config.php, the WordPress configuration file. Of course, this file can remain untouched if you want to stick to the default settings but it becomes a necessary evil to edit this file to apply security precautions, customize functionality and improve performance. This article will give you a good understanding of this file so that you can mess with it without any qualms.

Where is the wp-config.php?

When you install WordPress, the wp-config.php isn’t included. Yes, you read that right. You can only find a file named wp-config-sample.php located in the root directory that includes all the default settings. Just rename this file to wp-config.php and you are ready to go.

Securing the wp-config.php file

The configuration is most vulnerable to attacks making it imperative for you to secure it in the best possible way. One way of doing this is to move the file one directory higher than the web root folder. This works by taking wp-config.php and moving it outside of the public realm (typically one level above /public_html). This will have no implications as WordPress automatically knows to look up one directory if it can’t find wp-config.php in the default location. However, a few developers are opposed to this idea. For more information, click here.

Another important security measure is the file permission. Ensure that you set this file’s permission to 600 using chmod so that only the true owner can edit the files.

The third step involves modifying the .htaccess file and not the wp-config.php file.  The .htaccess file is a configuration file used for access control by web server. I know what you must be thinking “Oh no, not another configuration file! “. But relax; you only have to include the following lines to your .htaccess file and you are done. By including these lines, you can prevent hackers from loading wp-config.php file directly from the browser.

# protect wpconfig.php

<files wp-config.php>

    order allow,deny

    deny from all


Getting down to the details

Having secured the file, it is time to get down to the nitty gritty of the WordPress configuration. An important note before you proceed – never use a word processor such as Microsoft Word to edit this file. You may just end up formatting it in an unacceptable and unusable way. Always remember to use a simple text editor such as Notepad, vim, gedit, etc. to modify the wp-config.php file.

Database Configuration

WordPress stores all your data – posts, comments and everything else in a storehouse that is more popularly known as a database. This database includes multiple tables for each type of information – users, posts, comments, etc.

In most cases, you only require to know – database name (DB_NAME), username (DB_USER), and password (DB_PASSWORD). The DB_HOST is usually left as localhost. These are the default values present in the wp-config.php file.

  • DB_NAME: Name of your database

  • DB_USER: User who has access to the database

  • DB_PASSWORD: Password corresponding to the user

  • DB_HOST: Hostname of your database server. In most cases, the default value localhost works well for most servers. If install fails, contact your web hosting provider for the correct hostname. Some of the popular webhosts and the corresponding DB_HOST values are as follows:













At times, you are also required to specify an alternate port number for your database server.

e.g.  define(‘DB_HOST’, ‘localhost:1234’);

        define(‘DB_HOST’, ‘mysql.example.com:3307’);

Another way to figure out the server name is by using an environment variable.

e.g.  define(‘DB_HOST’, $_ENV{DATABASE_SERVER});

WordPress, being one of the most popular CMS, is not only used in English but also in various other languages all over the world. A charset is a form of encoding used to store different languages in a consistent manner. The default value, UTF-8, rarely needs to be changed as it supports almost all the languages.

e.g. define(‘DB_CHARSET’, ‘utf8’);

Note: Don’t change this value once your website is up. It may have serious implications on your data.

You also have the option of choosing a collation type corresponding to the character set. See Collation in Databases for more information.

e.g. define(‘DB_COLLATE’, ”); // default value

   define(‘DB_COLLATE’, ‘utf8_general_ci’); // general collation

Note: Leaving the DB_COLLATE value as NULL ensures that the right collation is automatically assigned by your server when the tables are created. Unless you know what you are doing, it is best to leave these values untouched.

Security Keys

What if your site gets hacked? You need to act fast. Your first step would probably be to change all the passwords. But how will that ensure that the bad guy is kicked out of your website? The answer to your problem lies in changing the security keys. Updating the keys will ensure that all users are forced to re-login to your site. It is strongly advised that you update these keys regularly.

The easiest way to generate these keys is by using the WordPress key generator. Simply copy-paste the contents into your wp-config.php file and you are ready to go. Click here for more details on security keys. Alternatively, you can use a security plugin like MalCare that offers has Site Hardening features allowing you to Change Security Keys with a click of a button.

Table Prefix

Hackers usually probe sites for the tables starting with the default prefix “wp_”. You have the option of defining your own prefix for the database tables. By changing to prefix to something more unique, you can improve the overall security of your site. You can also use this setting when you want to install multiple instances of WordPress on a single database. Suppose you want to have a blog for the support team and another for the marketing team, you can define two table prefixes.

$table_prefix  = ‘wp_’; // default value

$table_prefix  = ‘sup_’; // first blog

$table_prefix  = ‘mar_’; // second blog

WordPress Address

The WordPress site address (WP_SITEURL) is the location where the core WordPress files reside. This is useful in cases where WordPress is installed in a subfolder under your root folder. For example, if your domain is example.com and your WordPress is installed in a folder called /public_html/wordpress, your SITEURL should be defined as:

define(‘WP_SITEURL’, ‘http://example.com/wordpress’);

See our article on using WP_SITEURL and WP_HOMEURL for more details.

Blog Address

As the name indicates, this is the address that you want your visitors to type to get to your blog. Hence it is also known as the HOME URL.

define(‘WP_HOME’, ‘http://example.com’);

See our article on using WP_SITEURL and WP_HOMEURL for more details.

Auto Save Interval

While editing posts, WordPress automatically saves these posts as revisions. You have the option to increase the interval between these auto-saves. The default value is 60 seconds.

define (‘AUTOSAVE_INTERVAL’, 160); //seconds

Post Revisions

WordPress maintains multiple revisions of your post. You can limit the number of revisions by changing the value in the following line:

define (‘WP_POST_REVISIONS’, 3); //up to 3 versions

You can also disable the option by setting the value to false.

define (‘WP_POST_REVISIONS’, 0); //up to 3 versions

For more details, see our article on WordPress Revisions.

WordPress Multisite

Multisite is a feature that allows multiple sites to share a single WordPress installation. When this feature is activated, the original WordPress site can be converted to support a network of sites. You can achieve this by adding the following line in wp-config.php file. When not present, the value defaults to false.

define(‘WP_ALLOW_MULTISITE’, true);

Redirect Nonexistent Blogs

In a WPMU, this feature is used to redirect users to a valid URL when a nonexistent page or domain is requested. For example, if the user is trying to access http://badsubdomain.example.com, you can redirect the user to the home URL instead of displaying a 404 page not found error by adding the following line in your wp-config.php file:

define(‘NOBLOGREDIRECT’, ‘http://example.com’);

Memory Limit

Everything in the virtual world needs memory space to reside in. WordPress content such as themes, plugins, and even software upgrades require memory. In the middle of all the updates and installations, PHP may run out of memory throw an error saying memory is exhausted.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 41544617bytes) in [filepath]

You can increase the memory size by defining a constant in your wp-config.php file.

define(‘WP_MEMORY_LIMIT’, ‘128M’)

When in the administration area, the memory can be increased or decreased from the WP_MEMORY_LIMIT by defining WP_MAX_MEMORY_LIMIT. By default, it is 256M.

define(‘WP_MEMORY_MAX_LIMIT’, ‘512M’)

Disable Updates and Installations

You’ve set up a WordPress site for a client and you don’t want them upgrading themes and plugins without determining their compatibility. Poorly executed upgrades can cause a host of issues, including site crashes, that will have your client knocking on your door once again.

Adding the following line of config helps you to restrict access to the plugins and themes, along with the updating capability from within WordPress. It also removes the ability for users to install new plugins and themes.

define(‘DISALLOW_FILE_MODS’, true);

An easy way of doing this would be by using a security plugin like MalCare. It’s site hardening features allows you to disable updates and installation of plugins and themes. All you need to do is push a few buttons.


By default, WordPress doesn’t display error messages on the screen and you end up the White Screen of Death. However, there are ways to make WordPress display error and debug messages to make debugging easier. You can add the following constants to your wp-config.php file to reap their benefits:

WP_DEBUG: Enables all PHP errors and notices related to deprecated functions, function arguments, or files. It is set to false by default.

WP_DEBUG_LOG: Works in conjunction with WP_DEBUG. When enabled, all errors are saved in a log file, /wp-content/debug.log. It is set to false by default.

WP_DEBUG_DISPLAY: Works in conjunction with WP_DEBUG. It controls whether debug messages are displayed as they are generated. It defaults to true and setting it to false will hide all errors. It should be used along with WP_DEBUG_LOG so that all the errors can be logged to a file.

SCRIPT_DEBUG: WordPress minifies JavaScript and CSS scripts to reduce their file size. You can force WordPress to use the complete versions of these files by setting the SCRIPT_DEBUG constant to true. It defaults to false.

For more details, see our article on Debugging WordPress.

Saving DB queries

While debugging database errors, it may be useful to have a list of database queries readily available. This can be achieved using the SAVEQUERIES constant. When set to true, each query is saved to an array along with the execution time and the function which called it. This array is stored in the global $wpdb->queries. To view the list of queries, you will have to add a code snippet to print this array. It defaults to false.

define(‘SAVEQUERIES’, true);

Note: This will have a performance impact on your site, so make sure to turn this off when you aren’t debugging.

Custom User and Usermeta Tables

WordPress stores user related information such as name, password, email, etc in the users table and the corresponding metadata in the usermeta table. WordPress allows users to define custom users and usermeta tables. If you’ve got a site that requires multiple WordPress installs, but the same authors often write on all of them, this is the perfect solution. You’ve simply got to add the following lines to your wp-config.php file.

define(‘CUSTOM_USER_TABLE’, ‘my_users’);

define(‘CUSTOM_USER_META_TABLE’, ‘my_usermeta’);

Rarely Used Options

The following options are used in specific cases.

Moving wp-content folder

The wp-content folder stores all your themes, plugins, images, etc. For better security, albeit by obscurity, you can move this folder to an unexpected location so that any hackers looking to target this area won’t be able to find it. Once you move the content of the folder, you will need to configure the same in the wp-config.php file.

For example, if you moved your wp-content folder into another subfolder, content.

define(‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’] . ‘/content’);

Additionally, you need to update the wp-content URL.

define(‘WP_CONTENT_URL’, ‘http://example.com/content’);

Moving plugins folder

In case you don’t want to move your entire wp-content folder but just the plugins, you can do so just as in the case of wp-content. Once you move the content of the plugins folder, you will need to configure the same in the wp-config.php file.

For example, if you moved your plugins folder into another folder, /content/wp-content/plugins.

define(‘WP_PLUGIN_DIR’, $_SERVER[‘DOCUMENT_ROOT’] . ‘/content/wp-content/plugins’);

Additionally, you need to update the wp-content URL.

define(‘WP_PLUGIN_URL’, ‘http://example.com/content/wp-content/plugins’);

There is another variable used by some plugin developers. Hence it is best to update that as well.

define(‘PLUGINDIR’, $_SERVER[‘DOCUMENT_ROOT’] . ‘/content/wp-content/plugins’);

Cookie Domain

A cookie is a piece of text stored on a user’s computer by the web browser. The information stored can be used for user authentication, storing site preferences, and everything else that can be achieved using text. A domain is an attribute of the cookie which defines its scope. A cookie domain tells the browser that the cookie should be sent back to the server only for the given domain.

80-90% of the end-user response time is spent downloading static components such as images, stylesheets, scripts, etc. When the browser requests a static content and sends cookies with the request, the server ignores the cookies. These cookies are unnecessary network traffic. As such, serving the static content from a cookie free domain is a good practice for all websites.

If your domain is example.com, you can host your static components on static.example.com. You then need to add the following lines to your wp-config.php file.

define(‘WP_CONTENT_URL’, ‘http://static.example.com’);

define(‘COOKIE_DOMAIN’, ‘http://example.com’);

Overriding File Permissions

Every file is associated with permissions to decide who can read, write, and execute it. File users are broadly classified into three classes –

  • User – owner of the file

  • Group – set of users in a closed group, owner can also be a part of this group

  • World – rest of the users, except owner and group members

Each class is associated with a set of read, write, and execute permissions. Some webhosts refuse to access files with group or world permissions set. In such cases, there is a need to override the default permissions. You can achieve by using the FS_CHMOD_DIR and FS_CHMOD_FILE constants for directory and file permissions respectively. See Changing File Permissions for more details.

define(‘FS_CHMOD_DIR’, 0755);

define(‘FS_CHMOD_FILE’, 0644);

Language and Language Directory

Although WordPress uses English language by default, it supports many other languages too. You can have your dashboard, themes, and plugins in any language that you choose. To achieve this, you need to upload the .mo language file to a new folder called languages under wp-content. After this, you’ve got to edit your wp-config.php file according to the .mo file you just uploaded. E.g. for the Portuguese spoken in Brazil, you have to add,

define(‘WP_LANG’, ‘pt_BR’);

See WordPress in Your Language