$query_args = array(
    'meta_query' => array(
        array(
            'key' => 'my_key',
            'value' => false,
            'type' => 'BOOLEAN'
        )
    )
);

This works for the false case, but not for the NULL case. As I did a bit of searching, I found this core ticket which is going to allow searching for NULL meta values in WordPress 3.4. However, I had 2 problems with this solution:

1. WordPress 3.4 isn’t out yet (duh) and we need to support a couple of versions back, anyhow.
2. I needed to modify the main query. Tacking on items to the meta_query is error prone once someone else (a plugin, for example) tries to modify it as well. Specifically, the relation argument causes issues:

$query_args = array(
    'meta_query' => array(
        'relation' => 'OR',
        array(
            'key' => 'my_key',
            'value' => false,
            'type' => 'BOOLEAN'
        ),
        array(
            'key' => 'my_key',
            'compare' => 'NOT EXISTS'
        )
    )
);

The above code would work as long as no other plugin needed to use the meta_query. But what if a plugin tried to modify the query args with their own keys and values?

$plugin_query_args = array(
    'meta_query' => array(
        'relation' => 'AND',
        array(
            'key' => 'their_first_key',
            'value' => true,
            'type' => 'BOOLEAN'
        ),
        array(
            'key' => 'their_second_key',
            'value' => true,
            'type' => 'BOOLEAN'
        )
    )
);

You’ll notice the relation values would conflict, since WordPress only allows one meta_query at a time. That means we need another method to check for false or NULL values. After a bit of digging around, I pieced together this SQL-based solution:

add_filter( 'posts_join', 'lets_modify_the_posts_join' );
add_filter( 'posts_where', 'lets_modify_the_posts_where' );

function lets_modify_the_posts_join( $clause='' ) {
    global $wpdb;

    // We join the postmeta table so we can check the value in the WHERE clause.
    $clause .= " LEFT JOIN $wpdb->postmeta AS my_postmeta ON ($wpdb->posts.ID = my_postmeta.post_id AND my_postmeta.meta_key = 'my_key') ";
    
    return $clause;
}

function lets_modify_the_posts_where( $clause='' ) {
    global $wpdb;

    // Check whether the value is false or NULL. If it is neither, then we want to filter it.
    $clause .= " AND ( (my_postmeta.meta_key = 'my_key' AND CAST(my_postmeta.meta_value AS CHAR) = '') OR my_postmeta.meta_id IS NULL ) ";

    return $clause;
}

What we’re doing here is adding a JOIN statement to the query that joins the wp_postmeta table on the key “my_key”. We join the table as “my_postmeta” in the example.

Then, we’re adding a condition to the WHERE clause to check if the my_postmeta.meta_value is either false or NULL.

I hope this is useful to somebody out there. If I’ve overlooked some easier way to do this, let me know in the comments – thanks!

After a fast start, Twenty Twelve development slowed to a crawl in February (which was my fault) and in March we decided including it in WordPress 3.4 wasn’t a good idea. Since then we’ve re-focused, moved the Twenty Twelve repository to Github, and established a regular work schedule to ensure it’s ready for WordPress 3.5.

If you’re following along over on Github, expect to see commits going in on Wednesday and Thursday mornings. Right now the team is small: Lance and I are working on the code and chatting with Matt and Nacin as required over Skype. We may be small, but we’re more than happy to accept bug fixes and suggestions in the form of pull requests. In fact, a few folks have already chipped in — thanks Konstantin Obenland and Jeff Sebring!

Over the next few months I’ll be posting more about the decisions and discussions we’ve made and had while building Twenty Twelve. At first, these will be a bit backdated, but the posts will slowly catch up as we move along. We’ll also put up a live demo site sometime soon, so you can see Twenty Twelve in action!

First sketches

First sketches are a basic overview for the direction of the theme. It’s the first thing I do when I sit down to design a theme. They don’t set anything in stone, but they set the tone and aesthetic for the design. The goal here was to avoid anything fancy, whimsical, or tricky. The focus for the theme will be clean lines, precise spacing, and great typography. Twenty Twelve should be a joy to read.

These sketches were completed back in January, and some things have changed since then, but the general look and feel of the theme has stayed the same. In the next few posts we’ll dive a little deeper and take a look at some of the decisions we’ve made so far. Stay tuned!

However, by default this row will show no matter what, even when you toggle the “kitchen sink” on and off:

It seems more logical to toggle the third row on and off along with the rest of the advanced buttons. In fact, there is a core ticket dealing with this very situation.

In searching around, I discovered a WordPress StackExchange thread that described my exact problem – but without a solution to the toggle issue.

I decided to dig into the TinyMCE API and write my own little jQuery function to handle it. You can add this code directly to your TinyMCE plugin init call:

init : function( ed, url ) {
    ed.onInit.add(function( ed ) {
        if ( getUserSetting( 'hidetb', '0' ) == '0' ) {
            jQuery( '#content_toolbar3' ).hide();
        }

        jQuery( '#wp-content-editor-container #content_wp_adv' ).click(function() {
            if ( jQuery( '#content_toolbar2' ).is( ':visible' ) ) {
                jQuery( '#content_toolbar3' ).show();
            } else {
                jQuery( '#content_toolbar3' ).hide();
            }
        });
    });
}

Once you add this snippet to your editor plugin JavaScript, your extra row of buttons will toggle on and off along with the other advanced buttons:

Let me know if it works for you!

Additional resources for writing your own TinyMCE plugin:

• WordPress Codex page for custom buttons
• Writing a TinyMCE plugin

It was about time

Now that we’ve moved completely to WordPress all of our content is actually managed by – guess what – a Content Management System! All tutorials, documentation, theme pages and generic content pages (About, Contact, etc) were previously hand-edited HTML/PHP files. Making updates to the documentation involved:

1. Writing the copy locally and committing to Git.
2. Creating and formatting any necessary images and adding them to the Git repository.
3. Adding links elsewhere on the site to the new content.
4. Ask the team to review changes, which meant they had to pull the repository.
5. Deploying the changes and images to the live server.

That meant content and images were generally not visible to the whole team until they were checked into Git, and it created incredible friction when it came to updating documentation. I know I personally avoided adding images because it was such a pain to get things to work “just right”. It was a process that is better suited for code and not content.

New and improved workflow

Now, we’ve simplified our workflow:

1. Write or edit your content and insert images in WordPress.
2. Ask for review if necessary.
3. “Publish” and you’re done!

Most links are managed by WordPress and automatically updated – for example, publishing a new theme immediately makes it available on the theme index page.

Now, there are times where we want to do some local development – maybe Scott wants to test some new headings for blog posts. I wrote some pulldown scripts using Capistrano with the multistage extension to make this possible.

Content (including uploads) is pulled down from the production server to the staging server, which is a nearly-exact replica of the production machine. Then, we pull the content from the staging server to our local machines, which means we can develop locally with a copy of the live content easily.

Before the switch, content flowed from Development → Live. Now, we’ve completely reversed the flow: Live → Staging → Development. This is separate from code changes, which still go Development → Staging → Live (and they should, as Mark Jaquith dutifully pointed out in his WCSF 2011 talk).

The WordPress-powered site removes the friction I mentioned earlier, making documentation and copywriting tweaks quick and easy. We’re now using the full potential of WordPress to power our entire site, instead of only using it for our blog. It’s refreshing to trust WordPress to manage all of our content, because it allows us focus on improving the other aspects of the site.

That’s great, but what’s under the hood?

Our content is broken down into a few Custom Post Types, beyond the normal Posts and Pages:

• Themes – One for each dazzling theme we release.
• Stories – Success tales from our actual customers.
• Tutorials – Documentation and guides for our paid customers.

We use custom taxonomies for each of these Post Types. Currently, the taxonomies are used to decide which Themes/Stories/Tutorials are “featured” in various places on our site.

In addition to the taxonomies, we’re using a handful of custom meta data fields on each of the post types. For example, each Story belongs to a Theme, so we store that with the Story:

Similar meta data is stored for Themes:

Plugins

We’re also using a few plugins to help power the new site.

• Akismet – Foil nasty spammers.
• bbPress – Powers the customer support section of our new Help Center.
• Markdown on Save Improved – We love Markdown, and this plugin makes it easy to use with WordPress.
• Memberful WP – Handles single sign on and integration with Memberful.
• Multiple Post Thumbnails – Use multiple Featured Images in a post.
• VaultPress – Real-time offsite backups of our precious data.

Wrapping it all up

So what does all this WordPress goodness amount to? Well, it has offered a few clear advantages:

• Previously, WordPress only powered our blog. Now, it powers all of our content – and that means that we’re dogfooding it even more, bringing us closer to the experience of most of our customers. Heck, according to the WP 2011 survey most WordPress users have WordPress acting as a CMS only, so we needed to get with the times!
• Our documentation and marketing copy have improved already, due to the ease of revisions. Small copy tweaks that would’ve taken 15 minutes to deploy on the old system take 15 seconds now.
• Reviewing the material before a release used to be a mish-mash of “sharing” methods. Sometimes we’d check it into Git and push for everyone to read and sometimes we’d post rough drafts in Basecamp. Now, we just write our draft in WordPress and publish when a new theme is released. Condensed, consolidated and simplified.

I think the last point can’t be overstated – consolidating your workflow into one place does major things for your productivity. No more lost bits of information scattered over multiple sources. Instead, you have a canonical place for your content, reducing the clutter and allowing you to just…write.

All of this sums up to a much better content publishing experience. Like I mentioned, I used to dread publishing to our site. But now I’m actually excited to work on our documentation posts and to write blog posts like this one.

Behind every good website there’s a person (or people) and, in many cases, a business. And behind every rework and redesign, there is a reason – a “why” before the “how”, if you will. I wanted to touch on that a little bit. Don’t worry – we’ll get to the custom post types, bleeding edge this-and-that and JavaScript whizbangs for you propeller heads before long!

But first, let’s review the story up to this point.

Back in 2008, Drew and Jennifer started what would eventually become The Theme Foundry with plenty of blood, sweat and tears to mark the trail.

Since then, the business has grown and moved from

1. Drew and Jennifer going it alone, to…
2. Working with a handful of contractors, to…
3. Hiring two full-time employees (Scott and myself) and looking for another

We’ve also expanded our themes to the WordPress.com marketplace and moved into a totally new and foreign (and exciting!) realm with Memberful, our still in development SaaS offering for selling digital products.

2012 is an exciting year for this company. And with all the growth going on, it was time to not only add a fresh coat of paint, but completely rework the website that powered the business.

The old website grew organically out of need – a handful of static pages, WordPress powering the blog, bbPress 1.0 Alpha powering the forums, and aMember (*shudder*) managing the selling of themes.

If our old website were a bicycle, it might look something like this (with Drew supplying the Fred-Flinstone-esque leg power).

As of February 18th, 2012, we’ve officially “switched over” to a more powerful and elegant solution, featuring:

• A single WordPress installation
• bbPress 2.1
• Memberful integration (yep, we’re dogfooding it!)

I hope you’ll join me in the coming days as I do my best to chronicle some of the decisions we made and discussions we had along the way.

There are some themes that are designed to serve nearly any purpose under the sun – and they contain a vast amount of configurable options on the backend to help you get your site “just like you want it”.

On the other hand, there are those who say themes should have zero (or as close to it as possible) options – the idea being that a theme should “just work”.

At The Theme Foundry, we tend to lean toward the “zero configuration” side. We think requiring extensive backend setup is a turn-off for the average user, so we gear our themes to work “out of the zip”.

With that in mind, I’d like to share a story with you about some lessons I learned while building Duet.

Developing a philosophy

Personally, I’m relatively new to the WordPress theme space. As I’ve read over various WordPress development blogs and news sources, I’ve found that there seems to be a general outcry against too many options. In a recent WPCandy podcast, Ryan Imel mentioned that developers should be shooting for zero theme options as an ideal. Andrew Nacin wrote recently about “learning to decide” instead of just adding another option.

Death to options!

Such a compelling rallying cry – the thought of a theme that “just works” without a single configuration option seemed like a crystal-clear light to guide the way! I loved the principle so dearly, that during a company discussion, I suggested that we gear our efforts towards eliminating all options:

Talk is cheap…

The team rallied around the idea – we’d take a hatchet to options! At the time, we were working on our most recent release, Duet. Scott’s design was focused on typography and a beautiful reading experience, and it had a number of options to tweak the appearance. Duet’s options page looked like this, fully expanded:

We talked it over, and decided we’d go one-by-one through the options and scrutinize like madmen. Anticipating massive option slaying, we pictured the “after” screenshot to look something like this:

The Ethos of the Logos

Energized behind our new philosophy, we started with some substantial victories in the Logo Options section.

We asked: Do our users have any need to modify the alt text of their logo image?

The answer: No. Of course not – the site title works wonderfully as the alt text (this is for their logo, after all). Chopped.

We asked: Do we need an option to toggle the tagline display?

The answer: No. The tagline is only used in the header, and if the user wants to remove it they can simply remove their tagline in their settings. Any more complicated tagline requirements they have can be handled through template modification and/or CSS changes. Consider it chopped.

Boom! Two options down right out of the gate. We were feeling pretty good at this point, and our strategy looked promising. But (you knew this was coming), as we started trying to chop some of our other options, we found ourselves at a bit of a crossroads.

Color me unconvinced

The headings in Duet were a nifty orange color by default. Knowing that orange doesn’t suit everyone’s taste, we originally included an option for toggling the color of these headings to a color of your choosing, using a hex value and a color picker.

Then, we asked: Is choosing the heading color something a user should have to deal with?

The answer: No – but they need to be able to switch from orange. As theme designers, instead of leaving the user to try to find something that looks nice, we should be be providing some awesome choices that are stunning out of the box. It’s all about making the best decisions for the user, not adding options.

We decided to come up with some color schemes to choose from, which offered a few big advantages:

• Users didn’t have to mess around with hex color codes, trying to find a good fit.
• We could add additional colors to compliment the main.
• We could change the featured banner color (which uses image CSS pseudo-elements to get the banner effect) to compliment the color scheme.

Our slash-and-burn philosophy was starting to hit reality – and believe it or not, I started to feel a little anxiety. I wanted desperately to chop our options down to the bare minimum, and I suggested ways to get rid of the option:

• Provide tutorials on editing CSS that would show users how to modify their color schemes and select good colors.
• Include the banner elements as PNG and PSD files so users could make their own.

Drew and Scott quickly reminded me that requiring users to make modifications to their theme is a less than ideal experience. They weren’t buying it, so we kept the option.

So, after our changes we still had an option – but we felt it provided a better experience and prevented the user from having to make a nuanced design decision (that’s our job, after all) – instead, they had 3 lovely choices. I wasn’t thrilled, but I was overruled and we moved on to the next option for review.

The great reversal

Scott had included an option to control whether or not the tags would display on a post. If the user checked it, all tags would be hidden from all posts – aha! Something that could be easily controlled using CSS or a small template modification – victory was mine!

We asked: Do our users really need to be able to hide the tags on their posts?

The answer: No. Except that this is one of the most-requested modifications on any of our themes. Some people use tags, some people use categories, some use neither, and some use both. Hiding one or the other is useful to many of our users, and that’s something we’ve learned only through experience. It could be omitted, but we would then have to instruct users on how to modify the templates to remove tags or categories (not easy for the average user).

So, the real answer: Maybe…?

This was a toss-up. The option wasn’t necessary, but experience told us that a toggle option would probably improve the user experience. At this point, I was actually going through a bit of cognitive dissonance.

On one hand, I wanted options to die. On the other hand, I realized that these options were born out of real use cases. I knew this because I handle requests for removing categories, tags and authors on a daily basis in support. Modifying template files is difficult for many of our users, and hiding via CSS is not a very clean solution.

In addition, we sell our themes on WordPress.com – where users are unable to modify their template files, and CSS changes cost extra.

We left it in, and actually added a toggle for hiding the author and categories as well. It was sorta painful, but I was beginning to realize the flaw in my philosophy: It’s not about eliminating options, it’s about having the right options. I know, I know – hardly groundbreaking. It’s been said before by many wiser people than myself. But it’s very easy to get caught up in a philosophy without considering the real goal, which is making a pleasant experience for your users.

Don’t steal my Theme Options

And this is why I wanted to write this post – to counter-balance the anti-options, anti-configuration sentiment. It’s too easy to get caught up in a cargo cult – I know I did, briefly. Instead of making a theme either fully-customizable or configuration-free, I’ve realized that the ultimate goal is to add “just the right options” to make the user experience more pleasant. I think everybody would agree with that sentiment – but it’s easier said than done.

We continued through our options page, scrutinizing each one and considering ways to improve. We ended up reorganizing many options and adding a few (crazy reversal, huh?). Here’s what we ended up with, final (left) vs. original (right):

We actually ended up with more options (19 vs. the original 16). Many of our original options remained, though some were tweaked to be clearer. We added an option to control the drop cap styling on posts, since Duet is all about beautiful typography and we anticipated not everyone liking this aspect. Finally, we added some slider options that are commonly requested on our other themes.

And that brings me to the end of my story, a tale of a developer (and a team) who went from loving, to hating, to having a mutually beneficial relationship with options, all in a matter of weeks. It was a tremendous and rapid learning experience for all of us. We still have a lot to learn, but we’re making strides in providing top-notch experiences with each of our themes.