At our Meetup on 3/5/18, I covered a few of the tweaks you can make to your
wp-config.php file. This is a little more advanced than many of the topics we’ve had at our Meetup lately, but these tips can come in handy if you find yourself in need of them.
or, how to blow up your website in less than a minute
Side note: if you don’t need the wordy explanations below, the tl;dr version of this list is over here in this Google Sheet.
That’s just my way of warning you that messing with
wp-config.php, while powerful, can cause your site to go down.
wp-config.php isn’t part of your theme, or a plugin; it’s one of the WordPress core files. It’s not often I’d suggest editing any core files; as a matter of fact, this is the only one I’d suggest you dig into. But tread lightly, because there’s some very important stuff in there and changing or deleting it will take your site down. The most important section of the file is the first—it contains information about your database, including the username and password giving WordPress access to it. Play with those lines at your own peril!
The focus of my presentation was offering some
wp-config.php tweaks that are commonly used, presented in several categories.
Important: make sure you add these before
require_once(ABSPATH . 'wp-settings.php');– anything after that point will be ignored.
If you’re struggling with WordPress, your theme, or a plugin not working correctly it can be helpful to display PHP warnings and errors on your screen. It’s simple enough to turn this feature on; simply add
define( 'WP_DEBUG', true ); to the file. Refresh your page, and you’ll be seeing your problems spelled out for you. If you’d rather the errors go to a log file, add
define ('WP_DEBUG_DISPLAY', false); and
define( 'WP_DEBUG_LOG', true ); as well. The error log will be stored in your
Editing and Post Management
Some of the cooler things to be able to control, and that probably come in handy for more people than
WP_DEBUG, is changing how WordPress handles autosave and revisions. For instance, did you know that WordPress autosaves your work as you go? This comes in handy if you accidentally close the page or manage to swipe left on your trackpad and back out of the edit screen. If you reload the edit screen you’ll find that you haven’t lost your work – or much of it, anyway. By default your post is autosaved every 60 seconds. If you have a really slow internet connection you might want to increase that interval, because your browser might be hanging a little every time WordPress pushes the autosave to your web server. On the other hand, if you’re really worried about losing your brilliant words you’d decrease the autosave interval.
To make this change, add
define( 'AUTOSAVE_INTERVAL', xx ); where xx is the autosave interval, in seconds, that you need.
WordPress also saves revisions. This means you can go back in time and restore an earlier version of your post if you like. Unfortunately, WordPress saves all of your revisions, so you could end up with tens, or hundreds, of versions of your posts. (Don’t laugh. I’ve seen this happen.) This is a lot of unnecessary bloat in your database that slows your site down. You can tame this madness by simply adding
define( 'WP_POST_REVISIONS', x ); where is x is the number of revisions you want saved. Some hosts, like WP Engine, disable revisions altogether. You can do the same with
define( 'WP_POST_REVISIONS', false );. Bonus: this doesn’t disable the Autosave feature, just the revisions you save as drafts or published versions of your posts.
And finally, WordPress will happily take out the trash. Any post or page you delete will doesn’t actually get canned; it’s just marked for deletion 30 days in the future. You change that interval, making it longer or shorter to suit your needs. Just add
define( 'EMPTY_TRASH_DAYS', xx ); replacing xx with the number of days you want your old stuff to hang around before disappearing.
Here’s a feature many beginning WordPress users aren’t aware of—the ability to edit theme and plugin files directly from WordPress admin. It’s right there at the bottom of the Appearance and Plugins menus. While this can be handy when you need to make some quick tweaks, it’s also a security risk in that it gives anyone with a high enough level of access the ability to edit these critical files without needing to log in via SFTP. This includes some jerk who hacks his way in by cracking your password.
It’s often recommended that you turn this feature off. Just add
define( 'DISALLOW_FILE_EDIT', true); to the config file and you’re done. You can go a step further and shut off all ability to install, update, or edit themes and plugins from the dashboard by entering
define( 'DISALLOW_FILE_MODS', true ); instead. You’ll have to change that to false every time you need to update your plugins and whatnot, of course. Which you’re doing regularly, right?
It’s also a good idea to force a secure connection to wp-admin, to avoid sending your username in the clear when you log in. The code for that is
define( 'FORCE_SSL_ADMIN', true ); .
It’s always a good idea to remove plugins and themes you’re not using. Not only does it save space, it also eliminates vulnerabilities. It’s bad enough to get hacked; it’d be even more frustrating if they got in through a plugin or theme you’re not even using.
One thing that bugged me for a long time was that WordPress would reinstall the default themes (Twenty Fifteen, Twenty Sixteen, etc.) as part of an update, then I’d have to go and delete them again. Turns out you can shut that off with
Keys and Salts
Finally, we have keys and salts, which have to do with security and authentication. If you’re curious about the details, here’s a good primer. Checking your
wp-config.php you’ll see eight lines of text that look like a cat walked across your keyboard. These are used to encrypt the information WordPress saves in your site visitors’ cookies. Some say that periodically changing these increases site security. Keep in mind that doing so will invalidate the cookie on your computer as well, so if you do this know that you’ll be logged out of your site and will have to log back in to get a new cookie. You can use any string of characters for keys and salts, but in the interest of security they should be long and completely random. It’s not like you have to use them like a password. There’s a handy tool here for generating them – just copy the text you get there and replace the salts and keys currently in
You can do a lot more customization to your
wp-config.php file, this is just a start. For instance, several plugins let you enter your license code here rather than having to enter it on every site you develop. This comes in handy if you use something like Gravity Forms all the time and you have a dev license – just add
define( 'GF_LICENSE_KEY', 'XXXXXXXXXX'); to the config file of your stub site, and every time you clone it your Gravity Forms key will already be entered.
As always – back up before you try any of this stuff!