{"id":2009895,"date":"2022-05-06T20:00:00","date_gmt":"2022-05-06T20:00:00","guid":{"rendered":"https:\/\/wpx.net\/blog\/?p=2009895"},"modified":"2023-11-01T11:09:14","modified_gmt":"2023-11-01T11:09:14","slug":"wpconfig-immense-power","status":"publish","type":"post","link":"https:\/\/wpx.net\/blog\/wpconfig-immense-power\/","title":{"rendered":"The Immense Power of wp-config.php"},"content":{"rendered":"\n

The thing that motivates me in writing these columns for WPX.net is my desire to help you achieve mastery over WordPress. Mastery implies having knowledge and exerting control.<\/p>\n\n\n\n

There is one file within each WordPress installation that allows an inordinate amount of control over the behavior of the entire instance \u2014 core, themes, and even some plugins: the wp-config.php<\/strong> file. You can use it to unlock hidden functionality and impose limits on users’ behavior and performance that are impossible to override from the WordPress dashboard.<\/p>\n\n\n\n

I have already mentioned wp-config.php in passing in a couple of previous columns. In this article, it will be the centerpiece.<\/p>\n\n\n\n

Interestingly, the WordPress Codex<\/a> does not have a separate article about wp-config.php configuration parameters. There is no explanation of how to use all of them.<\/p>\n\n\n\n

I am aiming to improve that. When published, this column will be the most detailed collection of documented wp-config settings in existence, as far as I know. I also intend to come back to it regularly and update it when I come across some new and helpful settings.<\/p>\n\n\n\n

This isn’t the kind of blog post that one is expected to read from beginning to end (but please feel free to skim through it at least the first time you see it). It has been structured like a reference guide. If you find any of this information useful, bookmark it and check back from time to time.<\/p>\n\n\n\n

Let us dig into what wp-config.php can offer us.<\/p>\n\n\n\n

<\/span>Database Access and Configuration<\/span><\/h2>\n\n\n\n

Almost everyone knows that wp-config.php holds database credentials. If you ever see the ‘Error establishing a database connection’ message when opening your WordPress website, the very first thing you need to do is open up-config.php and check out the settings for DB_NAME<\/code>, DB_USER<\/code>, DB_PASSWORD<\/code> and DB_HOST<\/code>.<\/p>\n\n\n\n

Near these are two other less well-understood parameters: DB_CHARSET<\/code> and DB_COLLATE<\/code>. The Database Character Set determines the encoding used within the database. Since WordPress 4.2, the default and recommended setting for this is ‘utf8mb4<\/strong>‘ which allows the database to store the full, 32-bit range of Unicode symbols. This should be the default value for any new WordPress instance you create.<\/p>\n\n\n\n

The collation setting determines how symbols are sorted within the selected character set. The recommended value for this setting is ‘utf8mb4_unicode_ci<\/strong>‘ but if your WordPress website is designated to use with a specific language, you might select that specific collation. The rule of thumb here is that if you need to change the collation, you know<\/strong> you have to; otherwise, you should stick with Unicode, case-insensitive.<\/p>\n\n\n\n

<\/span>Keys and Salts<\/span><\/h2>\n\n\n\n

Below the database settings is a block of 4 keys and 4 salts. WordPress uses the four keys to encrypt certain parts of its data and salts the data stored in the browser cookies with the other 4 strings to prevent cookie forgery. These values should never<\/strong> be shared with anybody.<\/p>\n\n\n\n

Regenerating the keys and salts is the fastest way to stop site hijacking via stolen browser cookies. Replacing them has the effect of immediately invalidating all existing sessions (including yours, as the administrator).<\/p>\n\n\n\n

Bear in mind that somebody who is finalizing a purchase from your Woocommerce store as you are resetting the keys and salts will lose their cart contents, but there will be no long-lasting effects or consequences besides that.<\/p>\n\n\n\n

<\/span>Force Use of HTTPS<\/span><\/h2>\n\n\n\n

These days, it is less frequent to see websites that do not use SSL connections to serve pages to their visitors. Usually, this is handled at the server level; and if your website uses HSTS headers, even at the domain level.<\/p>\n\n\n\n

However, if a particular site does not use SSL by default, you might want to make sure that at least the admin area is using an encrypted connection. To do that, you may add this setting to wp-config.php<\/p>\n\n\n\n

define('FORCE_SSL_ADMIN', true);<\/code><\/pre>\n\n\n\n
Note: older WordPress tutorials mention another setting, FORCE_SSL_LOGIN, which enforces an encrypted connection for login pages. This one is deprecated since WordPress 4.4; even if you put it in wp-config.php, it will be ignored.<\/p>\n\n\n\n
<\/span>Post and Media Management and Housekeeping<\/span><\/h2>\n\n\n\n
WordPress has a very robust autosave and versioning for blog posts, which allows users to effortlessly restore their content to an earlier state.<\/p>\n\n\n\n
By default, WordPress will enable auto-save and store a copy of your post in the database and in the browser’s cache once every 60 seconds. Depending on your preferences, you might want to change that. You do this by adding the following line to wp-config.php:<\/p>\n\n\n\n
define( 'AUTOSAVE_INTERVAL', 120 ); \/\/ Defaults to 60 seconds<\/code><\/pre>\n\n\n\n
It is not currently possible to completely disable autosave, but providing a large enough value will do the same. Hint: there are 86,400 seconds in a 24-hour day.<\/p>\n\n\n\n
Keeping previous posts revisions can be a lifesaver, but it also fills the database with many copies of your posts. This could quickly turn into an issue if you have many writers working in parallel. That is why WordPress allows you to limit the number of post revisions it will store, or to disable revisioning altogether:<\/p>\n\n\n\n
define( 'WP_POST_REVISIONS', 3 );\ndefine( 'WP_POST_REVISIONS', false ); \/\/ Disable feature<\/code><\/pre>\n\n\n\n
Note: changing this setting will not influence the number of post revisions for existing posts, unless you edit each one of them afterwards. Plugins like WP-Optimize<\/a> can help you clean up revisions of old publications.<\/p>\n\n\n\n
<\/span>Media Management<\/span><\/h2>\n\n\n\n
Unlike blog posts, pages, comments, and other kinds of data, WordPress treats images very roughly. It allows users to delete them and offers no means of restoring them once this is done.<\/p>\n\n\n\n
The solution to this apparent injustice is the following pair of wp-config.php settings:<\/p>\n\n\n\n
define('MEDIA_TRASH', true) ;  \/\/ Trash media files instead of delete\ndefine('EMPTY_TRASH_DAYS', 7); \/\/ Empty trash after 7 days<\/code><\/pre>\n\n\n\n
The first one enables the trash bin for media images, and the second one determines how long they are kept there before getting deleted for real. Bear in mind that enabling EMPTY_TRASH_DAYS is not obligatory: if you leave it out of the config file, media images will simply stay in the trash until manually deleted.<\/p>\n\n\n\n
By default, the media library will only accept files of certain formats. While this list is long, you might find yourself in a situation when you need to upload a file and publish it on your WordPress website, except WordPress would have none of it. The easiest way to allow this is to enable the following settings:<\/p>\n\n\n\n
define('ALLOW_UNFILTERED_UPLOADS', true);<\/code><\/pre>\n\n\n\n
However, bear in mind that this has the potential to significantly degrade the WordPress security model. It allows privileged users to upload unchecked files that might be infected with malware, or \u2014 if you are uploading shell scripts and executable files \u2014 hackers could make attempts to call them from the outside. This option should be used with extreme caution, and\/or only occasionally (for example, you could enable it while you upload a specific file, link to it from a blog post, and then disable unfiltered uploads once more).<\/p>\n\n\n\n
<\/span>Memory Allocation<\/span><\/h2>\n\n\n\n
WordPress allows users to set or increase the limit to the usage of system RAM. If you ever get a PHP error that says ‘Allowed memory size of ... bytes exhausted (tried to allocate ... bytes)<\/code>‘, then it is time to increase your RAM limit. The way to do that is to add the following setting to wp-config.php<\/p>\n\n\n\n
define('WP_MEMORY_LIMIT', 128M);<\/code><\/pre>\n\n\n\n
Having more RAM at our disposal could be helpful for heavier websites with complicated functionality. You should always remember however that usually there is a memory limit setting imposed globally on your hosting account, and that you can’t rely on WP_MEMORY_LIMIT to get access to indefinitely more memory than is allotted to you by the webhost.<\/p>\n\n\n\n
However, it is important to know that WP_MEMORY_LIMIT has a less-known sister function that allows administrators to control RAM usage in the back end independently of the front end.<\/p>\n\n\n\n
define('WP_MAX_MEMORY_LIMIT', 256M);<\/code><\/pre>\n\n\n\n
WP_MAX_MEMORY_LIMIT overrides the memory limit for PHP processes executing in the back end, which could help those who use WordPress as a CRM service or something similar. But once again, you must remember that you are limited by the memory allocation that your host provides.<\/p>\n\n\n\n
Side note: this limit is very often 128MB, and more rarely 256MB. However WPX \u2014 being the awesome host they are \u2014 allow their clients to set up a max memory limit of 1024MB.<\/p>\n\n\n\n
<\/span>Catch and Process 404 Not Found Requests<\/span><\/h2>\n\n\n\n
I honestly think that allowing users to see a 404 ‘Not Found’ page is a small tragedy. As a webmaster, you should do your utmost to prevent such situation. Thankfully, WordPress makes things much easier for you: it can be configured to intercept all 404 requests and send them to a custom page, and you only need to create that page.<\/p>\n\n\n\n
\/* Catch 404 pages and redirect to a custom page *\/\ndefine('NOBLOGREDIRECT', 'https:\/\/YOURDOMAIN.COM\/are-you-lost');<\/code><\/pre>\n\n\n\n
I have planned a blog post specifically dedicated to creating custom 404 pages. However that one is still many weeks away from completion, and you might not have time to wait for me. In such a case, open Google, and search for “awesome 404 error pages” to get some ideas.<\/p>\n\n\n\n
<\/span>Enable\/Disable Theme and Plugin Editor<\/span><\/h2>\n\n\n\n
WordPress ships with a quite convenient file editor that allows users to make changes to theme and plugin components. On production websites, these functions should of course stay disabled and hidden.<\/p>\n\n\n\n
But if you are working on a theme or a plugin and need to study the code, this is the fastest way to view it and make changes if needed.<\/p>\n\n\n\n
define( 'DISALLOW_FILE_EDIT',  false );\ndefine( 'DISALLOW_THEME_EDIT', false );<\/code><\/pre>\n\n\n\n
Pasting these two inside wp-config.php will add two new entries to your WordPress admin bar:<\/p>\n\n\n\n
Plugins \u27a1 Plugin File Editor
Appearance \u27a1 Theme File Editor<\/p>\n\n\n\n
<\/span>Change Site URL and Home Directory<\/span><\/h2>\n\n\n\n
These next two settings are extraordinarily powerful.<\/p>\n\n\n\n
When you provision a new WordPress instance, the installer sets up two very important internal parameters: WP_HOME and WP_SITEURL. These were initially meant to be used when somebody wanted to configure WordPress to appear as if it opens from the default domain URL but without cluttering the www root folder with extra files.<\/p>\n\n\n\n
Hence, WordPress allows you to provide separate settings for the physical locations of your WordPress folder and the publicly-facing domain. You would set WP_HOME to https:\/\/example.com<\/a> and WP_SITEURL to https:\/\/example.com\/wordpress\/<\/a>, for example. Combined with some .htaccess trickery, when visitors attempt to load example.com, WordPress would serve them from example.com\/wordpress but the URLs in the address bar would still appear as if they originate from example.com.<\/p>\n\n\n\n
This was important maybe 10 or 15 years ago when WordPress had little adoption and had to offer anything it could to make it easy for webmasters to deploy it parallel to some other CMS or static website.<\/p>\n\n\n\n
Nowadays almost nobody would think about tucking WordPress away in a subfolder (‘Nobody puts Baby in the corner!’), but the WP_HOME and WP_SITEURL settings are still supported, and can be used for something way more powerful, like changing the entire apparent URL of the domain, or making the same WordPress instance serve content under multiple domains!<\/p>\n\n\n\n
The values for WP_HOME and WP_SITEURL can be changed from the admin dashboard (Settings \u27a1 General, WordPress Address and Site Address), and are stored in the wp-options table. Normally, this limits WordPress to responding only to requests that match the domain and URL stored in these settings.<\/p>\n\n\n\n
However, we can use wp-config.php to override the default WordPress behavior and add the following lines:<\/p>\n\n\n\n
define( 'WP_SITEURL', 'http:\/\/example.com\/wordpress' );\ndefine( 'WP_HOME',    'http:\/\/example.com' );<\/code><\/pre>\n\n\n\n
WP_SITEURL and WP_HOME will override the matching values stored within the wp_options table, but will not change them permanently. This makes these settings extremely helpful when you need to promptly migrate the WordPress instance to a different domain, or to make a quick copy of it for testing\/staging purposes and let yourself in to make permanent changes.<\/p>\n\n\n\n
We can even use PHP environment variables to make the address replacement dynamic. Consider this setting:<\/p>\n\n\n\n
define ( 'WP_SITEURL', 'https:\/\/' . $_SERVER['HTTP_HOST'] );\ndefine ( 'WP_HOME', 'https:\/\/' . $_SERVER['HTTP_HOST'] );<\/code><\/pre>\n\n\n\n
Now imagine that your web server is configured to serve 5 different domains: example.com, example.net, example.gov, example.edu, example.org. As long as these domains are configured to resolve to the IP address of your web server, and you have configured the www_root for each vhost to point towards the physical folder where your WP instance is located, WordPress will respond to each inquiry as if it has been configured to serve each domain natively!<\/p>\n\n\n\n
One final word about site relocation: there might be another way to do it using a similar setting called RELOCATE that I learned about recently, but haven’t used in practice.<\/p>\n\n\n\n
define ( 'RELOCATE', true );<\/code><\/pre>\n\n\n\n
It is mentioned in the WordPress codex, under the main article that discusses changing a WordPress websites’ URL<\/a>. As far as I can tell, the difference between the previous method and this one is that RELOCATE reads the values of HTTP_HOST and PATH_INFO from the server environment and changes the content of WordPress Address URL and Site Address URL in Settings \u27a1 General.<\/p>\n\n\n\n
In a sense, the behavior is similar to that of using WP_SITEURL and WP_HOME with the HTTP_HOST server variable, which makes RELOCATE a convenient shortcut.<\/p>\n\n\n\n
It is very important to disable this setting as soon as you’re done moving the website.<\/p>\n\n\n\n
<\/span>Auto-Update Control<\/span><\/h2>\n\n\n\n
WordPress has four types of components that require periodic updates:<\/p>\n\n\n\n