WordPress Dev Strategy - Part One: Setup
26 October 2016
Wordpress isn't my favourite platform to develop on. It was first released in 2003 and the core code still contains some features that – while they may have been standard practice at the time – feel pretty dated in 2016. But, Wordpress is immensely popular – powering by some estimates, 27% of the web. Clients are familiar with Wordpress, and my vendors have an easy time selling it. As such, Wordpress development makes up a significant portion of my workload. If I'm stuck with this technology, I need a good set of strategies and tools to improve my workflow and make Wordpress more fun to work with. I'm going to review those here on my blog. Today is part one.
Setup
In my last post I discussed my overall setup for development on OS X (er um... macOS), most of which consists of following these two guides:
- Get Apache, MySQL, PHP and phpMyAdmin working on macOS Sierra
- How to set up Virtual Hosts in Apache on macos Sierra and OSX
I prototype my WordPress sites on my local machine, and as such my WordPress setup builds on this foundation, but my WordPress strategy doesn't necessarily depend on macOS, or the specific setups described in the above guides.
WP-CLI
I generally do my local WordPress installs with WP-CLI, a command line interface. For those that prefer the browser GUI it's not absolutely crucial to do your installs on the command line, however WP-CLI is an important part of my deployment process so it's good to have it up and running from the get-go.
Debugging
Three constants can be set in wp-config.php to set up debugging.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
These first two are my standard setup. WP_DEBUG
toggles debugging and must be set to true for the other values to have an effect. WP_DEBUG_LOG
, when set to true outputs all PHP notifications to wp-content/debug.log.
define( 'WP_DEBUG_DISPLAY', false );
Additionally you may wish to turn off WP_DEBUG_DISPLAY
, which defaults to true. When true, PHP notifications are output to the browser as well as the debug log. I like to leave this in place as I am not always closely monitoring the debug log, but if you find the browser output to be redundant, you can set it to false.
PHP notifications will not always be enough as sometimes things can go wrong that don't throw errors or warnings. As such I always include the following function in my functions.php:
if ( ! function_exists('write_log')) {
function write_log ( $log ) {
if ( is_array( $log ) || is_object( $log ) ) {
error_log( print_r( $log, true ) );
} else {
error_log( $log );
}
}
}
This function allows us to output to the log from anywhere in our code, and nicely formats any objects you pass to the function.