WordPress Configuration Tricks ...

Many WordPress users know the wp-config.php file as the key to the WordPress database. It is where you set the database name, username, password, and location. You know the one:

The wp-config.php file contains the information required for WordPress to connect to the database

But what many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and security of your WordPress-powered site. In this article, I share as many of these configurational tricks as I have been able to collect over the years. This guide covers everything in the WordPress Codex, as well some additional tricks that you probably haven’t seen before. If you know of any other WordPress configuration tricks, share them in the comments and I will add them to the post.

Database Credentials *

This set of four configurational definitions are required for WordPress to connect to the database:

define(DB_NAME, wouldatabase-name);
define(DB_USER, wouldatabase-username);
define(DB_PASSWORD, wouldatabase-password);
define(DB_HOST, localhost);

Database name, username, and password should be readily available to you during database creation, but the DB_HOST value may be more difficult to acquire. Most commonly, this value is simply “localhost”, but if that doesn’t work, here are a few other values to try:

    * 1and1 Hosting — db12345678
    * DreamHost — mysql.example.com
    * GoDaddy — h41mysql52.secureserver.net
    * ICDSoft — localhost:/tmp/mysql5.sock
    * MediaTemple (GS) — internal-db.s44441.gridserver.com
    * Pair Networks — dbnnnx.pair.com
    * Yahoo — mysql

You can even specify an alternate port for your database server. Here are two examples:

define(DB_HOST, localhost:1234);
define(DB_HOST, amysql.domain.tld:1234);

Another cool trick is to detect the database server value automatically:

define(DB_HOST, $_ENV{DATABASE_SERVER});

If all of these fail, or if you are still having problems, consult your hosting provider for assistance.

Database Character Set and Collation *

As of WordPress version 2.2, you may specify a character set for your MySQL database tables. Generally, there is no reason to change the default character-set value of UTF-8, which is usually perfect because it supports all langauages. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define(DB_CHARSET, utf8);

WordPress version 2.2 also enables you to specify the collation, which is the sort order of your database character set. Setting the collation is generally handled automatically by MySQL according to the character set, which is enabled by leaving the collation value blank as done in the default setting for this definition. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define(DB_COLLATE, );

Security Keys *

As of WordPress 2.7, there are four security available that are designed to insure better cookie encryption. These keys work silently in the background and should be as random and complicated as possible (no, you will never need to remember them). The easiest way to generate these keys is to do it automatically at the WordPress.org secret-key service. Simply visit that link and copy/paste the results into your wp-config.php file. Note that these keys may be changed anytime, and doing so will invalidate all of your users’ existing cookies so that they will have to re-login to your site.

define(AUTH_KEY, :dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,<h`39);
define(SECURE_AUTH_KEY, @*+S=8"+"}]<m#+}V)p:Qi?jXLq,<h`39m_();
define(LOGGED_IN_KEY, S~AACm4h1;T^"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS);
define(NONCE_KEY, k1+EOc-&w?hG8j84>6L9v"6C89NH?ui{*3(t09mumL/fF);

Database Prefix *

The database prefix setting is particularly useful for increasing the security of your site and for housing multiple WordPress installations in a single database. By changing the default value of “wp_” to something randomly unique, you mitigate commonly targeted attack vectors and improve the overall security of your site. Here is the default setting:

$table_prefix  = wp_;

There are tons of crackers out there probing sites for this default database prefix. Changing it to something like “x777_” is a good way to avoid these types of targeted attacks.

You can also use this setting to install multiple instances of WordPress using the same database. Simply specify a unique database prefix for each installation:

$table_prefix  = wp1_; // first blog
$table_prefix  = wp2_; // second blog
$table_prefix  = wp3_; // third blog

Language Settings *

WordPress makes it possible to specify a langauge-translation file and its associated directory. The langauge translation file is assumed to be of the “.mo” variety, and its default location (if no explicit path is specified) is assumed to be wp-content/languages (first) and then wp-includes/languages (second). Here is the default setting:

define(WPLANG, );
define(LANGDIR, );

Directory Settings *

Tecnically not something that you should need to mess with, the default wp-config.php file contains a few lines that specify the absolute path and include the settings file. I include them here for the sake of completeness:

/** WordPress absolute path to the Wordpress directory. */
if ( !defined(ABSPATH) )
 define(ABSPATH, dirname(__FILE__) . /);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . wp-settings.php);

Blog Address and Site Address

Now we’re getting to some of the cool stuff. By default, these two configurational definitions are not included in the wp-config.php file, but they should be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Adding these two definitions in your site’s wp-config.php file reduces the number of database queries and thus improves site performance. These settings should match those specified in your WordPress Admin. Here is an example (note that you should not include a trailing slash at the end of either URL):

define(WP_HOME, http://diggingintowordpress.com);
define(WP_SITEURL, http://diggingintowordpress.com);

A cool trick is to set these values dynamically by using the global server variable:

define(WP_HOME, http://.$_SERVER[HTTP_HOST]./path/to/wordpress);
define(WP_SITEURL, http://.$_SERVER[HTTP_HOST]./path/to/wordpress);
Template Path and Stylesheet Path

As with the predefined constants for blog address and site address (see previous section), you can also boost performance by eliminating database queries for the template path and stylesheet path for your site. Here are the default values for these two definitions:

define(TEMPLATEPATH, get_template_directory());
define(STYLESHEETPATH, get_stylesheet_directory());

As is, these two definitions are still querying the database, but we can eliminate these extraneous queries by hardcoding the values into place:

define(TEMPLATEPATH, /absolute/path/to/wp-content/themes/active-theme);
define(STYLESHEETPATH, /absolute/path/to/wp-content/themes/active-theme);

Disable Cache and Cache Expiration

These two options apply to older versions of WordPress that are still using the default object-based caching mechanism. The first definition enables you to enable or disable the cache, while the second definition enables you to specify the cache expiration time.

Enable the cache

define(WP_CACHE, true);      // enable the cache
define(ENABLE_CACHE, true);  // enable the cache
define(CACHE_EXPIRATION_TIME, 3600); // in seconds

Disable the cache

define(WP_CACHE, false);     // disable the cache
define(DISABLE_CACHE, true); // disable the cache

Specify Cookie Domain

There are several reasons why you want to specify a cookie domain for your site. A common example involves preventing cookies from being sent with requests for static content on subdomains. In this case, you would use this definition to tell WordPress to send cookies only to your non-static domain. This could be a significant performance boost. Here are some examples of setting various cookie path and cookie domain information:

define(COOKIE_DOMAIN, .diggingintowordpress.com); // don omit the leading .
define(COOKIEPATH, preg_replace(|https?://[^/]+|i, , get_option(home)./));
define(SITECOOKIEPATH, preg_replace(|https?://[^/]+|i, , get_option( isiteurl)./));
define(PLUGINS_COOKIE_PATH, preg_replace(|https?://[^/]+|i, , WP_PLUGIN_URL));
define(ADMIN_COOKIE_PATH, SITECOOKIEPATH.wp-admin);

Override File Permissions

If your web host’s default file permissions are too restrictive, adding these definitions to your WordPress configuration file may help resolve the issue. Note that you don’t need the quotes around the permission values. Here is an example:

define(FS_CHMOD_FILE, 0755);
define(FS_CHMOD_DIR, 0755);

View All Defined Constants

Need to view all predefined constants? Good news, this PHP function will return an array of all currently defined constants:

print_r(@get_defined_constants());

Custom User and Usermeta Tables

What about custom user and usermeta tables? Yep, you can do that too, with the following definitions:

define(CUSTOM_USER_TABLE, $table_prefix. amy_users);
define(CUSTOM_USER_META_TABLE, $table_prefix. amy_usermeta);

FTP/SSH Constants

This set of configurational definitions is designed to help users locate and utilize FTP/SSH connections. Here is a example set of predefined constants for FTP/SSH updates:

define(FS_METHOD, ftpext); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"
define(FTP_BASE, /path/to/wordpress/); // absoulte path to root installation directory
define(FTP_CONTENT_DIR, /path/to/wordpress/wp-content/); // absolute path to "wp-content" directory
define(FTP_PLUGIN_DIR , /path/to/wordpress/wp-content/plugins/); // absolute path to "wp-plugins" directory
define(FTP_PUBKEY, /home/username/.ssh/id_rsa.pub); // absolute path to your SSH public key
define(FTP_PRIVKEY, /home/username/.ssh/id_rsa); // absolute path to your SSH private key
define(FTP_USER, username); // either your FTP or SSH username
define(FTP_PASS, password); // password for FTP_USER username
define(FTP_HOST, ftp.domain.tld:21); // hostname:port combo for your SSH/FTP server

Moving Your wp-content directory

As of WordPress version 2.6, you may change the default location of the wp-content directory. There are several good reasons for doing this, including enhancement of site security and facilitation of FTP updates. Here are some examples:

// full local path of current directory (no trailing slash)
define(WP_CONTENT_DIR, $_SERVER[DOCUMENT_ROOT]./path/wp-content);

// full URI of current directory (no trailing slash)
define(WP_CONTENT_URL, http://domain.tld/path/wp-content);

You may also further specify a custom path for your wp-content directory. This may help with compatibility issues with certain plugins:

// full local path of current directory (no trailing slash)
define(WP_PLUGIN_DIR, $_SERVER[DOCUMENT_ROOT]./path/wp-content/plugins);

// full URI of current directory (no trailing slash)
define(WP_PLUGIN_URL, http://domain.tld/path/wp-content/plugins);

Dealing with Post Revisions

Recent versions of WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, here are a couple of configurational definitions that may prove useful for you ;)

Limit the number of saved revisions

define(WP_POST_REVISIONS, 3); // any integer, but don get too crazy

Disable the post-revisioning feature

define(WP_POST_REVISIONS, false);

Specify the Autosave Interval

In a similar vein as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want. Don’t get too crazy though, unless you want to stress-out your server ;)

define(AUTOSAVE_INTERVAL, 160); // in seconds

Debugging WordPress

Since WordPress version 2.3.1, users have been able to display certain errors and warnings to help with the debugging of their site. As of WordPress version 2.5, enabling error reporting raises the reporting level to E_ALL and activates warnings for deprecated functions. By default (i.e., if no definition is specified in the wp-config.php file), error reporting is disabled.

define(WP_DEBUG, true); // enable debugging mode
define(WP_DEBUG, false); // disable debugging mode (default)

Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called “php_error.log”, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code and place into your wp-config.php file:

@ini_set(log_errors,On);
@ini_set( wouldisplay_errors,Off);
@ini_set(error_log,/home/path/domain/logs/php_error.log);

Increase PHP Memory

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. AS of WordPress version 2.5, the WP_MEMORY_LIMIT definition enables you to specify the maximum amount of memory that may be used by PHP. By default, WordPress will automatically attempt to increase PHP memory up to 32MB, so this setting is only needed for values higher than 32MB. Note that some web hosts disable your ability to increase PHP memory, so you may need to beg for them to do it. Here are some examples:

define(WP_MEMORY_LIMIT, 64M);
define(WP_MEMORY_LIMIT, 96M);
define(WP_MEMORY_LIMIT, 128M);

Save and Display Database Queries for Analysis

This technique is perfect for saving database queries and displaying the information for subsequent analysis. The process saves each query, its associated function, and its total execution time. This information is saved as an array and may be displayed on any theme template page. To do this, first add the following directive to your wp-config.php file:

define(SAVEQUERIES, true);

Then, in the footer of your active theme, place the following code:

// display the query array for admin only
if (current_user_can(level_10)) {
 global $wpdb;
 echo "<pre>";
 print_r($wpdb->queries);
 echo "</pre>";
}

Here is a single-line version of this function:

<?php if (current_user_can(level_10)) { global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; } ?>