The wp-config.php is a core WordPress file of our WordPress website.

With the help of the wp-config.php file, we can manage or configure our WordPress website.

In this article you are going to see:

#Overview Overview

In WordPress the wp-config.php is one of the most important files.

The wp-config.php file is automatically generated while installing WordPress in the root directory of the website.

Below is the screenshot of my testing site which shows the location of the wp-config.php file.

By default, the wp-config.php does not exist. It is automatically created from wp-config-sample.php while installing WordPress. The wp-config.php contains the database configurations of the website.

Note: We can also create manually wp-config.php and set the database configuration to install WordPress.

Top ↑

#Database configuration: Database configuration:

Below are the constants which exist in the wp-config.php file from my localhost setup.

These constants are used for database connection.

define('DB_NAME', 'dev.test');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

Where,

• DB_NAME – It is a database name used for websites. Here my database name is dev.test.
• DB_USER – It is a username used to access the database. Here my username is root.
• DB_PASSWORD – It is a password used by a username to access the Database. Here my password is empty.
• DB_HOST – It is the hostname of your database server. Here my host is localhost.

Additionally there few other constants which are used for database connection.

• DB_CHARSET – It is used to set the database character set which is used when defining the MySQL database tables. The default value of utf8 (Unicode UTF-8) is almost always the best option.
• DB_COLLATE – The Database Collate type.

#Database Tables & Table Prefix Database Tables & Table Prefix

If you see the database after installing WordPress then it looks like the below screenshot:

WordPress creates a number of database tables for storing website data.

Below is the list of these tables:

• wp_commentmeta
• wp_comments
• wp_links
• wp_options
• wp_postmeta
• wp_posts
• wp_termmeta
• wp_terms
• wp_term_relationships
• wp_term_taxonomy
• wp_usermeta
• wp_users

If you notice that each table starts with the prefix wp_.

You can also change that table prefix by setting the variable $table_prefix from the wp-config.php file.

If you see the wp-config.php file then you can notice that the wp_ is the default table prefix for all the WordPress websites:

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each
 * a unique prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

Top ↑

#Security Keys Security Keys

The secret keys make the WordPress website harder to successfully attack by adding random elements to the password.

Password like “admin”, and “test” is simple and easily broken.

A random, long password that uses no dictionary words, such as “gAwkoT,sCJQ<ni0Z$=T5x)9$lGYp%@L” would take a brute force attacker millions of hours to crack.

Below is the constant which adds some random keys in the wp-config.php file while installing WordPress.

define('AUTH_KEY',         '>O,Ev[NTf-Pe!WaqYPa*]{]}xu#;[xB4.:(hqDEjMR7?:b;[RPh5;%&LXYa@xIEs');
define('SECURE_AUTH_KEY',  'S=]oW8;%Q5`X_5Vpf?K~0e}<O#;/ zV{P*/c7@R.)(Q$ImW&^u[+* wwRAge=pcT');
define('LOGGED_IN_KEY',    'gAwkoT,sCJQ<ni0Z$=T5x)9$lGYp%@L?iLa<%@/)2vB>5v4d!#%3_dE>w9$pcPj.');
define('NONCE_KEY',        'oKhOPl9=lA>{-qmT^|,Mt.L9@[aIM;Whu2u9nLTf[T/Ftvk;x`L*]b &R0b(Kkj&');
define('AUTH_SALT',        'I_tZSV(%?=K@`5+vj)-ABb}OOU(+k)7kJ./9:)cc}Z(8b[pk2IoMeJm5q`_3Ikp}');
define('SECURE_AUTH_SALT', 'n[(nC(VxYP>S|m?B/ohN}>!w1YHwZu1{^m=9CB/Lt7t{nHH1GM5Is6S>AQ,&&JCO');
define('LOGGED_IN_SALT',   '-G0Qd=?{oYB?7X!$I8;J:FMA</JWKQ5T(~?=RY&A[044|-G;}R_5}J8$t5Ij;f]0');
define('NONCE_SALT',       'Y[J~h{tnXzJfY[O,T+^hSi1{0GN:X6~(5lYL.l{(Cq<-8F{k!IJZ3nk<=h$pjwNA');

If you don’t have these keys then don’t worry. You can simply create a theme from the WordPress random secret key generator tool.

See https://api.wordpress.org/secret-key/1.1/salt/

Top ↑

#Additional Constants Additional Constants

• WP_SITEURL allows the WordPress address (URL) to be defined. The value defined is the address where your WordPress core files reside.

E.g.

define( 'WP_SITEURL', 'https://mysite.com/wordpress' );

• WP_HOME is the address you want people to type in their browser to reach your WordPress blog.

E.g.

define( 'WP_HOME', 'https://mysite.com/wordpress' );

• WP_CONTENT_DIR to the full local path of this directory (no trailing slash), e.g.

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );

• WP_CONTENT_URL to the full URL of this directory (no trailing slash), e.g.

define( 'WP_CONTENT_URL', 'https://mysite.com/blog/wp-content' );

• WP_PLUGIN_DIR to the full local path of this directory (no trailing slash), e.g.

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

• WP_PLUGIN_URL to the full URI of this directory (no trailing slash), e.g.

define( 'WP_PLUGIN_URL', 'https://mysite.com/blog/wp-content/plugins' );

• PLUGINDIR to the full local path of this directory (no trailing slash), e.g.

define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

• UPLOADS to set the uploads directory path which contain all the uploaded files. e.g.

define( 'UPLOADS', 'blog/wp-content/uploads' );

• AUTOSAVE_INTERVAL WordPress use Ajax to auto-save revisions of the post while editing the post. Default it trigger for each 60 seconds. Change it in wp-config.php file. E.g.

define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds

#Disable Post Revisions #Disable Post Revisions Disable Post Revisions #Disable Post Revisions

If you do not set this value, WordPress defaults WP_POST_REVISIONS to true (enable post revisions). If you want to disable the awesome revisions feature, use this setting:

define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds

• WP_POST_REVISIONS to set the maximum number of revisions. e.g.

define( 'WP_POST_REVISIONS', 3 );

• COOKIE_DOMAIN You can set the cookie domain like.

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

• WP_ALLOW_MULTISITE By setting this constant you can enable to multisite setup for your WordPress site. e.g.

define( 'WP_ALLOW_MULTISITE', true );

define( 'WP_ALLOW_MULTISITE', true );

NOBLOGREDIRECT can be used to redirect the browser if the visitor tries to access a nonexistent subdomain or a subfolder.

define( 'NOBLOGREDIRECT', 'http://example.com' );

The WP_DEBUG option controls the reporting of some errors and warnings and enables use of the WP_DEBUG_DISPLAY and WP_DEBUG_LOG settings. The default boolean value is false.

define( 'WP_DEBUG', true );

Top ↑

#SCRIPT_DEBUG SCRIPT_DEBUG

SCRIPT_DEBUG is a related constant that will force WordPress to use the “dev” versions of scripts and stylesheets in wp-includes/js, wp-includes/css, wp-admin/js, and wp-admin/css will be loaded instead of the .min.css and .min.js versions.. If you are planning on modifying some of WordPress’ built-in JavaScript or Cascading Style Sheets, you should add the following code to your config file:

define( 'SCRIPT_DEBUG', true );

To result in faster administration screens, all JavaScript files are concatenated into one URL. If JavaScript is failing to work in an administration screen, you can try disabling this feature:

define( 'CONCATENATE_SCRIPTS', false );

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

Top ↑

#Increasing memory allocated to PHP Increasing memory allocated to PHP

WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as “Allowed memory size of xxxxxx bytes exhausted”.

Increase PHP Memory to 64MB

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

Increase PHP Memory to 96MB

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

Administration tasks require much memory than usual operation. When in the administration area, the memory can be increased or decreased from the WP_MEMORY_LIMIT by defining WP_MAX_MEMORY_LIMIT.

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

The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.

define( 'WP_CACHE', true );

CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designate that the user and usermeta tables normally utilized by WordPress are not used, instead these values/tables are used to store your user information.

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

WPLANG defines the name of the language translation (.mo) file. WP_LANG_DIRdefines what directory the WPLANG .mo file resides. If WP_LANG_DIR is not defined WordPress looks first to wp-content/languages and then wp-includes/languages for the .mo defined by WPLANG file.

define( 'WPLANG', 'de_DE' );
define( 'WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages' );

The SAVEQUERIES definition saves the database queries to an array and that array can be displayed to help analyze those queries. The information saves each query, what function called it, and how long that query took to execute. Note: This will have a performance impact on your site, so make sure to turn this off when you aren’t debugging.

First, add this to the wp-config.php file:

define( 'SAVEQUERIES', true );

The FS_CHMOD_DIR and FS_CHMOD_FILE define statements allow override of default file permissions. These two variables were developed in response to the problem of the core update function failing with hosts running under suexec. If a host uses restrictive file permissions (e.g. 400) for all user files, and refuses to access files which have group or world permissions set, these definitions could solve the problem.

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

Example to provide setgid:

define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );

The following are valid constants for WordPress updates:

• FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not.
  • (Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
  • (Secondary Preference) “ssh2” is to force the usage of the SSH PHP Extension if installed
  • (3rd Preference) “ftpext” is to force the usage of the FTP PHP Extension for FTP Access, and finally
  • (4th Preference) “ftpsockets” utilises the PHP Sockets Class for FTP Access.
• FTP_BASE is the full path to the “base”(ABSPATH) folder of the WordPress installation.
• FTP_CONTENT_DIR is the full path to the wp-content folder of the WordPress installation.
• FTP_PLUGIN_DIR is the full path to the plugins folder of the WordPress installation.
• FTP_PUBKEY is the full path to your SSH public key.
• FTP_PRIKEY is the full path to your SSH private key.
• FTP_USER is either user FTP or SSH username. Most likely these are the same, but use the appropriate one for the type of update you wish to do.
• FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication this can be omitted.
• FTP_HOST is the hostname:port combination for your SSH/FTP server. The default FTP port is 21 and the default SSH port is 22. These do not need to be mentioned.
• FTP_SSL TRUE for SSL-connection if supported by the underlying transport (not available on all servers). This is for “Secure FTP” not for SSH SFTP.

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_BASE', '/path/to/wordpress/' );
define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp.example.org' );
define( 'FTP_SSL', false );

Disable cron entirely by setting DISABLE_WP_CRON to true.

define( 'DISABLE_WP_CRON', true );

Make sure a cron process cannot run more than once every WP_CRON_LOCK_TIMEOUT seconds.

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Here are additional constants that can be defined. These probably shouldn’t be set unless other methodologies have been attempted first. The Cookie definitions can be particularly useful if you have an unusual domain setup.

define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) );
define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) );
define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) );
define( 'TEMPLATEPATH', get_template_directory() );
define( 'STYLESHEETPATH', get_stylesheet_directory() );

This constant controls the number of days before WordPress permanently deletes posts, pages, attachments, and comments, from the trash bin. The default is 30 days:

define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days

To disable trash set the number of days to zero.

define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

Top ↑

#Automatic Database Optimizing Automatic Database Optimizing

There is automatic database repair support, which you can enable by adding the following define to your wp-config.php file.

Note: This should only be enabled if needed and disabled once the issue is solved. When enabled, a user does not need to be logged in to access the functionality, since its main intent is to repair a corrupted database and users can often not login when the database is corrupt.

 define( 'WP_ALLOW_REPAIR', true );

The script can be found at {$your_site}/wp-admin/maint/repair.php.

Top ↑

#DO_NOT_UPGRADE_GLOBAL_TABLES DO_NOT_UPGRADE_GLOBAL_TABLES

A DO_NOT_UPGRADE_GLOBAL_TABLES define prevents dbDelta() and the upgrade functions from doing expensive queries against global tables.

Sites that have large global tables (particularly users and usermeta), as well as sites that share user tables with bbPress and other WordPress installs, can prevent the upgrade from changing those tables during upgrade by defining DO_NOT_UPGRADE_GLOBAL_TABLES to true. Since an ALTER, or an unbounded DELETE or UPDATE, can take a long time to complete, large sites usually want to avoid these being run as part of the upgrade so they can handle it themselves. Further, if installations are sharing user tables between multiple bbPress and WordPress installs you may to want one site to be the upgrade master.

  define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

Top ↑

#View All Defined Constants View All Defined Constants

PHP has a function that returns an array of all the currently defined constants with their values.

 print_r( @get_defined_constants() );

Top ↑

#Disable the Plugin and Theme Editor Disable the Plugin and Theme Editor

Occasionally you may wish to disable the plugin or theme editor to prevent overzealous users from being able to edit sensitive files and potentially crash the site. Disabling these also provides an additional layer of security if a hacker gains access to a well-privileged user account.

define( 'DISALLOW_FILE_EDIT', true );

Note: The functionality of some plugins may be affected by the use of current_user_can('edit_plugins') in their code. Plugin authors should avoid checking for this capability, or at least check if this constant is set and display an appropriate error message. Be aware that if a plugin is not working this may be the cause.

Top ↑

#Disable Plugin and Theme Update and Installation  Disable Plugin and Theme Update and Installation 

This will block users being able to use the plugin and theme installation/update functionality from the WordPress admin area. Setting this constant also disables the Plugin and Theme editor (i.e. you don’t need to set DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT, as on its own DISALLOW_FILE_MODS will have the same effect).

define( 'DISALLOW_FILE_MODS', true );

Top ↑

#Require SSL for Admin and Logins Require SSL for Admin and Logins

Note: WordPress Version 4.0 deprecated FORCE_SSL_LOGIN. Please use FORCE_SSL_ADMIN.

FORCE_SSL_ADMIN is for when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear. See also Administration_Over_SSL for more details.

define( 'FORCE_SSL_ADMIN', true );

Top ↑

#Block External URL Requests Block External URL Requests

Block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL as true and this will only allow localhost and your blog to make requests. The constant WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow, wildcard domains are supported, eg *.wordpress.org will allow for all subdomains of wordpress.org to be contacted.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

Top ↑

#Disable WordPress Auto Updates Disable WordPress Auto Updates

There might be reason for a site to not auto-update, such as customizations or host supplied updates. It can also be done before a major release to allow time for testing on a development or staging environment before allowing the update on a production site.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Top ↑

#Disable WordPress Core Updates Disable WordPress Core Updates

The easiest way to manipulate core updates is with the WP_AUTO_UPDATE_CORE constant:

 # Disable all core updates:
 define( 'WP_AUTO_UPDATE_CORE', false );

 # Enable all core updates, including minor and major:
 define( 'WP_AUTO_UPDATE_CORE', true );

 # Enable core updates for minor releases (default):
 define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Reference: Disabling Auto Updates in WordPress 3.7

Top ↑

#Cleanup Image Edits Cleanup Image Edits

By default, WordPress creates a new set of images every time you edit an image and when you restore the original, it leaves all the edits on the server. Defining IMAGE_EDIT_OVERWRITE as true changes this behaviour. Only one set of image edits are ever created and when you restore the original, the edits are removed from the server.

 define( 'IMAGE_EDIT_OVERWRITE', true );