wp-config.php is the primary configuration file for every WordPress installation. Located in the root directory of a WordPress site, it contains the essential settings that allow WordPress to connect to its database and function correctly — including database credentials, security keys and salts, table prefix, debug settings, and a range of constants that control advanced site behavior. Without a valid wp-config.php, a WordPress site cannot load.

Every WordPress setup has one. The file is generated automatically during the initial installation process, but it remains one of the most important files to understand for anyone managing or developing a WordPress site. Knowing what’s in wp-config.php — and how to configure it safely — is the difference between a well-hardened site and one with preventable vulnerabilities. Because this file is loaded on every uncached page view, its contents directly affect both site security and performance.

[Image: Screenshot of wp-config.php file structure in a code editor, with sections labeled: Database Settings, Security Keys, Table Prefix, Debug Mode]

How wp-config.php Works

When a visitor loads a page on your WordPress site, PHP processes wp-config.php first. The file uses define() calls to set PHP constants and a few direct variable assignments for settings like the database table prefix. WordPress then uses these constants throughout its execution to connect to the database, verify user sessions, and apply site configuration.

The key sections of a standard wp-config.php:

  • Database connection settings — DB_NAME, DB_USER, DB_PASSWORD, DB_HOST: the credentials WordPress uses to connect to its MySQL database.
  • Security keys and salts — Eight unique random strings used to encrypt cookies and user sessions. Changing these immediately logs out all currently logged-in users.
  • Table prefix — $table_prefix defines the prefix for all WordPress database tables. The default wp_ is well-known to attackers; changing it adds a layer of obscurity.
  • Debug constants — WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY: control whether PHP errors are displayed or logged. Essential during development; should be disabled on live sites.
  • Additional constants — A wide range of optional settings covering memory limits, autosave intervals, revision counts, file editing permissions, SSL enforcement, and more.

Purpose & Benefits

1. Establishes the Database Connection

Every piece of content on a WordPress site — posts, pages, settings, users — lives in the database. wp-config.php is what makes that connection possible. If any database credential in the file is incorrect, the site returns a “Error establishing a database connection” message and goes down entirely. Correct configuration here is foundational.

2. Controls Site Security at the Server Level

Several critical security settings live in wp-config.php rather than in the WordPress admin panel. Disabling the built-in theme and plugin file editor (DISALLOW_FILE_EDIT), forcing SSL in the admin area (FORCE_SSL_ADMIN), and setting strong, unique security keys are all handled here. Our WordPress hosting and infrastructure services always include hardened wp-config.php configurations as part of the setup.

3. Enables Advanced Performance and Behavior Tuning

Constants in wp-config.php let you adjust WordPress’s default behavior in ways the admin dashboard doesn’t expose — increasing the PHP memory limit (WP_MEMORY_LIMIT), limiting the number of stored post revisions (WP_POST_REVISIONS), disabling the built-in WordPress cron in favor of a server-level cron (DISABLE_WP_CRON), and more. These settings directly affect site performance and server resource usage.

Examples

1. Basic Database Configuration

The core database connection settings that every wp-config.php requires:

<?php
// ** Database settings — provided by your web host ** //

/** The name of the database for WordPress */
define( 'DB_NAME', 'my_wordpress_db' );

/** Database username */
define( 'DB_USER', 'db_username' );

/** Database password */
define( 'DB_PASSWORD', 'strong_database_password' );

/** Database host — usually 'localhost' */
define( 'DB_HOST', 'localhost' );

/** Database charset */
define( 'DB_CHARSET', 'utf8mb4' );

/** Database collate type — leave blank unless you know you need to change this */
define( 'DB_COLLATE', '' );

These four settings — name, user, password, host — must match exactly what your hosting provider has configured for your database. A mismatch on any one of them prevents WordPress from loading.

2. Security Hardening Constants

A set of security-focused constants that should be added to every production site:

// Disable the built-in theme and plugin file editor in wp-admin
define( 'DISALLOW_FILE_EDIT', true );

// Force SSL (HTTPS) for all admin area requests
define( 'FORCE_SSL_ADMIN', true );

// Limit stored post revisions to keep the database lean
define( 'WP_POST_REVISIONS', 5 );

// Change the default table prefix from 'wp_' to something less predictable
$table_prefix = 'xk7_';

DISALLOW_FILE_EDIT is particularly important: if an attacker gains admin access, it removes their ability to inject malicious code through the dashboard’s built-in editor. For more on WordPress hardening, these constants are a good starting point.

3. Debug Configuration for Development vs. Production

Debug settings should be configured differently in development and production environments:

// --- DEVELOPMENT environment ---
define( 'WP_DEBUG', true );           // Enable error reporting
define( 'WP_DEBUG_LOG', true );       // Write errors to /wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // Don't show errors on-screen (log only)

// --- PRODUCTION environment ---
define( 'WP_DEBUG', false );          // Disable all error reporting
define( 'WP_DEBUG_DISPLAY', false );  // Never display errors to visitors
define( 'WP_DEBUG_LOG', false );      // Don't log errors in production
@ini_set( 'display_errors', 0 );      // Extra safety: disable at PHP level

Running WP_DEBUG as true on a live site can expose sensitive path information and error messages to visitors. Always disable it on production. Use WP_DEBUG_LOG set to true (with WP_DEBUG_DISPLAY set to false) if you need error logging on a production site without exposing errors publicly.

Common Mistakes to Avoid

  • Leaving WP_DEBUG enabled on a live site — Displaying PHP errors publicly reveals server paths, plugin names, and other details that give attackers useful information. Always set WP_DEBUG to false on production.
  • Using the default wp_ table prefix — The default prefix is known to every automated attack tool targeting WordPress. Changing it to something random doesn’t prevent all attacks, but it eliminates easy automated exploitation.
  • Storing wp-config.php with open file permissions — File permissions of 644 (readable by all users on a shared server) are far too permissive for a file containing database credentials. Set permissions to 440 or 400 so only the file owner can read it.
  • Editing wp-config.php without a backup — A syntax error in wp-config.php takes the entire site down immediately. Always download a copy before making edits, and test the site immediately after saving changes.

Best Practices

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

WordPress allows you to move wp-config.php one directory level above the public web root (e.g., from /public_html/wp-config.php to /wp-config.php). Files outside the web root cannot be accessed directly via HTTP, adding a meaningful layer of protection for a file that contains your database credentials. Not all hosting configurations support this, but it’s worth implementing where possible.

2. Generate Fresh Security Keys for Every Installation

WordPress security keys and salts encrypt session cookies. Use the official generator at https://api.wordpress.org/secret-key/1.1/salt/ to get fresh, random keys for every new installation. Also rotate keys immediately after any suspected compromise — this forces all logged-in users (including any attacker who may have active sessions) to log out. Our WordPress development process generates unique keys for every new site build.

3. Use Environment-Specific Configuration

On sites with staging and production environments, use conditionals or environment variables to keep configurations separate. Hardcoding production database credentials in a file that gets copied to staging is a common source of accidental data corruption. Many modern hosting platforms support environment variables that can be referenced in wp-config.php without storing credentials in the file itself:

// Reference credentials from server environment variables
// instead of hardcoding them in the file
define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) );

Frequently Asked Questions

What happens if wp-config.php is misconfigured?

Even a small error — wrong database name, a syntax mistake, an incorrect constant value — prevents WordPress from loading entirely. The site displays an error message like “Error establishing a database connection” or a blank white screen. Always back up the file before editing and test immediately after making changes.

Is wp-config.php the same on every WordPress installation?

The structure is the same, but the values are unique to each installation — different database credentials, different security keys, different constants based on the site’s needs. A file copied from one site to another won’t work on the new site without updating all the relevant values.

Can I add custom PHP settings to wp-config.php?

Yes. Because wp-config.php is loaded on every page request, it’s a valid place to set PHP configuration values — memory limits, execution time, file upload sizes — especially when you don’t have direct access to php.ini. This is commonly used on shared hosting environments.

Should I edit wp-config.php directly or use a plugin?

For most changes, direct editing is appropriate — but always via SFTP or SSH, not through the browser. Some hosting providers offer dashboard tools for common wp-config.php settings. Avoid plugins that manage wp-config.php unless they’re from highly reputable sources, since they require write access to one of your site’s most sensitive files.

How do I regenerate security keys?

Visit https://api.wordpress.org/secret-key/1.1/salt/ to generate a fresh set of eight unique keys. Replace the existing key definitions in the Authentication Unique Keys and Salts section of your wp-config.php with the new values. All users currently logged in will be signed out and will need to log in again.

Related Glossary Terms

How CyberOptik Can Help

As a WordPress-focused agency, we configure and harden wp-config.php on every site we build and host — setting correct file permissions, generating fresh security keys, disabling file editing, and tuning performance constants from the start. If you’re on a host that doesn’t give you this level of configuration control, or if you’re inheriting a site with a poorly configured setup, we can help. Learn about our hosting solutions or get in touch to discuss your project.