Call me Pawpaw

Status

As of 7:50 a.m. this morning, My wife Susan and I are officially grandparents. We will henceforth be known as Mammaw and Pawpaw.

Welcome, Carson Alexander Buckner. 9lbs 10oz, 20 3/4 inches. And congrats to proud parents Mary and Shane!

Pictures to come. Lots and lots and lots of pictures, I’m sure. 😉

 

Pantheon Platform Adds WordPress Support

Pantheon, long known as a platform provider for Drupal hosting, has now added official support for WordPress, as well. Pantheon provides a scalable web platform with devops-friendly dashboards and tools for deployment and management.

The first and most obvious thing we did was ensure the platform was WordPress-friendly. This is the only piece of work that wasn’t on our roadmap already, but luckily it wasn’t very hard. The requirements for running Drupal vs. WordPress are quite similar.

The upside is that WordPress developers can expect tuned and friendly configurations for php, nginx, Varnish, mysql and Redis, with a stock set of Plugins to make the most of everything the platform has to offer.

WordPress Developers Rejoice! Pantheon Has Your Back

Interestingly, Pantheon already had a CLI (Command-Line Interface) tool called Terminus for managing services, which they originally implemented as a drush extension (drush is the “drupal shell”, a CLI for Drupal). In modifying their platform for WordPress support, they rewrote it as a stand-alone tool, borrowing a lot of ideas from wp-cli in the process.

We actually borrowed quite a lot from the wp-cli toolkit in this refactor. Our library code was largely portable from Drush, but we took their object structure and docstring-parsing magic, which is pretty strong stuff. As a result, we have a more robust CLI tool to build off in the future.

If you’re interested, they offer a free account to let you check things out (no custom domain on the free level). Paid offerings begin at just $25/month.

(I have no affiliation with Pantheon, if anyone is wondering)

mysql vs mysqli in WordPress

I recently ran across an issue that I was previously unaware of, so other developers could run into it as well. I was having problems with a plugin, which started misbehaving. The plugin had previously worked fine (it generates a sidebar widget), and I wasn’t actively working on my site, so I wasn’t really sure when it had quit working.

In the course of debugging the problem, I discovered that the plugin was throwing warnings in my PHP error log regarding the mysql_real_escape_string() function. As a quick fix, I simply replaced all of those calls with WordPress’ esc_sql() function. Voila, problem fixed.

Curious, I took a peek into wp-db.php, and found this block of code:


/* Use ext/mysqli if it exists and:
 *  - USE_EXT_MYSQL is defined as false, or
 *  - We are a development version of WordPress, or
 *  - We are running PHP 5.5 or greater, or
 *  - ext/mysql is not loaded.
 */
if ( function_exists( 'mysqli_connect' ) ) {
        if ( defined( 'USE_EXT_MYSQL' ) ) {
                $this->use_mysqli = ! USE_EXT_MYSQL;
        } elseif ( version_compare( phpversion(), '5.5', '>=' ) || ! function_exists( 'mysql_connect' ) ) {
                $this->use_mysqli = true;
        } elseif ( false !== strpos( $GLOBALS['wp_version'], '-' ) ) {
                $this->use_mysqli = true;
        }
}

Note the bit about using a development version of WordPress. In my case, I’m running out of svn trunk, and my server has the mysqli extension installed, so wpdb chose to use it. That’s fine.

But this exposes the fact that some plugins use functions like mysql_real_escape_string() “in the raw”, so to speak, which depends on using PHP’s mysql extension, and not mysqli. WordPress provides convenience functions like esc_sql() and $wpdb->prepare() to help abstract details like this away and protect developers against environmental differences between servers.

Hopefully this will save somebody else out there some debugging time.