On This Page: [hide]
The wp-config.php is one of the fundamental components of any WordPress site installation. This is the service file which contains all important information that is required by the scripts to function properly. It is initially setup by the owners during the site creation. The basic settings are entered via the web interface to get the WordPress site running. However there are many settings and variables which can be changed manually by the administrators for different purposes. This guide will teach you all that you need to know about wp-config.php.
All About The wp-config.php
wp-config.php is the main WordPress configuration file which is essential for any website installation using this content management system. It is created automatically by the setup process. It will be filled with custom values that are needed in order for the site to start working and optional parameters can later be edited when needed. Many site administrators do not know that they can create their own wp-config.php from scratch without using the setup wizard, they can use any text editor which they like. To get it working they will only need to upload the file to the main WordPress root directory. Every WordPress installation package also includes a wp-config-sample.php which contains a template that can be used to create the actual WordPress configuration file. There are four main variables which are required in order to start a WordPress site:
- Database Name — This is the name of the database which is to be used by the WordPress installation
- Database Username — This string will specify the username used to access the database
- Database Host — This value specifies the hostname used by the database server. In some cases the users will also need to specify other values: a port number, UNIX socket file path or a pipe. Ask your web hosting company if you are unsure, in most cases localhost will work just fine
- Database Collate Type — This is a special option which should be left blank if a non-standard regional /language option environment is present. By default it is left blank which will make the WordPress installation use the default options as given by the MySQL database server
We advice our readers to use a special code editor and not a general-purpose word processor. The use of office packages can potentially break the special formatting and corrupt the configuration file.
Wp-config Database Options
There are some specific values that are specific to the database options. Depending on the hosting plan and company that the administrators are using there are several values which must be changed in order for the installation to work correctly. The necessity to alter them will depend on the chosen hosting settings. Check with your provider if there are any special values which need to be filled. This can be done via the database section of the relevant hosting company’s host panel. There are several instances where customization may be required:
- Database Alternative Port Requirement — There may be some cases where a non-default database server port must be set. This means that the service will operate from a service that is launched with custom settings or a remote host that is not localhost — meaning that the web server and databases operate on different machines
- Database Charset Value — This will define the character set used by the database. The default option utf8 (corresponding to the UTF-8 standard) will work in most cases and only needs to be changed if a non-standard server locale is defined
- Database Collate Type — This is a special option which should be left blank if a non-standard regional /language option environment is present. By default it is left blank which will make the WordPress installation use the default options as given by the MySQL database server
Custom tables for the users and meta fields are done by specifying custom values in these two holders:
— CUSTOM_USER_META_TABLE and CUSTOM_USER_META_TABLE
This is useful if the administrators want to store multiple installations in a single database. From version 2.9 onwards the WordPress content management system supports automatic database optimization. It can be used when corrupted databases or other related issues have been identified. This can be enabled optionally by setting the inserting the following string in wp-config.php:
— WP_ALLOW_REPAIR
All About The Database Security Keys
The configuration files has eight lines of security keys and tokens. As soon as the site is prepared they will be filled automatically by the engine which will generate set of unique keys that correspond to the best security policies as defined by the WordPress developers. However there is the possibility for the users to enter in their own unique strings, it is recommended to use a strong password generator such as the one provided by WordPress. There is a distinction between the key and salt values. Security keys are special strings that are used during the authorization and encryption processes of web cookies — small-sized bits of information that are used by the site to track the users and to allow for certain dynamic interactions. The so-called salt values are used to further strengthen the security keys — they provide an additional layer of encryption for security purposes.
Contemporary versions of the WordPress system have 8 distinct values of these types which are labelled as the following:
AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT.
Note: If the security keys and salts are deleted from the system this will force log out all logged in users.
Debug Mode Configuration In wp-config.php
Site administrators and web programmers can also access and enable some of the advanced capabilities of WordPress. Debug mode can be turned on by specifying “true” in the variable:
define( ‘WP_DEBUG’, true );
This must not be used on live installation as the debug mode will present errors and potentially sensitive information about the internal workings of the site. This may be very useful when the WordPress owners are trying to fix an issue or optimize parts of their code. In some situations when live sites must be worked on and there is no possibility to enter into maintenance mode a workaround can be activated. The following set of values can be inserted in the wp-config.php file:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 );
This will essentially keep debug mode on however all errors and warnings will be recorded in a file called debug.log file which is placed in the /wp-content folder.
Advanced wp-config.php Content Options
There are several important considerations when it comes to the content settings. Site owners can modify the number of autosave intervals, by this will happen each 60 seconds. A custom value declaration can be inserted using the following string:
define( ‘AUTOSAVE_INTERVAL’, 160 );
This is particularly useful for larger sites as the WordPress engine will add a row with the necessary changes in the table for each revision. However when a site become too big this can “clog down” the site and affect the database size and performance. Post revisions can be disabled with the following declaration:
define( ‘WP_POST_REVISIONS’, false );
The website owners can be limited to a certain number as well:
define( ‘WP_POST_REVISIONS’, 10 );
The default configuration of WordPress will store any trashed contents for 30 days after which it will be deleted forever. This can be edited by modifying the relevant value, in this case it will be changed to 10 days:
define( ‘WP_POST_REVISIONS’, 10 );
If the value is set to 0 WordPress will always delete the content and will not preserve revisions. When it comes to adjusting cache size and other related variables there are some cases where memory adjustments need to be made. If at any time visitors or the site owners see a message reading “Fatal error: Allowed memory size of xxx bytes exhausted …” the maximum memory size will need to be adjusted. This can be done from the general php.ini file defining the working parameters of the PHP service of the webserver or setting a custom variable in wp-config.
The default option is set to 40 MB for single sites and 64 for multisite installations. The custom value can be set with the following string declaration:
define( ‘WP_MEMORY_LIMIT’, ‘128M’ );
Users can also define a maximum memory size, here is an example:
define( ‘WP_MAX_MEMORY_LIMIT’, ‘256M’ );
Every time an image is edited from the WordPress panel a revision will be storedin the database and media library. The saving of these edits can be disabled in setting this constant:
define( ‘IMAGE_EDIT_OVERWRITE’, true );
Other wp-config.php Settings
Some of the other options which can be fined tune include the option of force disabling the automatic updates service. Since version 3.7 of WordPress it is enabled by default for security releases — the site installations will frequently call to the main WordPress site and check if there are any critical updates. If such are found the sites will be updated. This function can be disabled by entering this field:
define( ‘AUTOMATIC_UPDATER_DISABLED’, true );
A similar action can be done to disposable all core updates with this string:
define( ‘WP_AUTO_UPDATE_CORE’, false );
Automatic updates of major revisions can be set to enable as well. By default only minor releases of WordPress will be automatically applied. To enable this functionality insert the following string:
define( ‘WP_AUTO_UPDATE_CORE’, true );
Security wise there are some parameters which can be fine tuned in order to protect site installations. A recommended step is to disable the file editor in the administrative panel. This will prevent users with WordPress administrative privileges from directly accessing and modifying the core files used by the content management system. In an event of hacked credentials this will prevent unauthorized reconfiguration of WordPress. This is possible by inserting this string:
define( ‘DISALLOW_FILE_EDIT’, true );
Site owners can also enable a specific HTTP block for some hosts and enable only certain hosts to access the administrative panel. This is controlled by these two fields:
define( ‘WP_HTTP_BLOCK_EXTERNAL’, true );
define( ‘WP_ACCESSIBLE_HOSTS’, ‘example.com,*.anotherexample.com’ );
High-level users can also be prevented from publishing unfiltered HTML messages. By default only editors and administrators have the ability to post them. Line modificatins will generally disable this functionality, it is possible by inserting the following code:
define( ‘WP_HTTP_BLOCK_EXTERNAL’, true );
define( ‘DISALLOW_UNFILTERED_HTML’, true );
The wp-config.php file can be locked down by inserting the following directive in the .htaccess file which is read by the Apache web server:
order allow,deny
deny from all
For nginx web server the following needs to be added to its configuration file:
location ~* wp-config.php { deny all; }
Additional options are available as well. For a detailed overview you can check the complete wp-config.php guide which is posted on the official site of the project. Depending on individual needs other options that are not listed here can be found there.