{"id":134345,"date":"2014-12-11T07:00:33","date_gmt":"2014-12-11T12:00:33","guid":{"rendered":"http:\/\/premium.wpmudev.org\/blog\/?p=134345"},"modified":"2022-03-02T05:28:14","modified_gmt":"2022-03-02T05:28:14","slug":"wordpress-wp-config-file-guide","status":"publish","type":"post","link":"https:\/\/wpmudev.com\/blog\/wordpress-wp-config-file-guide\/","title":{"rendered":"The WordPress wp-config File: A Comprehensive Guide"},"content":{"rendered":"<p>The WordPress configuration file, also known as wp-config.php, is most frequently used to set up a\u00a0database connection and is then forgotten. Despite its neglected nature, it is a powerhouse of features and opportunities for optimization.<\/p>\n<p>While you don&#8217;t typically use\u00a0the config file on a day-to-day basis, I&#8217;m betting that almost every WordPress install could benefit from adding a couple of things to this file. A well thought out config file can not only make a website faster and more secure, it can also add features like the ability to empty the trash more frequently, or disabling features such as revisions and offer advanced debugging capabilities.<\/p>\n<p>In this article we&#8217;ll look at the default settings that ship with your config file and how you can tweak it to better suit the needs of your WordPress website.<\/p>\n<p>We&#8217;ll cover:<\/p>\n<ul>\n<li><a href=\"#what-is\">What is the wp-config.php File?<\/a><\/li>\n<li><a href=\"#content\">The Default Config Content<\/a>\n<ul>\n<li><a href=\"#db-configuration\">Database Configuration<\/a><\/li>\n<li><a href=\"#salts\">Salts And Keys<\/a><\/li>\n<li><a href=\"#other-configs\">Other Config Settings<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#customizing\">Customizing the wp-config\u00a0File<\/a>\n<ol>\n<li><a href=\"#urls\">WordPress URLs<\/a><\/li>\n<li><a href=\"#custom-dir\">Custom Directory Locations<\/a><\/li>\n<li><a href=\"#custom-theme\">Custom Default Theme<\/a><\/li>\n<li><a href=\"#custom-db\">Custom Database Tables<\/a><\/li>\n<li><a href=\"#revisions\">Revisions, Autosaves And Trash<\/a><\/li>\n<li><a href=\"#multisite\">WordPress Multisite<\/a><\/li>\n<li><a href=\"#developer\">Developer Settings<\/a><\/li>\n<li><a href=\"#memory\">Increasing The Memory Limit<\/a><\/li>\n<li><a href=\"#cron\">Cron Settings<\/a><\/li>\n<li><a href=\"#disable-table\">Disabling Table Updates<\/a><\/li>\n<li><a href=\"#ssl\">SSL In The Admin<\/a><\/li>\n<li><a href=\"#disable-updates\">Disable Automatic Updates<\/a><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h2 id=\"what-is\">What is the wp-config.php File?<\/h2>\n<p>According to the <a href=\"https:\/\/wordpress.org\/support\/article\/editing-wp-config-php\/\" target=\"_blank\">WordPress Codex<\/a>,\u00a0the config file is <q>One of the most important files in your WordPress installation.<\/q>\u00a0It file is located in your WordPress root directory and\u00a0contains important information such as database connection data (username, password, etc.) and various settings.<\/p>\n<p><em><code>wp-config.php<\/code><\/em> is actually not a part of the files that ship with WordPress. If you download the <a href=\"https:\/\/wordpress.org\/download\/\" target=\"_blank\">WordPress software<\/a>\u00a0you won&#8217;t find this file anywhere. Instead, you&#8217;ll find <em><code>wp-config-sample.php<\/code><\/em>.<\/p>\n<p>When you install WordPress you can rename this file to <em><code>wp-config.php<\/code><\/em> to set up your environment, or WordPress will create a final config file based on the information you give it during installation.<\/p>\n<h2 id=\"content\">The Default Config Content<\/h2>\n<p>You can take a look at the default content of your\u00a0config file by <a href=\"https:\/\/github.com\/WordPress\/WordPress\/blob\/master\/wp-config-sample.php\" target=\"_blank\">checking out this sample\u00a0at\u00a0GitHub<\/a>. This is the same <em><code>wp-config-sample.php<\/code><\/em> file you get in your own installations. The file is extremely well documented and I&#8217;ll explain some of the settings here nonetheless.<\/p>\n<p>Many settings in the config file use\u00a0<a href=\"http:\/\/php.net\/manual\/en\/language.constants.php\" target=\"_blank\">PHP constants<\/a>. As the PHP documentation states, a constant is an identifier for a simple value. The value can not be changed for the duration of the script. The general format of a constant is <em><code>define( 'CONSTANT_NAME', 'CONSTANT VALUE' )<\/code><\/em>.<\/p>\n<p>So let&#8217;s go through what all the code in the <em>wp-config.php<\/em> means.<\/p>\n<h3 id=\"db-configs\">Database Configuration<\/h3>\n<p>The first six settings are all about the database connection. WordPress stores posts and various other bits and pieces of data in a database; it needs access to said database to function. A database connection typically requires a host, a username, a password and a database name.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"db.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=db.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>The code above shows the constants without the inline documentation. The first four lines define the four settings I talked about previously. The charset and collation both have to do with languages and how specific characters are stored. UTF8 is a good choice because it contains special characters like &#8220;\u0151&#8221; for example. Collation determines how strings are compared in the database. Some collations may be case sensitive, others may be case sensitive for example. Unless you specifically know about these things it is best to leave these two settings alone.<\/p>\n<h3 id=\"salts\">Salts And Keys<\/h3>\n<p>The next eight settings are all used for securing WordPress. Authentication keys are used as security checks while salts are used when hashing passwords.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"auth.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=auth.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>You <strong>can<\/strong> fill these out yourself but there really is no need. You can use the <a href=\"https:\/\/api.wordpress.org\/secret-key\/1.1\/salt\/\" target=\"_blank\">secret key generation<\/a> utility to create these constants very quickly.<\/p>\n<p>I highly recommend reading <a href=\"http:\/\/codeseekah.com\/2012\/04\/09\/why-wordpress-authentication-unique-keys-and-salts-are-important\/\" target=\"_blank\">Why WordPress Authentication Unique Keys and Salts Are Important<\/a>\u00a0\u2013\u00a0it is a great read. As the article mentions, changing your keys and salts now and again is not a bad practice. Why not set a reminder every 90 days or so?<\/p>\n<h3 id=\"other-configs\">Other Config Settings<\/h3>\n<p>There are two more settings in there, the table prefix and the debug setting. The table prefix tells WordPress what prefix your database tables use. The default is <code><em>wp_<\/em>,<\/code> which would mean that your posts table is named <em><code>wp_posts<\/code><\/em>.<\/p>\n<p>One of the best ways to protect against attacks is to be unpredictable. It is a good idea to use default settings as little as possible, especially when they pertain to something as crucial as your database. If you&#8217;re just installing WordPress it&#8217;s a good idea to use an obscure prefix such as <em><code>Jbh8h3dD_oj3e_<\/code><\/em>. WordPress won&#8217;t mind that this is a lot more complex; to a script there is very little difference between <em><code>wp_postmeta<\/code><\/em> and <em><code>Jbh8h3dD_oj3e_postmeta<\/code><\/em>.<\/p>\n<p>The next setting is all about debugging WordPress. By default it is set to false, which means that error messages will be hidden. This is desirable behavior on production websites, but while coding or debugging you definitely want to see errors so you can fix them. If you ever activate a theme or a plugin and get a white screen you can at least figure out what the issue is by setting the <em><code>WP_DEBUG<\/code><\/em> constant to &#8220;True.&#8221;<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"other.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=other.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h2 id=\"customizing\">Customizing the wp-config\u00a0File<\/h2>\n<p>The config file is just like any other file, which means you can add any valid PHP to it. That being said, you should take care when editing <em><code>wp-config.php<\/code><\/em>. Only add to it when absolutely necessary and take care when editing because<em>\u00a0any incorrect edits you make could cause your website to stop functioning. <\/em>After all, this <em>is<\/em> the heart of WordPress we&#8217;re tinkering with!<\/p>\n<p>It&#8217;s a good idea to refer to the <a href=\"https:\/\/wordpress.org\/support\/article\/editing-wp-config-php\/\" target=\"_blank\">wp-config documentation in the WordPress Codex<\/a>\u00a0for all the official tweaks you can make to this file. All the additions I&#8217;ll be mentioning in this article\u00a0are safe to use if pasted correctly, but please be aware of what each of them does.<\/p>\n<p>There are some edits that you can make which have a place in the config file but are not a part of the documentation. One good example of this is the API access key and secret for your Amazon S3 server when using the <a href=\"https:\/\/wordpress.org\/plugins\/amazon-s3-and-cloudfront\/\" target=\"_blank\">Amazon S3 and Cloudfront<\/a> plugin. You could also use it to store your Google Fonts or Google Maps API key and other similar things.<\/p>\n<p>Do keep in mind though that this method is <em>not<\/em> for every single bit of data around. If you&#8217;re creating a plugin where the user needs to enter his\/her address it should be stored in the database.<\/p>\n<h3 id=\"urls\">1. WordPress URLs<\/h3>\n<p>There are two settings you can set in the config file which control WordPress URLs. One is the <em><code>WP_HOME<\/code><\/em> constant and the other is the <em><code>WP_SITEURL<\/code><\/em> constant. There is always some confusion about these, so let&#8217;s clear things up.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" width=\"590\" height=\"111\" class=\"size-full wp-image-134358\" src=\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/urls.png\" alt=\"WordPress URL boxes\" \/><\/p>\n<p>Both settings can be controlled from the WordPress settings section in the admin. The first setting in the screenshot, the WordPress address, corresponds to <code><em>WP_SITEURL<\/em><\/code>.The second setting, site address, corresponds to <em><code>WP_HOME<\/code><\/em>.<\/p>\n<p>When you use the config file to define these URLs, the settings given in the admin are overwritten and the config file takes precedence.<\/p>\n<p>The WordPress address, or <em><code>WP_SITEURL<\/code><\/em>, is the URL that users enter to visit your website. The site address or <em><code>WP_HOME<\/code><\/em> should point to the root of your WordPress install, which could be in a sub-directory.<\/p>\n<p>To learn more about the use and issues with these URLs I suggest reading <a href=\"https:\/\/toolset.com\/faq\/how-do-i-migrate-a-wordpress-site-from-one-domain-to-the-other\/\" target=\"_blank\">Using WP_SITEURL and WP_HOME to migrate a WordPress site<\/a>.<\/p>\n<h3 id=\"custom-dir\">2. Custom Directory Locations<\/h3>\n<p>The config file allows you to modify the location of various folders used by WordPress. You can move the content, plugins and uploads directories and create additional theme directories using the method outlined below. There are three reasons you may want to do this:<\/p>\n<ul>\n<li>Mimicking a folder structure following a site migration from another system<\/li>\n<li>Additional security based on not relying on the default structure<\/li>\n<li>Clearing up clutter from the root directory<\/li>\n<\/ul>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"folders.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=folders.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Note that different folders behave slightly differently. The <em><code>wp-content<\/code><\/em> folder requires an absolute path and a full URI to be given. The <em><code>plugins<\/code><\/em> directory is much the same, but for compatibility issues you may want to use the <em><code>PLUGINDIR<\/code><\/em> constant as well.<\/p>\n<p>Themes and uploads are a bit different. The default theme directory is hardcoded into WordPress, it is always set to the directory named <em><code>themes<\/code><\/em> inside the content directory. You can, however, add additional theme directories. In the code above I created a theme directory in the root folder.<\/p>\n<p>The uploads directory is always relative to the <em><code>ABSPATH<\/code><\/em> directory, which would be your root directory. In this case I have placed the directory in the root folder.<\/p>\n<p>Assuming WordPress is in a <em><code>wordpress<\/code><\/em> sub-directory the code above would result in the following folder structure:<\/p>\n<figure id=\"attachment_134359\" class=\"wp-caption aligncenter\" data-caption=\"true\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-134359\" src=\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/folders.png\" alt=\"WordPress folder structure\" width=\"347\" height=\"201\" \/><figcaption class=\"wp-caption-text\">Original WP folder structure on the left, custom structure on the right<\/figcaption><\/figure>\n<p>There is a special kind of plugin folder not many people know of called <em><code>mu-plugins<\/code><\/em>, short for &#8220;Must-use Plugins.&#8221; These plugins are loaded by default before any other plugins. To learn more about them read our post on <a href=\"https:\/\/wpmudev.com\/blog\/wordpress-mu-plugins\/\" target=\"_blank\" rel=\"noopener\">WordPress mu-plugins<\/a> or refer to the <a href=\"http:\/\/codex.wordpress.org\/Must_Use_Plugins\" target=\"_blank\">Must Use Plugins<\/a> documentation in the Codex. If you like the idea but want to change the location you can do so in a similar fashion to how we changed the plugin directory above.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"mu-plugin.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=mu-plugin.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h3 id=\"custom-theme\">3. Custom Default Theme<\/h3>\n<p>The default theme in WordPress is the most recent twenty-something theme. In WordPress 4.0 this would be Twenty Fourteen. If you would like a different fallback theme you can change the <em><code>WP_DEFAULT_THEME<\/code><\/em> to the folder name of your preferred theme.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"defaulttheme.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=defaulttheme.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>If you must change this I advise choosing a simple but very well-coded theme. If something goes wrong and your site&#8217;s theme is missing it will revert back to the default theme.<\/p>\n<h3 id=\"custom-db\">4. Custom Database Tables<\/h3>\n<p>WordPress has the ability to use a different table name for the users and usermeta tables. Using a custom table name could give you some additional protection although it is highly probably that if someone has access to your database they will figure this one out.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"usertables.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=usertables.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Before you make the change be sure to read up on <a href=\"https:\/\/wordpress.org\/support\/article\/editing-wp-config-php\/\" target=\"_blank\">changing user tables<\/a> to make the transition as smooth as possible.<\/p>\n<h3 id=\"revisions\">5. Revisions, Autosaves And Trash<\/h3>\n<p>I&#8217;m betting that many WordPress users don&#8217;t use the post <a href=\"https:\/\/wordpress.org\/support\/article\/revisions\/\" target=\"_blank\">revisions<\/a> feature. Even though it has been around since WordPress 2.6 it&#8217;s use is relegated to niche corners of the web. Luckily, WordPress allows you to limit or disable revisions easily using the <em><code>WP_POST_REVISIONS<\/code><\/em> constant.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"revisions.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=revisions.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Note that you should only use one or the other, I&#8217;ve just placed both in one example for easy reference.<\/p>\n<p>The use of autosaves are more widespread but these may happen a bit more frequently than you need them to. By default WordPress saves your post every 60 seconds. If you create content by copy-pasting it, or you&#8217;re not worried about loosing a minute&#8217;s worth of work you could increase the autosave time.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"autosave.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=autosave.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>The trash is another source of clutter which can be controlled easily. By setting the <em><code>EMPTY_TRASH_DAYS<\/code><\/em> constant you can control how many days a post stays in trash before it is completely deleted. You may also set this to 0 to disable the trash altogether.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"trash.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=trash.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h3 id=\"multisite\">6. WordPress Multisite<\/h3>\n<p>The config file is the starting place for creating a multisite install. The <a href=\"https:\/\/wordpress.org\/support\/article\/create-a-network\/\" target=\"_blank\">Create a Network<\/a> page in the Codex sums up what a Multisite installation actually is:<\/p>\n<blockquote><p>A multisite network is a collection of sites that all share the same WordPress installation. They can also share plugins and themes. The individual sites in the network are virtual sites in the sense that they do not have their own directories on your server, although they do have separate directories for media uploads within the shared installation, and they do have separate tables in the database.<\/p><\/blockquote>\n<p>Multisite allows you to create separate sites based on the same WordPress install. This allows you to manage a multitude of sites very easily. Multisite is commonly used for corporate websites where the shop, blog and company site may be separate. It could also be used to host websites for a community of bloggers. Developers use it to host multiple themes and plugins.<\/p>\n<p>To get started you&#8217;ll need to define a single constant:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"multisite.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=multisite.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Once defined, reload the WordPress admin and you should see a &#8220;Network Setup&#8221; option in the &#8220;Tools&#8221; section. Follow the instructions outlined there. WordPress will ask you to add additional settings to your config file as well as your .htaccess file. Once done you should be logged out and when you log back in you&#8217;ll have a nice new network install. Refer to the <a href=\"https:\/\/wordpress.org\/support\/article\/create-a-network\/\" target=\"_blank\">Create A Network<\/a> page for a more complete setup guide.<\/p>\n<p>A setting related to Multisite installs allow you to redirect users when someone accesses a sub-site, which does not exist. The <em><code>NOBLOGREDIRECT<\/code><\/em> constant defines the URL users are directed to in these cases.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"redirect.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=redirect.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Especially when working with Multisite installations you may want to make sure that plugins and themes cannot be edited using the built-in file editor, you may even want to make sure users can&#8217;t install their own plugins and themes. This can be achieved with the <em><code>DISALLOW_FILE_EDIT<\/code><\/em> and <em><code>DISALLOW_FILE_MODS<\/code><\/em> constant.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"filemods.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=filemods.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Note that if you define <em><code>DISALLOW_FILE_MODS<\/code><\/em> as true you don&#8217;t need to define <em><code>DISALLOW_FILE_EDIT<\/code><\/em> since this will be disabled as well.<\/p>\n<h3 id=\"developer\">7. Developer Settings<\/h3>\n<p>The config file has a number of settings which help developers catch errors or write better code. The most prominent of these is the <em><code>WP_DEBUG<\/code><\/em> constant, which we&#8217;ve already look at. Defining this as &#8220;True&#8221; will force errors to be displayed.<\/p>\n<p>In addition you can make sure that the full and unmodified CSS and Javascript files are served on a page load:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"scripts.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=scripts.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>By default, scripts are concatenated and minified. Concatenation is the process of joining files. Instead of loading 20 scripts individually WordPress concatenates them into one file and loads that. Minification is the process of compressing a file into a format which is non human-readable but computers work just fine with it. These two methods save considerable loading time and server resources.<\/p>\n<p>That said, it is next to impossible to figure out a JavaScript or CSS issue if the code is concatenated and minified. Using the two constants above to disable these features is necessary if you need to hunt down a script issue.<\/p>\n<p>Debugging often relies on log files, especially if errors are not shown. Many errors only occur in specific circumstances so as a developer we don&#8217;t always encounter them. This is where logging comes in handy. Instead of displaying error messages we can log them to a file and look over them every now and again. This can be done by defining\u00a0<code><em>WP_DEBUG_LOG:<\/em><\/code><\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"debug.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=debug.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>When enabled the errors encountered will be logged to a file named <em><code>error.log<\/code><\/em> in the <em><code>wp-content<\/code><\/em> folder.<\/p>\n<p>For the hardcore optimizers among us, the <em><code>SAVEQUERIES<\/code><\/em> constant is a life-saver. By defining this constant to be true we can access detailed profiles of the SQL queries performed by WordPress:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"savequeries.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=savequeries.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>Once defined we can print the content of <em><code>$wpdb-&gt;queries<\/code><\/em> to get an overview of all the queries.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"queries.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=queries.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>If you&#8217;re feeling particularly fancy or you need to look at these queries all the time you can hook this into <em><code>wp_footer<\/code><\/em> to make sure they are always displayed at the end of each page.<\/p>\n<h3 id=\"memory\">8. Increasing The Memory Limit<\/h3>\n<p>In some rare cases you may need to manually allot more memory to WordPress. While I have encountered situations where PHP ran out of memory while running WordPress, these were all caused by wasteful themes or plugins.<\/p>\n<p>If you need to you can set the memory limit with the <em><code>WP_MEMORY_LIMIT<\/code><\/em> constant and the <em><code>WP_MAX_MEMORY_LIMIT<\/code><\/em> constant, which controls the amount of memory available for the admin.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"memory.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=memory.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h3 id=\"cron\">9. Cron Settings<\/h3>\n<p>Cron is a time-based job scheduler in Unix-like environments. WordPress has a cron feature, which is not a real cron but copies its features closely. WordPress cronjobs run at regular intervals and perform various tasks. For example, the cron system is responsible for publishing posts at the correct time.<\/p>\n<p>The drawback of the system is that it relies on site visitors to perform cronjobs so the task may not run at the exact given time. If you set a real cron on your server to run at 1am every night it will do so with extreme precision.<\/p>\n<p>WordPress crons are triggered by visitors loading the site. This means that if you use WP cron to initiate an action at 1am it will be run the first time the website is loaded after that time. If you don&#8217;t have any visitors until 11am, the task will be completed then.<\/p>\n<p>In most cases this is not a problem. If you&#8217;ve set a post to be published at 1am and noone visits the site until 11am the post will be published before the site loads for the user, for all intents and purposes, the post was published on time.<\/p>\n<p>In some cases the cron system may throw a fit and refuse to work properly. I have never personally encountered this, but if you see this happening you can try using an\u00a0alternative cron method:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"alt-cron.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=alt-cron.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p>The config file also allows you to disable the cron altogether and to limit the repeat interval between the same cronjob.<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"cron.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=cron.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h3 id=\"disable-table\">10. Disabling Table Updates<\/h3>\n<p>When WordPress is updated it may run a <code>dbDelta()<\/code> function, the purpose of which is to modify your database to conform to the latest specifications. This usually poses no threat at all but for sites with huge tables (especially username tables) this may take a while to complete.<\/p>\n<p>Many large sites prefer to take care of these operations themselves, or perhaps schedule them for a time when there is little traffic. This can be done by disabling the upgrading of global tables:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"disabledbupdate.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=disabledbupdate.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h3 id=\"ssl\">11. SSL In The Admin<\/h3>\n<p>There are two options in the <em><code>wp-config.php<\/code><\/em> file which allow you to use SSL. <em><code>FORCE_SSL_LOGIN<\/code><\/em> makes sure that logins always use SSL, but the admin sessions themselves don&#8217;t. This adds some protection while making sure SSL doesn&#8217;t slow down the admin process.<\/p>\n<p>You can also use <em><code>FORCE_SSL_ADMIN<\/code><\/em>, which will use SSL for login and throughout the admin session, including the cookies:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"ssl.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=ssl.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<p><em><code>FORCE_SSL_ADMIN<\/code><\/em> supersedes <em><code>FORCE_SSL_LOGIN,<\/code><\/em> so if you&#8217;re using the more secure option there&#8217;s no need to define <em><code>FORCE_SSL_LOGIN<\/code><\/em>.<\/p>\n<p>Depending on your server setup there may be a bit more you need to do to access your site via SSL. I suggest reading the excellent <a href=\"https:\/\/wordpress.org\/support\/article\/administration-over-ssl\/\" target=\"_blank\">Administration Over SSL<\/a> guide in the Codex.<\/p>\n<h3 id=\"disable-updates\">12. Disable Automatic Updates<\/h3>\n<p>I personally enjoy automatic updates because they make my website safer and ensure I&#8217;m always running the latest version of WordPress. Being always up-to-date is a good thing and there are very few legitimate cases where not updating is a good idea. Modifying WordPress core files, a downloaded theme or plugin is <em>never<\/em> one of them.<\/p>\n<p>If you need to disable updates for any reason, WordPress gives you two constants to do so. <em><code> AUTOMATIC_UPDATER_DISABLED<\/code><\/em> can disable all automatic updates in one go. A better way to do this is to use the <em><code>WP_AUTO_UPDATE_CORE<\/code><\/em> constant.<\/p>\n<p>This can be set to &#8220;True&#8221;\u00a0to enable updates and &#8220;False&#8221;\u00a0to disable them. In addition, you can set it to &#8220;Minor&#8221;\u00a0(this is the default) to grab minor updates by default:<\/p>\n<div class=\"gist\" data-gist=\"d3eee86104b3c58d0dd0\" data-gist-file=\"updates.php\"><a class=\"loading\" href=\"https:\/\/gist.github.com\/d3eee86104b3c58d0dd0.js?file=updates.php\">Loading gist d3eee86104b3c58d0dd0<\/a><div class=\"gist-consent-notice\" style=\"display:none\"><p>Please <a href=\"javascript:Cookiebot.renew()\">update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n<h2>Conclusion<\/h2>\n<p>As you can see, the WordPress configuration file offers plenty of opportunities to tweak your site and make it your own. From modifying directory locations to logging in via SSL, a lot is possible.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The WordPress configuration file, also known as wp-config.php, is most frequently used to set up a\u00a0database connection and is then forgotten. Despite its neglected nature, it is a powerhouse of features and opportunities for optimization. While you don&#8217;t typically use\u00a0the config file on a day-to-day basis, I&#8217;m betting that almost every WordPress install could benefit [&hellip;]<\/p>\n","protected":false},"author":344049,"featured_media":152147,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"blog_reading_time":"","wds_primary_category":0,"wds_primary_tutorials_categories":0,"footnotes":""},"categories":[263],"tags":[],"tutorials_categories":[],"class_list":["post-134345","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials"],"_links":{"self":[{"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/posts\/134345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/users\/344049"}],"replies":[{"embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/comments?post=134345"}],"version-history":[{"count":11,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/posts\/134345\/revisions"}],"predecessor-version":[{"id":222844,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/posts\/134345\/revisions\/222844"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/media\/152147"}],"wp:attachment":[{"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/media?parent=134345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/categories?post=134345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/tags?post=134345"},{"taxonomy":"tutorials_categories","embeddable":true,"href":"https:\/\/wpmudev.com\/blog\/wp-json\/wp\/v2\/tutorials_categories?post=134345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}