search ]

Optimize WordPress Configuration with wp-config.php

WordPress users are familiar with the wp-config.php file as the one used to set up database information – the database name, username, password, and its location (as well as table prefixes, security keys, and language).

However, many users are unaware that wp-config.php can be used to set a wide range of configurations to enhance the functionality, performance, and security of your WordPress site.

In this guide, I’ll share several configuration tricks that I’ve encountered over the years. The guide will cover options detailed in the WordPress Developer Resources, as well as options you may not be familiar with.

Here is an image of a typical wp-config.php file, known as the WordPress Configuration File:


WordPress wp-config.php

Let’s take a look on some of the settings you can apply via the wp-config.php file:

1. Database Settings

These four settings are necessary for WordPress to connect to the database:


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

The database name, username, and password are the settings you defined during the creation of the database. The DB_HOST setting is a bit trickier – in most cases, its value should be localhost, but some hosting companies may require a different value.

You can also set a different port for the database server; here are two examples:


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

Another useful trick is to automatically identify the database server:

define('DB_HOST', $_ENV{DATABASE_SERVER});

If you still struggle to find the correct value, talk to your hosting company and ask for the information.

2. Database – Collation & Character Set

From WordPress version 2.2 onwards, you can set the Character Set for MySQL tables. In general, there’s no need to touch this setting since the default is UTF-8, which supports all languages:

define('DB_CHARSET', 'utf8');

Starting from WordPress 2.2, you can also set the Collation, which determines the sort order of the character set in the database. This setting is usually done automatically by MySQL based on the character set and can be left blank:

define('DB_COLLATE', '');

Note: Use/change these settings only if they already exist in the wp-config.php file.

3. Security Keys

WordPress uses eight security keys and salts designed to enhance the encryption of cookies. These keys work quietly behind the scenes and should be as random and complex as possible. The easiest way to generate these keys automatically is by using the WordPress.org secret-key service.

Simply visit the link and copy the result into your wp-config.php file during your WordPress installation.

You can change these keys anytime. Changing them will invalidate all existing cookies, forcing all logged-in users to log in again.


define('AUTH_KEY',         '_;*Yfw@]Qr#[|YDl-v$pXkPZ^;Ac&YC:|s]-pw`qJYDM<[Z7!%V66bWLu_Qr]MKF');
define('SECURE_AUTH_KEY',  'FF@{y)vPLNmMiIWW~7+fN7Zf7e9Jw37HyGRf9=$`0kg%cKrG33kkJ5 jpE6Ox)8*');
define('LOGGED_IN_KEY',    'q!0/8%dcC6Ey<t)[*r+/W/3R2L&V:=BM<zuAC!#bt&![hIu0@TgF+nqGp)aBLl-2');
define('NONCE_KEY',        'kIHaSGF92lbRElp/UZ4<)@?xoIDaxlve|]oY+53UG.v=g/[.3wz,/|yP-yhc2-aD');
  

4. Database Table Prefix

Table prefixes are especially useful to strengthen your WordPress site’s security or to host multiple WordPress installations on one database.

By changing the default value of wp_ to something more unique, you can thwart hacking attempts on your site’s database and enhance site security. Here is the default definition:

table_prefix  = 'wp_';

Changing the prefix to something like sVVV_ adds a minor layer of obscurity. While it won’t stop a determined attacker, it can help prevent automated SQL injection scripts that target the default wp_ prefix.

You can also use this setting to perform multiple WordPress installations on one database. Simply define the unique table prefix in each installation:

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

5. Language Settings

WordPress allows you to set the translation file for the language used on your site. The translation file is a .mo file, and its default location is wp-content/languages (with wp-includes/languages as a fallback):

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

6. Library Settings

This is not a setting you need to touch. This code comes with the wp-config.php file and contains a few lines that define the absolute path and the wp-settings.php settings file.

/** 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');

7. Blog URL and Site URL

The following two settings are not in wp-config.php by default, but adding them can slightly improve the performance of your WordPress site. They override the values stored in the database (without actually changing them).

Adding these settings reduces the number of database calls. Make sure they match the values in the WordPress control panel (note: no trailing slash):

define('WP_HOME', 'https://savvy.co.il');
define('WP_SITEURL', 'https://savvy.co.il');

The following trick uses the $_SERVER['HTTP_HOST'] variable. While convenient for development, avoid using it in production as it can be spoofed by attackers.

You can also set these values dynamically 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');

8. Template Path and Stylesheet Path

For the same reason, you can avoid unnecessary database calls to get the template path and stylesheet path. Here are the default WordPress settings:

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

As they are, they still make calls to the database, but you can skip these unnecessary calls by writing the paths in the code:

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

9. Domain Settings for Cookies

This setting is intended for those with a non-standard domain setup. For example, if you use a subdomain to serve static content (images, CSS, JavaScript), you can set cookies to be sent only to the main domain.

This prevents the static content subdomain from sending cookies with every request, which can improve performance.

define( 'COOKIE_DOMAIN', 'www.example.com' );

10. File and Directory Permissions Override

If your hosting company’s permission settings are too strict, adding these lines to the WordPress configuration can help. Note that there is no need for quotes around the permission value:

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

11. Custom User and Usermeta Tables

What about changing the tables responsible for users in the database? You can change these by using the following code:

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

12. Changing the Location of the wp-content Directory

Since WordPress 2.6 and above, you can change the default location of the wp-content directory. There are several reasons to do this, such as securing your WordPress site and FTP updates. Here are 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 can also set a different path for your plugins folder. This option can help solve 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');

13. Post Revisions

WordPress has a built-in revision system that lets you revert to older versions of a post. Whether you use this feature or not, there are several configurations you can apply:

Limit the number of saved revisions

define('WP_POST_REVISIONS', 3); // integer

Disable post versions functionality

define('WP_POST_REVISIONS', false);

14. Set the Time Between Automatic Post Saving

By default, WordPress auto-saves a version of a post every 60 seconds. You can change this interval:

define('AUTOSAVE_INTERVAL', 160); // in seconds

15. Allow Upload of All File Types for Admins

WordPress limits the file types that can be uploaded to the media library. You can allow all file types for administrators:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

It’s important to note that this setting allows only administrators to upload all file types. If you want to allow specific file types for non-admin users, check out this guide on allowing additional file types in WordPress.

16. Add a Trash Bin to the Media Library

By default, deleting an image in the media library is permanent. You can enable a trash bin for the media library:

define( 'MEDIA_TRASH', true );

This gives you the ability to recover accidentally deleted media files.

17. Debugging

WordPress includes a built-in debugging mode that displays error messages and deprecation notices. By default, debugging is disabled in production:

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

I recommend checking out this article on a more proper way to debug WordPress using WP_DEBUG_LOG.

18. Increase PHP Memory

If you receive an error message like “Allowed memory size of xxx bytes exhausted”, you can increase the PHP memory limit. By default, WordPress tries to set this to 40MB (64MB for multisite):

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

19. Save and Display Database Queries for Analysis

This technique saves each database query along with the function that executed it and the total execution time. Useful for performance analysis:

define('SAVEQUERIES', true);

Then add the following code to your theme’s footer to display the queries for administrators:

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

20. Disable File Editing in the WordPress Dashboard

WordPress includes a built-in file editor (Dashboard > Appearance > Editor) that lets users edit plugin and theme files. Disabling this is a recommended security hardening step:

define('DISALLOW_FILE_EDIT', true);

21. Concatenate Files in the Admin Interface

To speed up the admin interface, WordPress combines JavaScript files into a single request. If you encounter JavaScript errors in the dashboard, you can disable this concatenation:

define( 'CONCATENATE_SCRIPTS', false );

22. Force SSL for the Admin Dashboard

If your site has an SSL certificate, you can force all admin sessions to use HTTPS:

define( 'FORCE_SSL_ADMIN', true );

This ensures that login credentials and session cookies are always transmitted over an encrypted connection.

23. Prevent Plugin and Theme Installation

While DISALLOW_FILE_EDIT removes the file editor, DISALLOW_FILE_MODS goes further by also preventing plugin and theme installation, updates, and deletion through the dashboard:

define( 'DISALLOW_FILE_MODS', true );

This is useful for production environments where all changes should go through version control or a deployment pipeline.

24. Set the WordPress Environment Type

Since WordPress 5.5, you can define the environment type for your installation. This allows plugins and themes to adjust their behavior accordingly:

define( 'WP_ENVIRONMENT_TYPE', 'production' ); // local, development, staging, or production

For example, when set to production, WordPress disables the fatal error handler’s display. In development mode, WP_DEBUG is enabled by default.

25. Move wp-config.php Above the Web Root

For an extra layer of security, you can move the wp-config.php file one directory above your WordPress installation. WordPress automatically checks the parent directory for this file, so no additional configuration is needed.

This prevents direct HTTP access to the file, even if your server’s PHP processing fails. Combined with proper file permissions (600 or 640), this is a recommended security practice.

FAQs

Where is the wp-config.php file located?
The wp-config.php file is located in the root directory of your WordPress installation. You can access it via FTP, your hosting file manager, or SSH. For added security, you can move it one directory above the web root - WordPress will automatically detect it there.
Is it safe to edit wp-config.php?
Yes, but always create a backup of the file before making changes. A syntax error in wp-config.php can take your entire site down. Use a plain text editor (not a word processor) and test changes on a staging environment first whenever possible.
What is the difference between DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS?
DISALLOW_FILE_EDIT only removes the built-in theme and plugin file editor from the WordPress dashboard. DISALLOW_FILE_MODS is more restrictive - it also prevents installing, updating, and deleting plugins and themes through the dashboard. Use DISALLOW_FILE_MODS in production environments where all changes should go through a deployment process.
Should I set WP_DEBUG to true on a live site?
No. Displaying debug information on a live site can expose sensitive data to visitors and attackers. Instead, use WP_DEBUG_LOG to write errors to a log file, and set WP_DEBUG_DISPLAY to false. This way you can still monitor errors without exposing them publicly.
How many post revisions should I keep?
A good balance is 3 to 10 revisions. This gives you enough history to revert mistakes without bloating the database. For sites with many authors or frequent edits, keeping more revisions may be useful. For simple sites, 3 to 5 is usually sufficient.

Summary

The wp-config.php file is one of the most powerful configuration tools in WordPress. Beyond basic database settings, it lets you control security, performance, debugging, and file management.

Key takeaways: always use strong security keys, limit post revisions to reduce database bloat, disable the file editor in production, and consider moving wp-config.php above the web root for added protection. For more on securing your WordPress site, check out our WordPress security hardening guide.

Join the Discussion
0 Comments  ]

Leave a Comment

To add code, use the buttons below. For instance, click the PHP button to insert PHP code within the shortcode. If you notice any typos, please let us know!

Savvy WordPress Development official logo