On the “back end/front end” Thing

These distinctions are hard. For the vast majority of clients, if you are writing CSS, you are probably also writing HTML. If you are writing HTML, you are probably querying the DB or a remote API in order to generate that HTML. If you are querying a DB, you might be designing a schema. If you are calling an API, you might be managing the local server cache. Therefore there is no distinction between back/front end developers that clients will ever care about or be able to request accurately.

In my opinion, we’re all “templaters”. As a templater, I need a sys-admin to give me an environment in which to work and a designer to tell me how it should look. I’ll take it from there, everything from generating to styling the content.

GoDaddy’s “Micro Dollars”

I’m working on a GoDaddy plugin at the moment, to allow the wp-admin user to purchase domains through the GoDaddy API.  This is a crucial step in a larger project to allow non-technical clients to manage their own launch process. Turns out, GoDaddy’s API is weird.

Here’s a sample response from their `/domains/available` endpoint:

more… GoDaddy’s “Micro Dollars”

Published in CSS-Tricks: Deploying From Bitbucket to WordPress

Direct link.

Merging Multiple `WP_Error` Objects into One Object

Let’s say you have a function that does two things:

function my_func() {
    $a = a();
    $b = b();
    if( is_wp_error( $a ) || is_wp_error( $b ) ) { return FALSE; }
    return TRUE;

That’s a little cumbersome, because if it returns `FALSE`, I’m left unable to tell which failed: `$a` or `$b`, or both.

Here’s what we can do instead:

function my_func() {
	$a = a();
	$b = b();
	$maybe_errors = new WP_Multi_Error( array( $a, $b ) );
	if( $maybe_errors -> is_wp_error() ) {
		return $maybe_errors -> get_error();
	} else {
		return TRUE;

So what happened there?

I’ve got a custom class, `WP_Multi_Error`, that extends `WP_Error`. You can pass it an array with any number of members, of any type. It loops through them and, for any that are error objects, it merges them together into one error.

Here’s the gist:

more… Merging Multiple `WP_Error` Objects into One Object

PHPUnit on MAMP: The Last Boss

I tend to get beat up really badly whenever I have to do anything involving MAMP, the command line, OSX — basically anything environmental. I get the feeling I was supposed to learn this stuff when I was fourteen. Therefore, learning to run PHPUnit on MAMP has been painful for me, and I assumed all along that I was screwing up some … command line … thing.

Turns out, code is code. My problem was in the bootstrap.php that wp-cli created all along. Once I stopped staring off into the distance wondering why phpunit wasn’t working, and got back to actually, you know, reading and writing code, I found the problems. I had to make two customizations, and I haven’t seen either one discussed in the popular tutorials for this subject. Here’s the gist:

more… PHPUnit on MAMP: The Last Boss