What We Put in Every wp-config.php on CloudSonic (and Why)

Most people treat wp-config.php like the fine print on a terms and conditions page. It gets auto-generated during installation, you paste in your database credentials, and you never open it again. That’s a shame, because it’s one of the most powerful files in a WordPress installation. A well-configured wp-config.php can improve performance, tighten security, reduce database bloat, and make debugging a lot less painful when things inevitably go sideways.

We’re going to walk through every setting in the default wp-config.php we ship on CloudSonic hosting, explain what each one actually does, and show you how to tune them for your own setup. We’ll also cover a few settings we don’t include by default but are worth knowing about.

What wp-config.php actually does in WordPress

wp-config.php is the first PHP file WordPress loads. It sets up your database connection, security keys, language preferences, and a long list of constants that control how WordPress behaves. Think of it as the control panel that runs before anything else. WordPress reads it top to bottom, and many of the values defined here cannot be changed from inside the admin. If you want to change them, you’re coming back to this file.

Database connection settings in wp-config.php

The first block in any wp-config.php is the database connection. These four values need to be exactly right or WordPress won’t load at all.

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', '127.0.0.1' );

You’ll notice we use 127.0.0.1 instead of localhost for DB_HOST. On most hosting environments these resolve to the same thing, but using the IP address directly forces PHP to use a TCP connection rather than a Unix socket. This avoids a class of subtle connection errors that can appear on some server configurations. If you’re on CloudSonic hosting, leave this as 127.0.0.1.

The character set and collation settings tell MySQL how to store and sort text data.

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

utf8mb4 is the correct charset for any modern WordPress site. It supports the full Unicode range including emoji, which the older utf8 charset cannot store properly. Leave DB_COLLATE as an empty string and WordPress will choose the right collation automatically.

WordPress security keys and salts: what they are and why they matter

Below the database settings you’ll find eight long random strings. These are your authentication keys and salts.

define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

WordPress uses these strings to encrypt and sign the cookies it stores in a logged-in user’s browser. If someone were to steal a session cookie from your site, these keys are what prevent them from forging new ones. They also protect nonces, which are one-time tokens WordPress uses to verify that form submissions and admin actions came from a legitimate source.

You can generate a fresh set at any time using the official WordPress secret key service at api.wordpress.org/secret-key/1.1/salt/. It generates properly randomised strings each time you load the page.

We also set a ninth value on CloudSonic:

define( 'WP_CACHE_KEY_SALT', 'your_unique_cache_salt_here' );

This one isn’t part of the standard WordPress install. It’s used by object caching plugins like Redis Object Cache and W3 Total Cache to namespace cache keys. If you’re running multiple WordPress sites on the same Redis or Memcached instance, each site needs a unique value here to prevent their cached data from overlapping.

How to change the WordPress database table prefix

The table prefix is set with a single line near the top of the config:

$table_prefix = 'cs_';

The default WordPress table prefix is wp_. Changing it to something less predictable is a small but real security improvement. Automated attack scripts that target WordPress often assume the default prefix when attempting SQL injection attacks against known table names like wp_users. Using a custom prefix won’t stop a targeted attack, but it will filter out a lot of automated noise.

WordPress performance settings in wp-config.php

PHP memory limits for WordPress

WordPress lets you define how much PHP memory it can use. There are two separate constants for this:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT is the memory available for regular front-end page loads and general WordPress operations. WP_MAX_MEMORY_LIMIT is the ceiling available for admin tasks like image processing, bulk actions, and plugin updates. These values cannot exceed what your server’s PHP configuration allows at the php.ini level. On CloudSonic hosting plans, the server-level PHP memory limit is set high enough that these constants will take effect as written.

Controlling WordPress post revisions

Every time you save a draft or update a post, WordPress stores a revision in the database. Over time this can add thousands of rows to your wp_posts table, most of which serve no purpose.

define( 'WP_POST_REVISIONS', 5 );

Setting this to 5 keeps the five most recent revisions of each post and discards older ones automatically. You can set it to false to disable revisions entirely, but that’s usually too aggressive. Five gives you a useful undo history without letting the table grow without limit.

Disabling WordPress cron and running it via server cron instead

WordPress has a built-in task scheduler called WP-Cron. By default it runs on every page load, checking whether any scheduled tasks (like publishing scheduled posts or running plugin jobs) are due. On a low-traffic site this is fine. On a busier site, it means every visitor is potentially triggering a cron check, which adds overhead to every single request.

define( 'DISABLE_WP_CRON', true );

Setting this to true turns off the built-in cron trigger. But you do still need cron to run, so you set up a real server-side cron job to call the WordPress cron endpoint at a fixed interval instead. Add this to your crontab:

*/5 * * * * wget -q -O - https://yourdomain.com.au/wp-cron.php?doing_wp_cron > /dev/null 2>&1

This runs the WordPress cron endpoint every five minutes via wget. Replace yourdomain.com.au with your actual domain. The result is more reliable cron execution with less server overhead on page loads.

Autosave interval and trash retention in WordPress

define( 'AUTOSAVE_INTERVAL', 300 );
define( 'EMPTY_TRASH_DAYS', 7 );

AUTOSAVE_INTERVAL controls how often WordPress saves a draft while you’re writing, measured in seconds. The default is 60 seconds. We set ours to 300 (five minutes) because frequent autosaves generate unnecessary database writes during editing sessions. If you’re writing long posts and want more protection against accidental browser closures, drop it back to 60.

EMPTY_TRASH_DAYS sets how many days deleted posts sit in the trash before WordPress permanently removes them. Seven days is a reasonable window. Setting it to 0 disables the trash entirely, meaning deleted posts are gone immediately with no recovery option.

WordPress security hardening in wp-config.php

Forcing SSL on the WordPress admin login page

define( 'FORCE_SSL_ADMIN', true );

This forces all admin area traffic and login requests to use HTTPS. Without this, it’s possible for the WordPress login form to be served over HTTP even if your site has an SSL certificate installed. With it set to true, WordPress will redirect any non-HTTPS request to the admin to the secure version. This should be on for every WordPress site with a valid SSL certificate.

Disabling file editing from the WordPress admin dashboard

By default, WordPress lets admin users edit plugin and theme PHP files directly from the admin dashboard under Appearance > Theme File Editor and Plugins > Plugin File Editor. This is a significant security risk. If an attacker gains access to an admin account, they can inject malicious PHP into your site directly from the browser.

define( 'DISALLOW_FILE_EDIT', true );

This removes the file editor from the admin UI entirely. Your theme and plugin files can still be edited via SFTP or the file manager in cPanel. We’d recommend adding this to every production WordPress installation.

Disabling unfiltered HTML uploads in WordPress

define( 'ALLOW_UNFILTERED_UPLOADS', false );

When set to false, WordPress strips potentially dangerous content from uploaded files. Setting this to true would allow admin and editor users to upload files containing arbitrary HTML and JavaScript, which opens the door to stored cross-site scripting attacks. Leave this as false on any production site.

Turning off the WordPress database repair tool

define( 'WP_ALLOW_REPAIR', false );

WordPress has a built-in database repair and optimisation tool accessible at /wp-admin/maint/repair.php. When WP_ALLOW_REPAIR is set to true, this page works without requiring the user to be logged in, which means anyone who knows the URL can run it against your database. Set it to false normally. If you actually need to repair your database, enable it temporarily, run the repair, then set it back to false.

WordPress debug mode: how to enable it safely

WordPress has three constants that control error reporting. In production, all three should be off:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

When you’re troubleshooting a problem on a staging or development environment, you can enable logging without displaying errors to visitors. This is the pattern we recommend:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

With this configuration, PHP errors and WordPress notices get written to a log file at wp-content/debug.log rather than printed on screen. Visitors see nothing. You can read the log file via SFTP or the file manager. This is much safer than turning on full debug mode on a live site, where error output can reveal file paths, database table names, and plugin details to anyone who loads the page at the wrong moment.

How to set WordPress site URL and home URL in wp-config.php

WordPress normally stores your site URL in the database, but you can override it directly in wp-config.php. This is useful when migrating a site or when the database contains the wrong URL and you can’t get into the admin to fix it.

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

WP_HOME is the URL people type to reach your site. WP_SITEURL is where your WordPress core files live. In most standard installations these are identical. They only differ if you’ve installed WordPress in a subdirectory but want the site to be accessible from the root domain.

Changing the WordPress media uploads directory

By default WordPress stores uploaded media in wp-content/uploads/. You can move this to a different path with the UPLOADS constant:

define( 'UPLOADS', 'paste/media' );

This is a relative path from the WordPress root. We use a custom path on CloudSonic to keep media in a predictable location that’s separate from the core WordPress directories. If you’re changing this on an existing site, be aware that previously uploaded media will still be at the old path and you’ll need to move those files manually.

Saving database queries for debugging in WordPress

define( 'SAVEQUERIES', false );

When set to true, WordPress stores every database query made during a page load in the $wpdb->queries array. This lets you inspect what queries are running and how long each one takes. It’s useful for performance profiling when working with a developer, but it adds overhead to every database call. Keep it false in production and only enable it when you’re actively investigating a performance issue.

Putting it all together: a clean wp-config.php template

Here’s a complete template combining the settings covered in this article, with sensible production defaults. Drop in your own database credentials, generate fresh keys from the WordPress secret key service, and update the URLs.

<?php
define( 'DB_NAME',     'your_database_name' );
define( 'DB_USER',     'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST',     '127.0.0.1' );
define( 'DB_CHARSET',  'utf8mb4' );
define( 'DB_COLLATE',  '' );

// Generate fresh keys at: https://api.wordpress.org/secret-key/1.1/salt/
define( 'AUTH_KEY',         'generate-a-unique-value' );
define( 'SECURE_AUTH_KEY',  'generate-a-unique-value' );
define( 'LOGGED_IN_KEY',    'generate-a-unique-value' );
define( 'NONCE_KEY',        'generate-a-unique-value' );
define( 'AUTH_SALT',        'generate-a-unique-value' );
define( 'SECURE_AUTH_SALT', 'generate-a-unique-value' );
define( 'LOGGED_IN_SALT',   'generate-a-unique-value' );
define( 'NONCE_SALT',       'generate-a-unique-value' );
define( 'WP_CACHE_KEY_SALT','generate-a-unique-value' );

$table_prefix = 'cs_';

// Language
define( 'WPLANG', 'en_AU' );

// Performance
define( 'WP_MEMORY_LIMIT',     '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
define( 'WP_POST_REVISIONS',   5 );
define( 'AUTOSAVE_INTERVAL',   300 );
define( 'EMPTY_TRASH_DAYS',    7 );
define( 'DISABLE_WP_CRON',     true );
define( 'SAVEQUERIES',         false );

// Security
define( 'FORCE_SSL_ADMIN',           true );
define( 'DISALLOW_FILE_EDIT',        true );
define( 'ALLOW_UNFILTERED_UPLOADS',  false );
define( 'WP_ALLOW_REPAIR',           false );

// Debug - all off for production
define( 'WP_DEBUG',         false );
define( 'WP_DEBUG_LOG',     false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// URLs
define( 'WP_HOME',    'https://yourdomain.com.au' );
define( 'WP_SITEURL', 'https://yourdomain.com.au' );

// Custom uploads path (optional)
define( 'UPLOADS', 'wp-content/uploads' );

if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';

There’s a lot of power sitting in that one file. Most of these settings don’t need to be touched often, but understanding what they do means you’re making deliberate choices about how your site runs rather than just accepting defaults. If you’re on CloudSonic hosting and want help reviewing your wp-config.php settings, open a support ticket and we’re happy to take a look.