10 wp-config Tweaks To Improve Your WordPress Site
Many WordPress users never open their site’s configurations file, wp-config.php, unless they need to enable multisite or enable debugging. The wp-config file is the blueprint for how your site functions and how it is structured. Just like when building anything else, a little extra planning for your WordPress site makes a big difference in the long run.
In this tutorial I am going to show you 10 quick edits you can make to your wp-config file to make your site more secure and make your life easier.
I will cover how to change the default theme, disable the theme and plugin editor, rearrange the directory structure of your site and more.
Getting Started With wp-config
In each of the tweaks you’ll be learning we’ll be setting WordPress constants. In PHP, a constant is a simple identifier that stands in for a value, which can be defined programmatically. Constants must remain constant and cannot change while a script is being executed.
Constants must begin with a letter or an underscore and by convention are capitalized. Constants are defined with the define() function which is a very simple function with two arguments. The first is the name of the constant and the second is the value. Together it looks like this:
WordPress defines many helpful constants in various locations, though most of the ones we will be working with are defined in wp-includes/default-constants.php. When WordPress sets the value of WP_DEBUG to false, the default behavior, it first checks to see if it is already defined, like this:
if ( !defined('WP_DEBUG') ) define( 'WP_DEBUG', false );
Because wp-config is loaded before any WordPress core file, you can override the value set in core by simply defining your own value. If you set WP_DEBUG to true in wp-config, when the default definition of it is reached when default-constants is executed, the definition in that will be skipped because !defined(‘WP_DEBUG’) will return false, thus overriding the default setting of false.
Move the Configurations File
Moving wp-config out of the WordPress root directory is considered by many, but not everyone to be an important security step. Proponents of moving wp-config argue that it keeps the sensitive information, including your database login details and authentication keys, away from malware and other nefarious scripts looking to gain access to your site that expect wp-config to be in its default location.
WordPress will automatically look one level above the location of the directory WordPress itself is installed in. This means if WordPress is installed in your server’s web root you can move wp-config up one level to a less easily accessed location.
If you move your wp-config elsewhere you can create a second wp-config file in the root directory pointing to the “real” wp-config.
define('ABSPATH', dirname(__FILE__) . '/'); require_once(ABSPATH . '../path/to/wp-config.php');
Change The WordPress Content Directory Location
Once you have your wp-config file a level above your WordPress install, it also opens up several interesting options to you. For example, you can now easily put WordPress itself under version control using the SVN repository or the git mirror. This will allow you to keep WordPress up-to-date with the latest changes. It also can save your backside if you violate the “Thou shalt not hack core” commandment.
One problem you will run into with this setup is your plugins, themes and uploads directories are now inside the SVN or git repository. This is one of the many reasons you would want to move your wp-content directory from its default location.
One efficient solution is to install WordPress in a subfolder of your server’s root web directory and then in the web root add a new wp-content folder with directories inside for themes, plugins and uploads folders.
You can put any of these directories under version control separately if you want to. In order for WordPress to use your new WordPress directory, you can just need to point the WP_CONTENT_DIR and WP_CONTENT_URL constants to it:
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . 'path/to/wp-content' ); define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wp-content' );
This new, more easily accessible wp-content folder will be used instead of the one in the WordPress directory. This will mean you will lose access to the default themes.
You can either manually move them to the new content directory or you can register the original wp-content folder using register_theme_directory().
In case you are wondering, you can change the name of wp-content to whatever you want. Doing so is especially useful if you have several local development servers running on your computer. If you do it will make searching for a particular site’s content directory much easier. In fact you can use the same method to rename wp-content without moving it.
Do keep in mind that moving or renaming wp-content may break certain poorly written plugins or themes that have hardcoded the plugin or theme directories instead of doing it the right way. Don’t let this stop you moving or renaming wp-content as you probably shouldn’t trust any plugin or theme that doesn’t define their directory location properly using constants.
Move the WordPress Plugin Directory
So far we have assumed your plugin directory will be staying inside the content directory, but it doesn’t have to.
To ensure maximum compatibility with properly coded plugins, be sure to set both the WP_PLUGIN_DIR and WP_PLUGIN_URL constant.
WP_PLUGIN_DIR is the path relative to wp-config’s location and WP_PLUGIN_URL is the full URL, http:// and all, of the directory’s location.
You can either hardcode your site’s address, or use $_SERVER[‘HTTP_HOST’] to set it programatically.
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/path/to/plugins' ); define( 'WP_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/plugins' );
Relocate the Mu-Plugins Directory
Must use plugins, aka “mu-plugins,” are plugins that run automatically on your site and cannot be disabled.
By default, WordPress will look for a directory called “mu-plugins” in the content directory to load mu-plugins from. You can change the directory for mu-plugins by defining WPMU_PLUGIN_URL, using the full URL of your custom mu-plugins folder, with a similar method to how WP_PLUGIN_URL was defined:
Getting the URL using PHP:
define( 'WPMU_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/mu-plugins' );
Or hardcode the URL:
define( 'WPMU_PLUGIN_URL', 'http://example.com/path/to/mu-plugins' );
You can also use this same method to rename the mu-plugins directory. If you want to keep it in the same location, but just rename it, you would set WPMU_PLUGIN_URL relative to WP_CONTENT_URL like this:
define( 'WPMU_PLUGIN_URL', WP_CONTENT_URL . '/new-name' );
Change the Default Theme
Since WordPress 3.6, the default theme for WordPress is Twenty Thirteen. There are several reasons why you might want to change the default theme. For example, you prefer Twenty Twelve or you may also be creating a large WordPress multisite network where all or most of the sites will use the same theme.
Setting the default theme to that theme will save you a lot of repetitive work. Whichever theme you decide to set as your default, you set it by defining WP_DEFAULT_THEME to be that theme’s slug. For example, if you want to change the default theme back to Twenty Twelve:
Keep in mind that the default theme is used as a safety fallback if the current theme is missing. Changing the default theme to another theme may remove the safety of falling back on the trusty WordPress Twenty-Something theme that you know will work.
Disable the Theme and Plugin Editors
The theme and plugin editors in the WordPress backend can be very helpful tools but they can also be a recipe for disaster. If you use either to create a fatal error, the only way to fix this type of calamity is to delete the plugin or theme file from the server via FTP or SSH.
To protect yourself from making this type of tragic mistake, or to prevent your client from doing any unwanted “improvements” to a site you built for them, you can disable both editors with DISALLOW_FILE_EDIT.
You can even take this one step further by setting DISALLOW_FILE_MODS to true to prevent not only the editing of themes and plugins but also the updating and installing plugins and themes, as well as updates to WordPress from being done via the WordPress admin area.
Set the Akismet Key Once For a Multisite Network
Akismet is a great anti-spam tool that recently passed the 100 billion spams blocked milestone. One annoying thing about it that you might have experienced is that whenever you are using it with a multisite network you need to set your API key separately for every single site. That is if you are doing it via the WordPress backend instead of setting it once in wp-config and moving on.
All you need to do is add one line to wp-config:
Be sure to replace “your-key” with your actual Akismet key and it will be used for every site in your multisite network that has Akismet activated.
Disable Post Revisions or Set the Number of Revisions to Keep
By default, WordPress keeps a record of every change you make to a post’s content, excerpt, author, and title. While this can be a lifesaver, if you save a lot of drafts this can create a lot of extra entries in your database.
You can limit the number of revisions to keep by setting the WP_POST_REVISIONS constant to a number. For example, to save 10 revisions you would use:
Of course, if you want to disable all revisions except the autosave, you can always set the WP_POST_REVISIONS constant to false, like this:
Force SSL Login
In order to prevent username and passwords from being intercepted when they are submitted by users while logging in to WordPress, you can require that wp-login can only be accessed via a secure connection.
Of course, you will need to have SSL support for your site to use this option, which is enabled with FORCE_SSL_LOGIN.
You can take this one step further by requiring all interaction with the WordPress backend, including login, to occur via a secure connection by setting the FORCE_SSL_ADMIN constant to true.
Customize WP_DEBUG Behavior
Enabling debugging with the WP_DEBUG constant is one of the most common changes made to wp-config.
There are some other changes you can make in wp-config to change the behavior of WordPress debugging mode. By default WP_DEBUG prints all error messages at the top of the screen. If you would like to suppress this behavior you can set WP_DEBUG_DISPLAY to false.
This will not prevent fatal errors from causing a white screen of death. It will, however, stop your site from broadcasting non-fatal error messages to the world, which not only looks bad, but will usually expose the absolute directory path for your content directory to the world.
You can still see the errors in the error log, unless of course you set WP_DEBUG_LOG to false. When WP_DEBUG_LOG is set to true all debug messages will be logged to a file in your content directory called “debug.log”.