WP-Config tricks

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.

wp-config.php

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.

Debugging

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 wp-content folder.

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—including that of this website, 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.

Security

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 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 ); .

Updates

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 define('CORE_UPGRADE_SKIP_NEW_BUNDLED', true);.

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 wp-config.php.

Go Explore

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!

stuff we dig

FYI: yes, the above are affiliate links, so we do make a small amount of money if you follow them over and buy what they're selling. Thank you for helping pay our hosting costs!

Dave Kuhar

Dave is the jack-of-all-trades running Transmit Studio, a media creation lab in San Jose. He's built more websites than he can remember, well over a hundred of them on WordPress. Whether it's tradeshow booths, video/TV, graphic design, presentations, magazine, tearsheet, and catalog layout, corporate identity packages, or just about any other kind of visual communication project, he's worked on it!

Leave a Comment