10 wp-config.php Hacks Every Developer Should Know
Most of the WordPress users never open wp-config file, unless they want to enable multisite feature or debugging while developing. Making minor changes in this file can power up your WordPress site with enhanced performance and improved security.
As the name explains, wp-config is the file that lets you configure all the important settings that you require to access your MySQL database. It represents how your site is structured and how it functions. As this file doesn’t exist in the download copy of WordPress, you’re required to create it.
In this tutorial, we’ll show you 10 wp-config tweaks that you may not know yet.
Let’s go through them one by one.
Move Your Configurations File:
Moving wp-config outside the web root directory is one of the best security practices. Doing so keeps your important information, like your authentication keys and database login details, away from malicious scripts and hackers who can try to access your site’s database using default location of wp-config file.
Generally, WordPress looks for wp-config file in its web root. If it’s not available there, then it will automatically look one level above. So, just move this file one folder above the web-root folder. In this way, nobody will be able to access it without SSH or FTP access.
If you’re moving your wp-config file, it is recommended to create another wp-config file in the root folder that will point to the “real” wp-config.
define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . '../path/to/wp-config.php');
For a better security, you can also use the .htaccess file to deny public access to it. To do so, put the following code at the top of this file.
order allow,deny deny from all
Change the WordPress Content Directory Location:
After moving your wp-config file, you’ll find some other interesting things to do. For instance, you can easily put WordPress itself under version control to keep your WordPress database up-to-date using the git mirror or SVN repository. As your themes, plugins and uploads folders are now inside the SVN or git repository, you may face some problems. So it’s essential to change the wp-content folder’s default location.
To move the WordPress content folder, install WordPress in a sub-directory of your web root folder. Then create a new wp-content folder in the web root that have directories for plugins, themes and uploads folders. You can also put these folders separately under version control.
Now point the WP_CONTENT_DIR and WP_CONTENT_URL constants to your new WordPress directory using the following code:
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . 'path/to/wp-content' ); define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wp-content' );
WordPress will use this new wp-content folder instead of one that resides in WordPress directory.
It means that you can’t access your default themes now. The most efficient solution to this problem is to register the real wp-content folder through register_theme_directory() or move themes to the new wp-content folder manually.
Move the WordPress Plugin Directory:
To avoid compatibility issues with properly coded plugins, set both the WP_PLUGIN_DIR and WP_PLUGIN_URL constant pointing to the new plugin directory. You can either hardcode the URL of your site or use $_SERVER[‘HTTP_HOST’].
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/path/to/plugins' ); define( 'WP_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/plugins' );
Here WP_PLUGIN_URL is the URL of the location of the directory and WP_PLUGIN_DIR is the path to the location of the wp-config file.
Relocate the Mu-Plugins Directory:
Must use plugins, also known as “mu-plugins”, are the plugins that cannot be disable and runs automatically. WordPress automatically looks for “mu-plugins” directory that resides in the WordPress content folder to load these plugins. You can move the Mu-Plugins Directory using the same method we’ve used above for defining WP_PLUGIN_URL.
define( 'WPMU_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/mu-plugins' );
Or hardcode the URL:
{code type=php}define( 'WPMU_PLUGIN_URL', 'http://example.com/path/to/mu-plugins' );
Change the Default Theme:
For WordPress 3.6 and above, the default theme is Twenty Thirteen. Changing your default theme to your favorite theme is quite beneficial, if you’re going to create a large WordPress multisite network where you want to use the same theme for all of your sites. Setting your default theme to your preferable theme will help you avoid changing theme for your each site manually.
You can set your favorite theme as default by defining WP_DEFAULT_THEME to slug of that theme. For instance, if you want to set the default theme to Twenty Eleven:
define('WP_DEFAULT_THEME', 'twentyeleven');
While changing your default theme to another theme, keep in mind that it may remove the safety of falling back on Twenty Thirteen theme when your current theme is not available.
Disable the Theme and Plugin Editors:
If you want to protect your plugin or theme files from editing by a non-geek client, you can turn off both editors using DISALLOW_FILE_EDIT as shown below:
define('DISALLOW_FILE_EDIT', true);
In addition, you can also prevent unauthorized users from updating and installing themes and plugins, and updating WordPress via admin panel.
define('DISALLOW_FILE_MODS', true);
Set the Akismet Key Once For a Multisite Network:
One annoying thing about Akismet is that when you use it for a multisite network, you’ve to set the API key separately for your every site. Using this tweak, you can set your Akismet key one time in the wp-config file and move on. It will be used for all Akismet activated sites in your network. Just add the following line of code:
define('WPCOM_API_KEY','your-key');
Don’t forget to replace ‘your-key’ with your real Akismet key.
Set or Disable the Number of Post Revisions:
As WordPress keeps a record of all the changes that you make to the content of a post, it can create a number of useless files in your MySQL database. To prevent extra entries, you can set the maximum number of revisions to keep. To limit the number of post revisions, set the WP_POST_REVISIONS constant to a number. For example, to set 5 revisions per post you should use:
define('WP_POST_REVISIONS', 5);
Additionally, you can disable all the revisions except “autosave” by setting the WP_POST_REVISIONS constant to false, as shown below:
define('WP_POST_REVISIONS', false);
Force SSL Login and SSL Admin Access:
To prevent your username and passwords from being intercepted, you can secure your wp-login by enabling SSL login on your website. In order to use this great security tweak, you must have SSL support for your website.
Set FORCE_SSL_LOGIN to true, if you want to secure logins and prevent passwords from being sent in the clear.
define('FORCE_SSL_LOGIN', true);
Furthermore, the most secure option is to set the FORCE_SSL_ADMIN constant to true. This way all the interaction with your WordPress Backend will occur via a secure connection, as it will secure both logins and admin area by preventing both passwords and cookies from being intercepted.
define('FORCE_SSL_ADMIN', true);
Change WP_DEBUG Behavior:
While in development, one of the most common changes that developers make to wp-config file is to enable debugging. It is quite useful while developing or developing to display error messages at the top of the screen, but it should be turned off when your site is live. So it can stop your site from displaying potential errors to the world through which potential hackers can easily access your content directory.
You can turn off debugging by setting WP_DEBUG_DISPLAY constant to false.
define('WP_DEBUG_DISPLAY', false);
After disabling debugging, you can still see all the error messages in a file called “debug.log” that resides in your content directory (Be sure the WP_DEBUG_LOG is set to true).
If you know any other interesting change that can improve a WordPress site, please share that in the comment section given below.
