Stupid simple conditional config for local and production w/ constants.

1-wp-config.php

<?php
/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the
 * installation. You don't have to use the web site, you can
 * copy this file to "wp-config.php" and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * MySQL settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://codex.wordpress.org/Editing_wp-config.php
 *
 * @package WordPress
 */
 
define( 'WP_LOCAL_DEV', true ); // use this throughout if you have special "local-only" code. 

define( 'SUNRISE', 'on' );

// ** MySQL settings - You can get this info from your web host ** //

if ( WP_LOCAL_DEV == true ) {
    
    include( dirname( __FILE__ ) . '/local-config.php' );
    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);

} else {

    define( 'WP_DEBUG', false );

    // ** MySQL settings - You can get this info from your web host ** //

    define( 'DB_NAME', '{$my_database}' );
    define( 'DB_USER', '{$db_user}' );
    define( 'DB_HOST', 'localhost' );
    define( 'DB_PASSWORD', '{$password}' );

    // ** Domain and Location settings **//

    define('DOMAIN_CURRENT_SITE', 'mydomain.com');
    define('WP_HOME','http://mydomain.com');
    define('WP_SITEURL','http://mydomain.com');

}

/** Global database settings **/

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

/** Global WP Configuration settings **/ 

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);

/** Global location settings **/ 

define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

/** WordPress Database Table prefix. **/

$table_prefix = 'wp_';
  
/* That's all, stop editing! Happy blogging. */
/** Absolute path to the WordPress directory. */

if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */

require_once(ABSPATH . 'wp-settings.php');

2-local-config.php

<?php
/**
 * The base configuration for WordPress
 *
 * Configuration settings specific to a local installation of this WordPress package.*/

// ** MySQL settings - You can get this info from your web host ** //

define( 'DB_NAME', '{$my_local_database}' );
define( 'DB_USER', '{$db_user}' );
define( 'DB_PASSWORD', '{$password}' );
define( 'DB_HOST', '127.0.0.1' );

// ** Domain and Location settings **//

define('DOMAIN_CURRENT_SITE', 'mydomain.locdev'); // these should reflect your virtualhost settings
define('WP_HOME','http://mydomain.locdev');
define('WP_SITEURL','http://mydomain.locdev');

Why?

The benefit of having a wp-config file set up like this lies in the fact that you can have a config file that will function both on production and non-production (either staging or local) installs of the same WordPress package without anything more than a single constant being changed between the two. This is hugely beneficial for those who use automation scripts for migrating installs back and forth (similar to how WPEngine does).

How to Use

• Fill out the local-config.php constants as you would have filled a wp-config.php file on your local (or staging) machine.

• When working locally (or in staging) set the constant 'WP_LOCAL_DEV' to true. This will load in your local dev. database settings and local domains you set in your vhost (or httpd) config files.

Setting the constant to true also allows you to build in local conditions to your plugins.

WP_LOCAL_DEV Constant Usage Beyond Configuration:

You have a script that makes a curl request to file on the same WP install (commonly done w/ background async processing scripts). Most staging servers have a high level http username and password to stop the general public from accessing the staging version of your website. A curl request to any endpoint that is password protected requires authorization info to be passed in the headers.

Typically you would either have a patch file or some copy/paste code that you can apply to your newly-migrated files that adds additional 'Authorization: Basic' headers to your curl request. But be careful! If you forget to remove those headers things can fail!

Having a constant that you can check, on the other hand, allows you to test the environment in which you are operating and simply add the headers only when you are in the staging environment where authorization headers are extremely useful. And all this at the cost of a single little line of text added to the wp-config.php file at the beginning.

Example:

$args = array(
	'timeout'   => 15,
	'blocking'  => true,
	'sslverify' => false,
	'body' => array(
		'action' => 'wp_my_ajax_callback',
		'nonce'  => wp_create_nonce( 'wp_my_ajax_callback' )
	)
);

if( WP_LOCAL_DEV ) {
	$args['headers'] = array(
		'Authorization' => 'Basic ' . base64_encode( 'myusername' . ':' . 'mypassword' )
	);
	$args['local'] = true;
}

Nice work around, i like it 😁