In the root of a WordPress site, two files decide almost all of its configuration behaviour: wp-config.php and .htaccess. This post focuses on wp-config.php, where WordPress reads constants before loading any plugin or theme.

The first thing to remember: every constant below has to sit above this line in wp-config.php, or it will have no effect at all.

/* That's all, stop editing! Happy publishing. */
require_once ABSPATH . 'wp-settings.php';

1. Override the site URLs

These two constants override the values stored in the database. Very handy right after a domain change, or when a wrong URL has locked you out of the admin.

define( 'WP_SITEURL', 'https://example.com/' );
define( 'WP_HOME', 'https://example.com/' );

WP_SITEURL is where the WordPress code lives, WP_HOME is the address visitors type into the browser. In most cases the two are the same.

2. Move the plugin directory

define( 'WP_PLUGIN_DIR', '/physical/path/to/plugins' );
define( 'WP_PLUGIN_URL', 'https://example.com/url-path/plugins' );

Rarely needed, but useful when you want to keep code outside the web root.

3. Limit post revisions

By default WordPress stores an unlimited number of revisions per post. On a site that has been running for a few years, the wp_posts table can be several times bigger than it needs to be purely because of revisions.

define( 'WP_POST_REVISIONS', 5 );     // keep the 5 most recent
define( 'WP_POST_REVISIONS', false ); // turn revisions off entirely

I usually set 3 to 5 rather than turning them off, because revisions have saved me a few times when a client deleted content by accident.

4. Stretch the autosave interval

define( 'AUTOSAVE_INTERVAL', 150 ); // in seconds, default is 60

A larger value cuts the number of AJAX requests hitting the server when several people are writing at once.

5. Log SQL queries for debugging

define( 'SAVEQUERIES', true );

Then print the queries for the current page:

global $wpdb;
print_r( $wpdb->queries );

Each entry shows the query, how long it took, and which function called it. This is the fastest way to find the plugin slowing your pages down. Only enable it in development, because it holds every query in memory and slows the site noticeably.

6. Raise the PHP memory limit

When you hit Allowed memory size of xxxxx bytes exhausted:

define( 'WP_MEMORY_LIMIT', '128M' );     // for the front end
define( 'WP_MAX_MEMORY_LIMIT', '256M' ); // for the admin area

Note that this only works if the server’s PHP config permits the increase. If memory_limit in php.ini is lower, you have to fix it at the server level first.

7. Language and language directory

define( 'WPLANG', 'vi' );
define( 'WP_LANG_DIR', '/path/to/languages' );

Since WordPress 4.0 the language should be selected under Settings > General. WPLANG still works but is mostly useful for forcing a language in an automated deployment.

8. Enable advanced caching

define( 'WP_CACHE', true );

This tells WordPress to load wp-content/advanced-cache.php. Most caching plugins add this line themselves on activation, so you rarely write it by hand.

9. Force HTTPS for login and admin

define( 'FORCE_SSL_ADMIN', true );

Forces the whole /wp-admin area and the login page over HTTPS. Only turn this on once you have a working SSL certificate, or you will lock yourself out of the admin.

If the site sits behind a proxy or CDN like Cloudflare, add this beforehand so WordPress detects the right protocol:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

10. Trash retention

define( 'EMPTY_TRASH_DAYS', 7 );  // default is 30
define( 'EMPTY_TRASH_DAYS', 0 );  // disable trash, deletion is permanent

11. Disable the default WP-Cron

define( 'DISABLE_WP_CRON', true );

By default WordPress runs scheduled tasks by piggybacking on visitor requests. A high traffic site calls cron constantly and wastes resources, while a low traffic site barely runs it at all.

The right approach is to disable that mechanism and call it from a real system cron:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

This is one of the changes with the most visible effect on the sites I have optimised.

12. Block file editing in the admin

define( 'DISALLOW_FILE_EDIT', true );

Turns off the theme and plugin editors inside the admin. Turn this on for every production site: if an admin account gets taken over, the attacker cannot inject malicious code with a few clicks.

If you want to go further, this constant also blocks installing and updating plugins from the interface:

define( 'DISALLOW_FILE_MODS', true );

13. Enable debugging properly

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // write to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // do not print errors to the screen

These three together are the safe way to debug: errors get recorded in full, but visitors never see file paths or anything sensitive.

One note on security

wp-config.php contains your database credentials. Set the file permissions to 440 or 400, and block direct access through .htaccess:

<files wp-config.php>
order allow,deny
deny from all
</files>

If the server runs Nginx rather than Apache, .htaccess does nothing and you need the equivalent rule inside the Nginx server block.