WordPress development with wp-config.php

I use the following setup for testing code against multiple versions of WordPress. These instructions assume that you’ve already created the setup for MAMP development across computers via Dropbox.

WordPress versions

Each separate WordPress version that you plan on testing against needs its own directory in your ~/Dropbox/MAMP directory. For the purposes of this tutorial, I’ll use versions 4.0 and 4.1. (I use major point releases, updated to the latest version.)

Create the directories for each version in your ~/Dropbox/MAMP directory:

mkdir ~/Dropbox/MAMP/wp40.dev
mkdir ~/Dropbox/MAMP/wp41.dev

Download each version from the Codex and place the uncompressed files in the appropriate directory.

Create a master wp-config.php

Since Version 2.6, wp-config.php can be moved to the directory directly above the WordPress application directory. I take advantage of this by creating one single wp-config.php in my ~/Dropbox/MAMP directory, instead of having a different wp-config.php in each WordPress directory.

Plugins and themes

It is hard to test the same version of a plugin or theme against each version of WordPress if each instance has its own plugin directory, and Dropbox does not handle internal symlinks. The solution is to have wp-config.php handle the theme and plugin location for all of your WordPress instances.

In the ~/Dropbox/MAMP/htdocs directory, create the master wp-content directory.

mkdir ~/Dropbox/MAMP/htdocs/wp-content

Copy all of your plugins and themes into their respective wp-content/plugins and wp-content/themes directories, and add the following lines to ~/Dropbox/MAMP/wp-config.php:

define('WP_CONTENT_DIR', '/Users/jmdodd/Dropbox/MAMP/htdocs/wp-content');
define('WP_CONTENT_URL', 'http://localhost/wp-content');

I use localhost to deal with any resource requests for plugins and themes across all of my hosts.

Database and multisite settings

I use a system for naming the corresponding database after each WordPress version so I can cheat and use wp-config.php to set the database name.

/**
 * Dynamic database name calculation:
 * Directory:   URL:                        Database:
 * ms40.dev/    http://ms40.dev/            ms40_dev
 * ms40.dev/    http://site01.ms40.dev/     ms40_dev
 * wp40.dev/    http://wp40.dev/            wp40_dev
 */
if ( isset( $_SERVER['SERVER_NAME'] ) ) {
    $db = $_SERVER['SERVER_NAME'];
} else {
    $db = end( explode( '/', $_SERVER['PWD'] ) );
}

// If multisite
if ( preg_match( '/ms[0-9]{2}/', $db ) ) {
    // Get rid of the site subdomain for database and domain settings
    $db = preg_replace( '/^site[0-9]{2}\./', '', $db );

    // Allow multisite setup
    define('WP_ALLOW_MULTISITE', true);

    /* Uncomment once multisite has been installed
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true);
    define('DOMAIN_CURRENT_SITE', $db);
    define('PATH_CURRENT_SITE', '/');
    define('SITE_ID_CURRENT_SITE', 1);
    define('BLOG_ID_CURRENT_SITE', 1);
    */
}
// Change the dots to dashes
$db = str_replace( '.', '_', $db );

This means that I have to use the same user and password for my database user, but again, this is a quick setup for local testing against multiple versions of WordPress; it is not meant for production use.

Set up debugging

This will write out error files for the current session to the local drive, since I don’t really need or want those to sync between my computers.

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define('WP_DEBUG', true);
if (WP_DEBUG) {
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', true);
    define('SAVEQUERIES', true);
    @ini_set('error_log','/Users/jmdodd/logs/' . $_SERVER['SERVER_NAME'] . '/error_log');
}

Command-line hack

Sometimes I do something particularly awful and want to run a PHP script which includes WordPress functions via require( './wp-load.php' );. This sets up a really basic environment so that I can do things like file imports. WP-CLI would handle this far more gracefully.

// Server load
if ( isset( $_SERVER['SERVER_NAME'] ) ) {
    define( 'DB_NAME', $db );
// Command-line load
} elseif ( isset( $_SERVER['PWD'] ) ) {
    $pwd = end( explode( '/', $_SERVER['PWD'] ) );
    define( 'DB_NAME', $db );
    define( 'DOING_AJAX', true );
    define( 'WP_USE_THEMES', false );
    $_SERVER['HTTP_HOST'] = $pwd;
    $_SERVER['SERVER_NAME'] = $pwd;
    $_SERVER['REQUEST_URI'] = '/';
    $_SERVER['REQUEST_METHOD'] = 'GET';
}

Comments are closed.