Hacking WP-config
The wp-config.php file is an essential part of your WordPress site. It’s the bridge between the file system of your site and your database because… it contains your username and password. If that information is incorrect (or not present), you get the notorious white screen that displays: “Error establishing database connection”.
Additionally, the default wp-config.php is used to:
- Define security keys,
- Specify the database prefix,
- And specify the default language for the admin area of the site.
But we can do a lot more with it as well. A whole lot more.
Here are a few of the ways you can better utilize your wp-config file via a plain text editor. All changes will reflect immediately and, thankfully, are immediately reversible.
Of note: If your site is on a WordPress-specific or managed WordPress host, you may have already noticed that your wp-config file looks very different from the default one. That’s because it can be used to extensively customize many features of your WordPress installation.
PERFORMANCE
Priority Caching
WP-config.php is one of the first things that loads visitor hits your site. So if you use a caching plugin like WP Super Cache or Fastest Cache, those plugins will enable the cache constant:
define('WP_CACHE', true);
Doing so allows the caching plugin to take over and bypass the performance-rich WordPress processes like PHP and your database. If this constant is not defined or defined too late in the file, the cache will not execute and WordPress loads normally.
Memory Limitations
A very popular tweak is to use the wp-config file to increase the PHP memory allowance for your WordPress instance. If you’re running some intensive plugins like WooCommerce, WPML, or even an intensive theme like Avada, you’ll need at least 128 MB, or more likely, 256 MB.
Memory issues can create a slow admin area, a white screen incomplete loading of pages, or fatal errors. You can define the memory like this:
define( 'WP_MEMORY_LIMIT', '128M' );
Depending on your host’s set-up and limitations, there may be an upper limit for the memory allowance, which the wp-config cannot override. You can also define a memory limit for the admin area specifically:
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
For more info about memory limits and how to debug related error messages, I recommend this post by Donncha Ó Caoimh.
Post Revisions
By default, WordPress stores revisions of your posts every time you save it, making it easy to access previous versions. But as useful as this feature is, multiple revisions can add to the weight of your database and create unnecessary bloat. This can potentially impact your site’s performance.
An easy way to make sure post revisions don’t get out of control is to set up a maximum limit on the number of saved revisions. Specified in the wp-config file, of course. The example below creates a maximum of five revisions:
define( 'WP_POST_REVISIONS', 5 );
You can also disable revisions entirely:
define( 'WP_POST_REVISIONS', false );
Pro Tip: If you’re building a site for a client, make sure you tell them you’re doing this!
Cleanup Image Edits
This is an extremely powerful tweak to keep your uploads folders in check. As you may know, when you upload an image to WordPress a variety of sizes are created based on your Media settings alongside any custom sizes specified by themes and plugins. So for any given image, you’ll receive a minimum of four versions (the original plus thumbnail, medium and large), if not more.
Now, imagine you edit that image within WordPress. You will create another four files for the new, edited version, in addition to the original set of files. Another edit leads to yet another set…. and so on. Say hello to unnecessary files.
This behavior can be modified with:
define( 'IMAGE_EDIT_OVERWRITE', true );
With this definition, WordPress will only keep the original set of files plus the most recent set of edited versions, not all edited versions. Phew! For more background on the origins of this, check out this article.
DEVELOPMENT
Site URLs
WP-config provides the ability to define the WordPress and site address URLs. This tweak comes in particularly handy when migrating a site from one domain to another. It takes precedence over what is entered in Settings > General.
define('WP_HOME', 'http://www.example.com'); // no trailing slash
define('WP_SITEURL', 'http://www.example.com'); // no trailing slash
This removes the need to either update the URLs in the WordPress admin area or in the database itself. Why do that? Well, a mistake in the admin screen will kick you out of the site and force you to go to the database anyway. Additionally, editing the database could be unwieldy since you have to log into and navigate the hosting control panel. So defining the URLs in wp-config can make a transition easier.
You can even make the definitions dynamic so that you can move the site without editing the file:
define('WP_HOME','http://'. $_SERVER['SERVER_NAME']);
define('WP_SITEURL','http://'. $_SERVER['SERVER_NAME']);
Neither of these tweaks completely negates the need to update the database, but I would recommend using them as a temporary workaround for site migrations.
Troubleshooting
There are a few settings that can help developers to debug problems.
The first is to display errors:
define('WP_DEBUG', true);
This will actually display any errors on the front end of your website. That’s fine for a local or development site, but certainly not for a live site. In that case, you can log those errors to a file instead of displaying them on the front end by adding the following lines:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This creates a debug.log file in wp-content. I recommend turning off logging once you have the necessary info you need to avoid impacting performance.
Unraveling Minification
Minified scripts and styles can add a layer of complexity and obscurity when debugging. To avoid this, use the following:
define( 'SCRIPT_DEBUG', true );
Now WordPress itself will load the un-minified versions of its files instead of the .min.css and .min.js versions.
I use this mostly for debugging minification issues. like a performance plugin that provides minification and concatenation. In those cases, assets from your site are combined into one or a few files and so the individual file paths are obscured. Enabling the script_debug feature reveals those full file paths, a huge help in troubleshooting.
Jetpack – Developer Mode
Jetpack is a powerful tool, but not all of its features require a connection to WordPress.com. By turning on developer mode you can gain access to these features without going through the connection process. Simply add the following to enable Jetpacks’ developer mode:
define ( 'JETPACK_DEV_DEBUG', true);
Plugin API Keys
Some premium plugins allow you to define your API key in the wp-config file for convenience. For example:
Soliloquy:
define('SOLILOQUY_LICENSE_KEY','your_license_key');
Gravity Forms:
define( 'GF_LICENSE_KEY', 'YOUR-LICENSE-KEY-HERE' );
SECURITY
SSL
Secure your admin area with this easy SSL definition:
define( 'FORCE_SSL_ADMIN', true );
Disable File Editing
Keep your clients out of trouble and improve security by removing the ability to directly edit theme and plugin code from the dashboard.
define( 'DISALLOW_FILE_EDIT', true );
CREATE A BLUEPRINT
If you create a lot of sites and like to use the same customizations on each one, simply create a boilerplate wp-config. Just keep handy a modified copy of wp-config-sample.php.
On each installation of WordPress, include this modified version. When your site-specific wp-config.php is created during the installation process, it will automatically include the customizations you made to wp-config-sample.php
RESOURCES
This article introduces some useful configurations, but it’s not exhaustive. If you want to dig even deeper, here are a few resources to explore:
