Using wp-config to Customize WordPress

As you may already know, you can entirely customize the layout of a WordPress website thanks to the different existing themes, and you can even create your own if you want to have a fully personalized website. That’s a good thing, but did you know that the configuration of WordPress itself can also be modified? That’s the aim of the wp-config file. In this article, we will take a look at the wp-config file in order to know what it is, what it contains, and what we can (and must not!) do with it.

What Is the wp-config File?

When I mention wp-config file, I am referring to the file wp-config.php that is located in the root of your WordPress installation. It contains much of the information that WordPress needs to function. If you don’t correctly fill this file, your WordPress installation won’t work. That means you won’t be able to start your website and you could even break your installation by making a mistake in an edit of this file. To avoid these mistakes, it is important to know exactly what the wp-config file contains. This way, you will be able to modify what you want without taking any risk (but be sure to test your changes locally before sending them on to your server). Moreover, understanding the wp-config file will allow you to add some parameters, to modify the default behavior of WordPress. Note, you don’t have to manually edit the wp-config file, even if WordPress is not yet configured. In fact, the WordPress installation assistant asks you the needed information if it’s not present. This means you’ll only have to edit the wp-config file if you want to customize some settings. In the next section of this article, we will cover the different settings you’ll have to include in your wp-config file if you want to edit it by yourself. If you just downloaded the WordPress archive, then you don’t have a wp-config file yet. In its place, you have a file called wp-config-sample.php. If you don’t want to use the installation assistant, edit the wp-config-sample.php file and rename it to wp-config.php.

What Can We Find in This File?

In this section, we will cover the list of what we can find in the wp-config file in its current state, in WordPress 4.1. At the same time, we will see how to edit these lines if needed.

Database Settings

The database settings are the only mandatory settings. You must indicate the right values. If not, WordPress cannot create the tables it needs to work. These settings, as many of the others in the wp-config file, consist in a list of constants. To define a constant in PHP, you have to use the define() function. In the first parameter, give the name of the constant and, in the second one, its value, which can be a string, a number, or whatever you want. As you may realise, we will need to indicate the database credentials in order to let WordPress use it. If you don’t know all of the information required, you can search for the details in the admin panel of your web hosting. The first constant defining a database setting is DB_NAME. As its name suggests, it must contain the name of the database you want to use to store what is needed by WordPress. The value here should be a string representing the corresponding name.

define('DB_NAME', 'wordpressdatabase');

Following the database name, we find the DB_USER constant, which must contain the name of the user having the right to use the database. This user should have a password indicated in the DB_PASSWORD constant.

define('DB_USER', 'databaseuser');
define('DB_PASSWORD', 'dBpAsSwOrD');

Finally, the latest mandatory database setting is the DB_HOST constant, which must contain the server on which we can find your database. Often, the 'localhost' value is enough, but maybe your web hosting gives you an IP address or even a subdomain.

define('DB_HOST', 'localhost');

The next two constants are also database-related, but concern the character set used by the WordPress tables. By default, WordPress will use the UTF-8, but if you want to change this, indicate your preference into the DB_CHARSET constant. You can even set your own collation with the DB_COLLATE constant. A few lines after these constants definitions, we find the declaration of a variable called $table_prefix. WordPress uses this variable to name the table it creates. By default, its value is wp_, so all the tables created by WordPress will begin with wp_, like wp_posts or wp_options.

Authentication Keys

To automatically log in your users, WordPress uses cookies. Information stored in these cookies are encrypted, and you can get a better encryption thanks to a set of eight constants. The AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY constants are required if you want a better encryption and security. You can enhance this encryption with salts, thanks to the AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT constants. The value accepted by these constants are strings. These strings should be unique in order to have a better security. Moreover, try to use different and special characters, otherwise your phrases can be guessed. To help you, WordPress provides you with a tool: the online generator. This tool will generate unique phrases, displayed in a code that defines the right constants: all you have to do is copy and paste the result in the place of your current definitions. You can change your keys and salts at any time. When you do this, the information stored in your users’ cookies are invalidated: your users will have to log in manually next time.

Debugging Mode

Right after the declaration of the $tables_prefix variable we find the WP_DEBUG constant, defined to false by default. If you change it to true, WordPress will display some information which can be useful if you develop for this platform. You should avoid this option if this WordPress installation is not only for developing. However, if you activate the debugging mode, then you will be able to add new useful options we will cover in the next section.

Don’t Touch the Following!

The WP_DEBUG constant is the last default you can modify. However, after this constant, we find another one called ABSPATH. Do not modify this constant. WordPress uses it to retrieve the absolute path of your WordPress installation. Finally, the wp-config file is ending with the inclusion of another file: wp-settings.php, which is located at the root of your installation. This file sets up some constants, variables or functions used by WordPress. Once again, do not touch this file, or the path used in the require_once() function called in the wp-config file.

What Can We Add in This File?

Above we explored how to edit the wp-config file, but we can also add some things in this file, often some constants. To add things in the wp-config file, you have to respect one rule: the additions must be done before the definition of the ABSPATH constant, right after the definition of the WP_DEBUG constant by default. We will now review some useful additions we can include in the wp-config file, but this list is by no means exhaustive.

Automatic Updates

If you read our article about updating WordPress, you have already seen an example of additions in the wp-config file. In fact, if you want to disable automatic updates, you can add the following constant.

define('AUTOMATIC_UPDATER_DISABLED', true);

But you can also activate the automatic updates for the major ones with the following constant.

define('WP_AUTO_UPDATE_CORE', true);

Moving Folders

By default, WordPress stores your plugins and themes into the wp-content subdirectory of the root of your installation. If you want, you can change this behavior by defining by yourself the WP_CONTENT_DIR constant in the wp-config file. To find the folder wp-content, you can use the PHP function dirname() to retrieve the path to the directory containing your wp-config file, that is the root of your WordPress installation.

define('WP_CONTENT_DIR', dirname(__FILE__) . '/path/to/my/content-dir');

Do not add a trailing slash in this path. If you want to change this directory, you should also change its URL by defining the value of the WP_CONTENT_URL constant, once again without trailing slash.

define('WP_CONTENT_URL', 'http://mysite.com/path/to/my/content-dir');

Following the same format, you can also define your own paths for the plugins directory. You can, for example, use the content directory you just defined.

define('WP_PLUGIN_DIR', WP_CONTENT_DIR . '/myplugins');
define('WP_PLUGIN_URL', WP_CONTENT_URL . '/myplugins');

You can change the uploads directory, too, thanks to the UPLOADS constant.

define('UPLOADS', 'my/subdirectory/for/uploads');

Without a trailing slash, this path must not be absolute: it is relative to the ABSPATH constant defined by WordPress. Note that it is not possible to move the themes directory which always must be the themes subdirectory of the content directory defined with the WP_CONTENT_DIR constant.

Debugging

Error Reporting

We already saw that we can activate the debugging mode thanks to the WP_DEBUG constant set to true. If you activate this option, WordPress will display all errors by raising the error reporting level to E_ALL and you will know when you use deprecated functions thanks to warnings. You can control the way errors are reported to you by playing with the WP_DEBUG_LOG and WP_DEBUG_DISPLAY constants. Set to true, the former will send errors in a log file while the latter will directly display the errors.

// I don't want to miss any errors!
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

WordPress Scripts and Styles

Another useful constant is the SCRIPT_DEBUG one. Once again, it’s a boolean set to false by default. By setting it to true, WordPress will change the way it includes its JavaScript and CSS files. By default it includes their minified versions but, when this option is activated, it includes their full versions, which is useful when you want to edit them.

define('SCRIPT_DEBUG', true);

Queries

If you need to analyze the queries WordPress does during the display of a page, you can set the SAVEQUERIES constant to true.

define('SAVEQUERIES', true);

That way, you will be able to retrieve all the queries in the queries attribute of the $wpdb object. For example, in the footer, you can display the queries if the current user is an administrator.

if (current_user_can('administrator')) {
global $wpdb;
echo '<pre>' . print_r($wpdb->queries, true) . '</pre>';
}

Posts-Relative Constants

Revisions

As you may know, each time you edit a post or a page, WordPress saves your edit into a ‘revision’. That way, you will be able to retrieve a previous version of your post and cancel some edits if needed. If you are sure you don’t want revisions, you can deactivate this behavior by setting the WP_POST_REVISIONS constant to false. By default, its value is true and WordPress will create a new revision each time you edit a post, but you can also limit the number of revisions by giving an integer as a value to the same constant.

// I don't want to create revisions
define('WP_POST_REVISIONS', false);

// I love revisions!
define('WP_POST_REVISIONS', true);

// Too many revisions?
define('WP_POST_REVISIONS', 3);

Automatic Saves

When you are editing a post (or when you are creating a new one), WordPress doesn’t wait for you to finish your edits to save a draft or a revision: using AJAX, it will save your changes regularly, respecting a delay given by the AUTOSAVE_INTERVAL constant. By default, this delay is 60 seconds but you can change it by giving the number of seconds you want.

// Save my changes two times per minute
define('AUTOSAVE_INTERVAL', 30);

Trash Bin

Sometimes, we delete posts. To do that, WordPress provides us a trash bin and it empties this trash bin every 30 days. You can change this delay by setting the number of days you want to the EMPTY_TRASH_DAYS constant. If you set this value to 0, WordPress will disable the trash bin: by deleting a post, it will be removed permanently, without any confirmation.

// Delete permanently items from the trash bin every two months
define('EMPTY_TRASH_DAYS', 60);

// Disabling the trash bin
define('EMPTY_TRASH_DAYS', 0);

Note that all trash bins are involved so not only will posts will be deleted permanently, but also pages, comments and attachments.

In Conclusion

The wp-config file is an important one in any WordPress installation. It defines the database settings needed to store data, but also some useful options when you develop a plugin or a theme for WordPress. Now you know what can be found in this file, so you can edit it without any concerns. Don’t forget to always test your edits on a local version of WordPress, in order to prevent any potential issues on a live site. As covered above, the list of edits and additions we’ve touched upon in this article is by no means exhaustive. I tried to present you the constants I think are the most useful, but the WordPress Codex gives you even more possibilities for the wp-config file if you want to explore it deeper.

Frequently Asked Questions (FAQs) about Customizing WordPress Using WP-Config