Useful WordPress Configuration Tricks That You May Not Know

If functions.php is the single most important file in your WordPress theme, then wp-config.php is the single most important file in your entire WordPress installation. This file can be used to configure database functionalities, enhance performance, and improve security on all WordPress powered websites and blogs. In this article, we will share some of the most useful WordPress configuration tricks that you may not know yet.

By default, WordPress installation does not come with a file wp-config.php. The default install comes with a sample file known as wp-config-sample.php. You must use this file as a sample to create the actual wp-config.php before you can setup your blog. Most users never do this manually because WordPress lets you do it automatically from their installation setup. In that setup, you are adding/modifying key WordPress configurations. So first, we will walk you through what the default setup lets you do.

When you upload WordPress via FTP and access the site, you see a screen like this:

The setup basically tells you to use the wp-config-sample.php because it may not work on all hosts. Most of which we tried it with, it works. If you are using one of the popular hosts, then it will work. The next step would be something like this:

There you enter some of the key information. The info there lets WordPress connect with a database. Anything you enter in the setup will be added in your wp-config.php as:

Paste the code above, and it will most likely grab the database server. For this, you would have to manually edit the wp-config.php file though.

Security Keys

WordPress Security Keys is a set of random variables that improve encryption of information stored in the user’s cookies. Prior to WordPress 3.0, you had to install this in your wp-config.php file manually. In WordPress 3.0 if you use the install wizard, then it automatically adds the security keys in your wp-config.php. Also prior to WordPress 3.0, there were only 4 security keys, but with 3.0 there are 8 security keys available.

Database Prefix

When you are installing WordPress using the wizard, one of the options is to select the Table prefix. That is stored in wp-config.php file as:

$table_prefix = 'wp_';

We recommend that you use something other than wp_ to add extra work for the hackers. Although if you already have WordPress setup, then don’t just change the prefix like this. There is a set of steps here that you should take.

Language Configuration

By default, English is the localized language of WordPress, but it can be changed to your native language with these:

define('WPLANG', '');
define('LANGDIR', '');

The language translation file (.mo) must be placed in the default location which is assumed to be wp-content/languages (first) and then wp-includes/languages (second). As you can see in the function above, you can define your own language directory if you like. To find WordPress in your language, please check out the official WordPress Codex page.

Debugging WordPress

For developers, WordPress has this awesome debugging feature which allows them to find errors, and deprecated functions. By default, this function is set to false, but in the development mode, developers should have it enabled.

Blog/Site Address

In your WordPress Settings, you specify the WordPress address and the site address. Those are added in your database, and every time the developer calls it in the template, it is running a database query. In WordPress 2.2, these two settings were introduced to override the database values without changing them:

By adding these in your wp-config.php, you are reducing the number of database queries thus increasing your site’s performance.

Override File Permissions

You can override file permissions, if your host has restrictive permissions for all user files. Most of you do not need this, but it exists for those who need it.

define('FS_CHMOD_FILE', 0644);
define('FS_CHMOD_DIR', 0755);

Post Revisions

In the recent versions of WordPress, there is a super awesome feature called Post Revisions. This function auto-saves posts just incase if your browser crash, or something else happen. It also allows users to restore back to previous versions if they don’t like the changes and so on. While a lot of us love this feature, some of us really hate it with a passion. This function has numerous configuration, so you can make it work just right for you.

The Auto-Save Configuration

By default WordPress saves post every 60 seconds, but if you think that is way too much, then you can modify it to your likings with this configuration:

define('AUTOSAVE_INTERVAL', 120); // in seconds

Some posts have 10s, 20s, or even 100 post revisions depending on the blog owner. If you think that feature annoys you, then you can limit the number of revisions per post.

define('WP_POST_REVISIONS', 5);

You can use any integer you like there.

If none of the settings above satisfies you, then you can simply disable the post revisions feature by adding this function:

define('WP_POST_REVISIONS', false);

WordPress Trash Feature

In WordPress 2.9, there was a new “Trash” feature added to the core. This feature works just like the recycling bin, so instead of deleting the post permanently, you would send it to the trash. This helped those users who accidently click on Delete button, and it can be any of us. The bad part about this trash feature is that you have to empty the trash regularly. By default the trash empties itself every 30 days. You can modify that by using the following function:

define('EMPTY_TRASH_DAYS', 7 ); //Integer is the amount of days

If you do not like this feature, then you can disable it by adding the function below:

define('EMPTY_TRASH_DAYS', 0 );

But remember, if you keep the value to 0, then WordPress would not ask for confirmation when you click on Delete Permanently. Any accidental click could cost you…

FTP/SSH Constants

By default, WordPress allow you to upgrade plugins, and WordPress core versions from within the backend. There are some hosts that requires an FTP or SSH connection everytime you try to upgrade, or install a new plugin. By using the codes below, you can set the FTP or SSH constants and never have to worry about it again.

Auto Database Optimization

In WordPress 2.9, there was a feature added called Automatic Database Optimization. To enable this feature, you would need to use the following function:

define('WP_ALLOW_REPAIR', true);

Once activated, you can see the settings on this page: http://www.yoursite.com/wp-admin/maint/repair.php

The user does not need to be logged in to access this functionality when this define is set. This is because its main intent is to repair a corrupted database, Users can often not login when the database is corrupt. So once you are done repairing and optimizing your database, make sure to remove this from your wp-config.php.

Increase PHP Memory Limit

There is a common WordPress Memory Exhausted Error that users have seen when activating some plugin. You can increase the PHP Memory Limit through wp-config.php file. Simply paste the code below:

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

Note: This feature may not work with some web hosts, so you would have to ask them (beg them) to increase your PHP Memory limit.

WordPress Error Log

For developers, it is useful to have an error log for a site. You can easily create a simple error log for a WordPress powered website by using wp-config.php file. First create a file called “php_error.log”, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code:

Enable Multi-Site Network

In WordPress 3.0, WPMU was merged into WordPress core. To enable the multi-site network functionality, you have to add the following code in your wp-config.php file.

define('WP_ALLOW_MULTISITE', true);

Once you add this code, there will be a new page in your wp-admin called “Network” located in Tools » Network.

You will have to follow the directions on that page to continue the setup of the MU Network.

Securing Your WP-Config File

As you can see, this file is SUPER IMPORTANT therefore it needs extra security. By default it is located in the root WordPress folder, but you can move it. It can be moved outside your public_html directory, so users cannot access it. WordPress knows by default to look in other directories, if the files is not found in the WordPress root folder. You can also use .htaccess file to limit access to this file.

41 Comments

I’m wresting with one thing setting up my own CDN (which the above took care of 98%:).

I’m trying to exclude a sub-folder on my CDN sub-domain as it’s throwing an access violation.

I’ve tried a half dozen NGINX CORS directives in a server block .conf with no joy.

I want to figure out how to use this file in the main domain rather than how it’s written below:

Access to Font at ‘https://cdn.mydomain.com/wp-content/themes/mytheme/includes/lib/assets/fonts/fontawesome/fontawesome-webfont.woff?v=4.7.0’ from origin ‘https://mydomain.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://mydomain.com’ is therefore not allowed access.

I use useronline plugin…When am in the useronline dashboard I notice that some users want to access my default css, upload images link with their browser! So am scared may be they want to hack my site! Please any help on how to stop them

I’m currently using DesktopServer (Xampp lite – Installs sites with .dev extension locally eg. “mysite.dev”) with SourceTree (Git) – However trying to figure out what the path I should be using to my error log file is proving difficult. Could I use a full URL path such as “http://mysite.dev/php_error.log” ? or does it need to be the system file path “C:/Users/Garratt/Documents/mysite.dev/php_error.log” ?

Got a question: How do I transfer ownership of a site from one user to another? Like I set it up with my admin account, but I want to have another user be the main admin and do updates and posts. I doubt I can just set them as an admin and myself as a subscriber and be done with it, so what’s the correct route of doing so?

Yes that’s one way to do it. A WordPress site can also have multiple administrators.

If you also want to transfer them the ownership of domain, web hosting, and database then you will have to create a user account for them in your web hosting control panel. After that you can give them the complete control on domain, hosting, and database as well.

They already have all that, I’m just helping them redevelop their website (cause it’s not a good look right now nor is it easy to update ATM). Found this awesome church theme for them (cause it’s my church’s website I’m working on), and wanted to see how difficult it would be to switch admins. Last time a site of mine had multiple admins, just the first admin (ID #1) could update the plugins, themes, and WP in general.

Thanks for this useful tips.I!m a beginner and I have a wordpress.org web site.
I have followed your instructions and changed the wp-config file by copying the secure keys grabbed from the web site: https://api.wordpress.org/secret-key/1.1/salt/
After putting the new config file into the WP-Admin Folder in the server it gives an error “Parse error: syntax error, unexpected T_VARIABLE….”
That line is: “$table_prefix = ‘wp_’;” and it has never been changed.
How can I correct this error? Thanks.

Great information about such an important are as configuration. With all the pharma hacks going on recently the last tip is my favourite. Protecting that damn wp-config file seems to be the key to palace these days.

Thank you for the effort putting all of this information in one place for us all to benefit.

You will never move the .htaccess file anywhere. That file remains in your public_html folder or the folder where WordPress is installed… The code in that file will disallow all access to wp-config.php file from the web.

You can move the wp-config.php file to the root directory (one above public_html) to add an extra layer of security. One or the other would be fine… doing both is an overkill.

For reference, 3.0 does not include more security keys, nor were 2.9 installs any less secure when it came to authentication.

The first four are keys. The last four are salts. The salts were missing from wp-config.php before 3.0, but we actually added salts a few versions ago. We added them to wp-config.php in 3.0 so we could easily populate them on install, but they are not necessary.

If salts are not defined (or remain the default, e.g. “Enter unique phrase here”), then WP simply generates random strings to use as salts and stores those in the database.

$_ENV{DATABASE_SERVER} ??
Syntax doesn’t look correct to me ($_ENV[‘stuff’] maybe but {stuff} I don’t think so) and I’ve just checked, couldn’t find any host I have access to that has this defined. Definitely not something common.

Other than this, nice roundup. Note that WP doesn’t look “in other directories” to find wp-config.php, it just goes one directory up (which is in most case out of the server document root).

Thanks for choosing to leave a comment. Please keep in mind that all comments are moderated according to our comment policy, and your email address will NOT be published. Please Do NOT use keywords in the name field. Let's have a personal and meaningful conversation.

Notify me of followup comments via e-mail. You can also subscribe without commenting.

WPBeginner is a free WordPress resource site for Beginners. WPBeginner was founded in July 2009 by Syed Balkhi. The main goal of this site is to provide quality tips, tricks, hacks, and other WordPress resources that allows WordPress beginners to improve their site(s).