Last month we had Vietnam’s first ever WordCamp in Hanoi. It was a large, 100-ticket event that took months of planning and hours of time to get right. Sponsors and a rigid schedule were needed. Food and beverages were needed. It was work to get right. After WordCamp I remember thinking to myself, “This was amazing. I’m so happy with what we’ve accomplished during the last several years here in Hanoi, but I’m also glad that WordCamp only happens once per year. It’s too much.”

We had a meetup yesterday. Nearly 90 people registered for it and only 12 people, nearly half who had never been to a meetup, came. And yet I felt so fulfilled and so very happy with the turnout. Big never mattered to me as much as making connections, and the connections that I made at yesterday’s meetup were deeper than the connections that I made at WordCamp. No rigid schedule was needed. Chats happened organically. Everyone had a chance to introduce himself and share what he was working on. It felt like a small community.

WordCamp San Francisco 2011 changed my professional life. I was just ending my time with Graph Paper Press and thinking about what would happen next. I volunteered at a Happiness Bar, met Lance, immediately hit it off with him, and decided to apply to Automattic because he seemed like someone who I’d get along with. It was a very random, very destiny-filled encounter with another weird soul who had traveled the world, grown up in another country, and clicked with me well. We got each other.

But if I had not met Lance I would have probably thought that WordCamp San Francisco was exhausting and something that I could only physically and mentally bring myself to do once per year. I am an introvert. Large groups and large social gatherings bring me great stress. I’m socially adept, warm with others, and very personable, but only when groups are small. When they are large, like at a party or company meetup, I clam up, want to hide away in my room, and stay away from everyone. I don’t know why this happens but this is how I’ve always been. Give me a dinner table with 4 seats only, please. 6 is too much.

The way forward for me is small. Small numbers of friendships. Small gatherings. Small meetups. 1-hour phone conversations with 1 person rather than 3-hour social gatherings where I connect with no one and feel exhausted at the end of the night. I’m tired of feeling like big is a good thing. It’s simply not, especially when it comes to maintaining relationships in our lives that act as bouys and bedrocks. A girlfriend, a small handful of friends, my nuclear family, and a few extremely close professional colleagues. What more could I truly need?

This doesn’t mean cutting myself off from new relationships or communities. It doesn’t mean overlooking the value of networking. It mostly just means that if I have to do those things, I’ll remind myself that it’s okay I don’t like them very much and prefer dinner for two over dinner for twenty.

Subtitles v2.0.0 Released

Subtitles v2.0.0 is now available in the repository. The primary change in this version is how front-end CSS is handled. It was previously output via a call to a separate enqueued stylesheet but that wasn’t very sound for performance. In this version styling is sent via wp_head to avoid the additional CSS file mucking things up.

The reason for the version bump is because ditching styling is now done differently from how it was done in v1.0.0+. Previously it was handled in the following manner:

function ditch_subtitle_styling() {
	wp_dequeue_style( 'subtitles-style' );
add_action( 'wp_enqueue_scripts', 'ditch_subtitle_styling' );

It’s now handled like this:

if ( class_exists( 'Subtitles' ) &&  method_exists( 'Subtitles', 'subtitle_styling' ) ) {
	remove_action( 'wp_head', array( Subtitles::getInstance(), 'subtitle_styling' ) );

Download your copy of Subtitles today. Pretty soon here I’ll be adding in a way to remove all subtitles from a site, as there’s currently no way to easily do that.

Subtitles v1.0.7: Jetpack Support & Better Editing

Subtitles v1.0.7 has just been released on The two major changes in this release are default support for the Jetpack Portfolio custom post type and a better out-of-the-box editing experience on Add New Post screens (see issue).

Download your copy of Subtitles today, read over the documentation GitHub if you have any questions, and feel free to get in touch with me if you notice anything buggy about the plugin.

I was wrong about custom post type standardization.

I spent so much time thinking that implementation and the Customizer mattered in the discussion of custom post type standardization that I didn’t realize how easy this entire effort would be once the issue of meta keys was figured out. Here’s how the Testimonials standardization happened, and here’s how easy it will be to handle other post types moving forward:

  1. Someone kicks off a discussion about a custom post type that they care about.
  2. Other people weigh in and data standardization is discussed.
  3. I’ve found that providing visual mockups of data structures in discussions about data always helps the discussion.
  4. People agree on stuff, and a standard is created.

7 days. That’s how long it took for us to standardize Testimonials for all WordPress users. I don’t think it will be this easy for all custom post types but it can be if people care about it and give guidance to each other. Now it’s up to and WooThemes to adopt the standards that we’ve put forth for Testimonials. and Jetpack are on board; it’d be awesome if WooThemes also got on board.

Michael Cain at is a smart man. He helped me with thinking through CPT things during the last few days and I can’t thank him enough for his time and input.

Custom Post Types, Jetpack, Standardization, and Testimonials

Update: I was wrong about a lot of this. What follows deals more with implementation, not standardization. The standardization was much easier than I thought it’d be.

Both Brian and Justin recently wrote compelling posts about custom post type standardization in WordPress, which will become more important as the platform moves further in the direction of becoming less bloggy and more websitey.

I agree with Justin that creating standardized custom post type names is easy. He’s taken the lead on an “open set of standards for the WordPress developer community on how to name custom post types as well as related taxonomies and metadata”, which I fully endorse and encourage plugin developers and theme developers alike to look over. Naming here is not difficult, and the initial CPT list-Testimonials, Portfolios, Recipes, FAQs, and Events-is something that Jetpack and others have already started tackling.

My concern lies mostly with how users will interact with these custom post types and if they serve real needs. I’d prefer to spend less time on the ones that don’t matter right now (FAQs) and more time on the ones that do (Events). Which custom post types are most important is a matter of choice, to be sure, but if we’re able to identify one easy custom post type, standardize it, and then use that process as a precedent on which to standardize all other custom post types, I think we’ll be in a good place. The alternative is to spread our attention too thin and end up in a situation where two years down the road we’re still without some really useful tools as both themers and plugin developers.

Testimonials are the easiest to address immediately, not only because their usage is hard to misinterpret but also because they already exist on and need improvement. I do not know that Automattic has either the manpower or the want to lead the way on every custom post type, and the ones that are in Jetpack were born out of necessity in the moment. All of them are stuck on V1 because they’re hasn’t appeared to be a great need to V2 them.

We can have a very quick win with Testimonials. This is what would need to happen:

  1. Install Jetpack
  2. Install and activate the Motif theme.
  3. Go to the Customizer and stare at Testimonials in confusion.

I kid with point 3, but it does underscore my belief that we should start thinking about standardization from either within the Customizer itself first or the post and page edit screen first. The moment we bog ourselves down in the data we lose focus of how we want users actually interacting with these custom post types. I think that with Testimonials we can hammer away on the version that Automattic has built, make it better, standardize everything about it (including the experience around it), and then yell from the rooftops at Automattic to either incorporate these standards via pull requests or push back with their own ideas.

Data and naming standardization will be easy here; the experience side of this will likely require discussion.

  1. What should be included in a Testimonial? Customer Name? Customer Website? Company Name? The actual Testimonial? You get the idea.
  2. What default descriptions should we give to the Customizer controls for Testimonials? Having nothing on a Customizer screen but a section titled “Testimonials” with blank boxes is scary and confusing.
  3. Should customers be customers or clients? Or visitors? Or supporters? You get the idea.
  4. What should adding a Testimonial on a post edit screen look like?

These are the types of questions I’d like to focus on when talking about standardization. The data part will be easy if we can nail down the “How will users actually use these?” part. We can start with something already done and V2 the heck out of it to make Testimonials better for all of users and also set a precedent for how the .org world should go about implementing its custom post types.

I don’t care as much about “theme territory” and “plugin territory” discussion as others; I think the lines will always be blurred and that’s okay. But I can’t wait to see a CPT-supporting default theme in WordPress, which I briefly mentioned several weeks ago on an Apply Filters podcast. The sooner we can hop on standardizing just one custom post type, the sooner we may see that happen.

Discuss Testimonials on GitHub.