.. Your Daily Design Dosis

wp-config.php snippets for better Security and Performance


If you’ve installed a WordPress Theme before you’re familiar with the wp-config.php file, located in the root of your WordPress install. This is the file where you set the database name, username, password, location and define your site language.

But what many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and tighten security of your WordPress-powered site. Once you get the basics of wp-config.php, you can really do some awesome stuff.

The contents of the wp-config.php file are in a specific order, the order matters. If you already have a wp-config.php file, rearranging the contents of the file may create errors on your blog. But above all else, make sure to backup your database before making major optimization efforts or attempting to repair tables.

Now the first thing you want to do with your new wp-config.php is to protect it. In an earlier article here you can find a great way to secure this file using .htaccess: .htaccess codes to secure your WordPress site.

WordPress Database Table prefix

The smartest way you can protect your database is by changing the default table prefix which is really easy to do on a site that you are setting up. But it takes a few steps to change the WordPress database prefix properly for your established site without completely messing it up.

The default value, as seen in your wp-config.php file, is:

$table_prefix  = 'wp_';

Changing it to something unique essentially immunizes it against automated attacks, malicious scripts and bad bots on anything prefixed with “wp_”. The more random and unique, the better: “name123_” could be a good example.

Note: Ending the string with an underscore or some other easily recognizable character is a good way to keep things readable and easy to use.

Tell WordPress to remember your FTP credentials

This snippet simply tells WordPress to remember your FTP credentials so you won’t be asked again when an upgrade is available.

define('FTP_HOST', 'ftp.yoursite.com');
define('FTP_USER', 'Your_FTP_Username');
define('FTP_PASS', 'Your_FTP_password');
define('FTP_SSL', true); // If you can use a SSL connection set this to true


WordPress Internal Caching and Cache Expiration

In case of a slow database server, it might be a good idea to store frequently used data in a serialized form on disk. WordPress has an integrated disk-cache which stores rarely changing data like categories and users in a special folder.

The first definition enables you to enable or disable the cache, while the second definition enables you to specify the cache expiration time.

define('WP_CACHE', true);      // 'true' to enable the cache
define('CACHE_EXPIRATION_TIME', 3600); // in seconds

Note: If you want to disable cache, then change 'true' into 'false'. Make sure that the wp-content/cache folder is writable!

Dealing with Post Revisions

WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, you can limit the number of saved revisions by inserting:

define('WP_POST_REVISIONS', 3); // any integer

Note: If you want to disable the post-revisioning feature, change the integer to “false“.

Specify the Autosave Interval

In a similar approach as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want.

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

Note: Don’t set the time to tight, unless you want to stress-out your server.

Automatically empty trash

By default WordPress deletes the Trash every 30 days, but you can set it to whatever you want by adding a line like this to wp-config.php:

define('EMPTY_TRASH_DAYS', 1); // Empty spam comments automatically every day!

Note: Replace 1 by X to empty spam comments automatically every X days, you can disable the Trash feature by specifying a zero value.

htaccess codes WP security

Increase WordPress memory limit

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. By default, WordPress is configured to limit the php memory it uses to 32M. If you receive a message such as “Allowed memory size of xxxxxx bytes exhausted”, you might want to increase this limit, as shown below:

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


Blog Address and Site Address

By default, these two configurational definitions are not included in the wp-config.php file, but they should be added to improve performance. These two settings override the database value without actually changing them. Adding these two definitions in your site’s wp-config.php file reduces the number of database queries and thus improves site performance. These settings should match those specified in your WordPress Admin.

define('WP_HOME', 'http://gonzoblog.nl');
define('WP_SITEURL', 'http://gonzoblog.nl');

Note: Do NOT include a trailing slash at the end of either URL!

Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called php_error.log, make it server-writable, and place it in the directory of your choice. Error logs are powerful tools for keeping an eye on things and expediently resolving issues. Then edit the path in the third line of the following code and place into your wp-config.php:


Note: There’s a great article about monitoring your site’s PHP errors (see Method 1) on digwp.com

Override File Permissions

If your web host’s default file permissions are too restrictive, adding these definitions to your WordPress configuration file may help resolve the issue.

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

Note: All files should be 644 or 640, and all directories should be 755 or 750. Read more about Changing File Permissions on Codex.

Force SSL usage on your wp-admin directory

If you’re running WordPress on a server that supports SSL, you might want to force SSL usage on all admin sessions. To do so, simply define the FORCE_SSL_ADMIN constant in your wp-config.php file, as shown below:

define('FORCE_SSL_ADMIN', true);

Automatic Database Repair

WordPress 2.9 and later has automatic database optimization support, which you can enable by adding the following define to your wp-config.php file only when the feature is required:

define('WP_ALLOW_REPAIR', true);

After you have added the code in the wp-config.php, you can repair your database anytime by visiting the URL: {your_URL}/wp-admin/maint/repair.php

Change your wp-content directory

Since WordPress 2.6 you can change your wp-content directory. Set WP_CONTENT_DIR to the full local path of this directory but should not have a slash “/” at the end. Example:

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/new_folder/wp-content' );

Note: Do NOT include a trailing slash “/” at the end.

WordPress debugging, the easy way

When developing or debugging, it is useful to display errors. But when your site is live, you might not want to show your potential errors to the entire world. Here is simple solution to display errors only when a ?debug=debug parameter is found on the url.

The first thing to do is to paste the following code into wp-config.php:

if ( isset($_GET['debug']) && $_GET['debug'] == 'debug')
  define('WP_DEBUG', true);

Now you can open any page, and if something goes wrong there, like a white screen of death, you add ?debug=debug to its URL and see what’s causing the trouble.



Note: As pointed out correctly in the comments by Sebastiaan Stok, it’s best practice to only use this snippet in the developers phase! After publishing this snippet should be deleted immediately!

More Information

There are some more tricks and snippets you could add to your wp-config.php, for more information check out the WordPress Codex. On this page you’ll also find how to set Database Credentials, WordPress Localized Language and Authentication Unique Keys and Salts.

Next week I’m gonna write a new article with more tips and tricks to increase loadtime and therefore the general performance of your WordPress site, stay tuned!


Author: Jan Rajtoral

Jan Rajtoral AKA Gonzo the Great is the Founder of and Designer at gonzodesign, providing design services across the full spectrum of Brand Identity, Graphic Design, Print and Advertising Design & Website Design.


on this article: “wp-config.php snippets for better Security and Performance”
  1. I am not sure where you are getting your information, but great topic.
    I needs to spend some time learning much more or understanding more.
    Thanks for great info I was looking for this information for my mission.

    • Hi,

      Main source of this article is the Bible of WordPress: Codex! If you want more, that’s the place to be ;-P

      Glad you liked it, hope it was useful? Enjoy your weekend! Cheers & Ciao!

  2. – Database Table Prefix: only if they can get access to the database they would see the actual table names. Unless WordPress shows them publicly somewhere, in that case its indeed better.

    – Remember FTP credentials: True, sometimes this is needed, but its important to warn about the risks involved as not everyone will be aware of this. In the end its there decision, but at least they can make a weighted decision or take some extra precaution. – Like creating an extra (S)FTP user with an IP restriction :) (just for this)

    – Automatic Database Repair:
    Just noted this line. “After you have added the code in the wp-config.php, you can repair your database anytime by visiting the URL: {your_URL}/wp-admin/maint/repair.php”

    Hmm. I cannot remember seeing that line before :) in that case its no problem.
    With automatic I was thinking about doing this periodically, like every day at midnight. Doing this “manually”, as you need to go to a URL its no problem and perfectly save (as long as you have enough disk space and a recent back-up of course).

    WordPress debugging, the easy way:
    Yes in developing ;). I pointed this out as some people (no offense) would copy this blindly, opening there installation to attacks. Its best to use something random that only they know (h4f21d=42413k1kj1), or even better by restricting the IP access to either (localhost) so that only “they” can access debugging information.


    • Hi Sebastiaan,

      The good thing about the database table prefix is the fact you’ll only make it more difficult for hackers. I agree (and, unfortunately, know from my own experience) it’s almost undoable to fix this when you have already a great amount of existing and published posts (then you gotta work with SQL queries to change all the prefixes throughout your blog)! Do this when you start publishing a new blog/site .. much more relaxed ;-P

      I totally agree that it’s always important to warn people not to just copy the codes, but also give some insight what a snippet can do! And therefore I would like to thank you for, hat tip to you Sir!

      The tip for the Automatic Database Repair I got directly from the WordPress Bible, the Codex! Read more here: Automatic Database Optimizing. But yeah, your tip is a lifesaver: “having a recent back-up”. That’s why I placed a ‘notifaction’ bar in my preface of this post, .. we’re thinking the same here ;-P

      And I’ve *updated* the text concerning the debug snippet: only to use in developers phase! After publishing the designer/developer of the theme should delete this immediately. So thanks for that addition buddy!

      Thanks for your comments Sebastiaan, .. heb een hele fijne avond en wellicht spreek ik je eens live ergens, en in het NL’s? Groetjes!

  3. Awesome informative post. Thanks for this wordpress tip

  4. First of all, don’t use every described above. Some are extremely dangerous!!
    Most tips are good and useful but some can really get you in to trouble when applied blindly.

    “WordPress Database Table prefix”
    This does not secure you installation in any way, visitors don’t have access to the database and WordPress makes it no secret its used. So this is just pointless.

    “Tell WordPress to remember your FTP credentials
    This snippet simply tells WordPress to remember your FTP credentials so you won’t be asked again when an upgrade is available.”

    DON’T DO THIS! Unless there is good reason to use FTP like storing files don’t store your website access configuration in plain text in ‘plain side’. If someone hacks the installation (in any way, including bad chmod’ing) they can get FTP access and complete hack your site.

    Only keeping this for ‘ease of use’ is just to risk full.

    “Automatic Database Repair”
    Doing automatic MySQL optimize is something you should not never ever do!! especially when using myisam for the storage engine. MySQL is optimize performed in such a STUPID WAY that you will not believe it.

    MySQL optimize creates a NEW DATA FILE copying ALL DATA TO THIS NEW FILE, but during this process the old file is locked (you cant change anything then). And if something goes wrong your F******, MySQL panics and removes both the new AND THE OLD FILE!! Your data is gone, MySQL repair will not help you because the table is not corrupted. In fact, running repair with not enough disk space will have the same effect, make sure you have a back-up before starting optimize. And never do this automatically. EVER!

    Not everyone knows this, I to was shocked when I heard about this ‘feature’.

    “WordPress debugging, the easy way”
    And dangerous way, if someone knows your using this THEY to can (ab)use this. Make sure you use an IP restriction or “unique” value for the debug parameter so ONLY YOU can use it.

    Other tips are good, especially forcing SSL for the admin section! and enabling chaching.

    • Hi Sebastiaan,

      .. thanks for your detailed comment and sorry for my late reply .. had some huge deadlines these last couple of weeks so I had to focus on that.

      Don’t fully agree (or have another opinion) about some of the things you wrote about, but you’ve made some good additions too, thanks for that! First of all ..:
      – Database Table Prefix: By keeping your prefix “wp_”, the malicious user can easily guess the WordPress database table names and exploit the vulnerability against your blog or site, by renaming the WordPress database table prefixes, you are automatically enforcing your WordPress database security against such dangerous attacks because the attacker would not be able to guess the table names

      – Remember FTP credentials: Sometimes, depending on hosting/permissions/etc it’s wise/necessary to add the credentials into your wp-config (and secure that file as well) so you don’t need to write it down with every plugin/core update being released. I especially had this problem once with an ‘over-secured’ server (SFTP), where I had to add this snippet to let the site work correctly. I must admit that it could be vulnerable to put your FTP credentials ‘out there in the open’ .. cuz if wp-config gets hacked, you’re kinda spreading the red carpet for the hacker!

      – Automatic Database Repair: WordPress advices to repair the database this exact way, so can’t see what’s wrong with that? Okay, there’s also another way to optimize the tables of your database, in phpmyadmin, by optimizing your tables one by one. But the essence of optimizing tables should be a no-brainer (imho): it helps to reduce the size of database, loading speed of your blog increases, etc.

      – WordPress debugging, the easy way: Please do this only in the DEVELOPING phase of designing a WordPress site! Make sure to remove this snippet when you’re going to publish the site, than no one can (ab)use this feature to hack into your site!

      So Sebastiaan, thanks for some additions and maybe you could elaborate a bit more on some of the points (e.g. Automatic Database Repair) in your comment? Anyhowz, enjoy your day buddy! Cheers & Ciao!