The WP Chosen plugin tames the power of WordPress’s filters, settings, and options with the simplicity and versatility of the Chosen jQuery library.

I took some time to think about the recent passing of an old friend, and concluded the way to celebrate his life (and contributions to mine) was to build and open-source something I’ve wanted for a while, the way I think he would have.


Yesterday, I tweeted about the recent Volkswagen debacle:

It got me thinking about the WordPress community, who the major players are, and where I might fit into it all on any given day.

I’ll start with Automattic and work my way across from there. Full disclosure, if you didn’t know, I worked at Automattic for a few years, so some of my observations are based on internal influences from a company half the size with a different CEO, and 4 of Matt Mullenweg’s hairstyles ago.

Automattic, is a powerhouse. They have enormous momentum that’s intimidating to compete with even when you’re trying to carve your own niche. Interested in e-commerce? Woo. Hosting? The cloud? Jetpack. Backups? VaultPress. Together they’ve solved a number of small problems in huge ways, and are uniquely qualified to do so with Matt at the helm and millions in the bank.

If you’ve read The Year Without Pants then you got a decent (if bland) idea of how the sausage is made, but my not being a part of Scott’s retelling is a metaphor for my experience at Automattic. I didn’t really bond with the team like I’d hoped, and it was the second time I had attempted to replace Andy Peatling (the first being leading the BuddyPress project) and by this time I had already felt like my reputation was in a downward trajectory.

Ironically, my experience at 10up was pretty similar. A position opened up and I was asked to follow the enormous footsteps of two beloved engineers. I failed to gel with a company made entirely of friends from the WordPress community, I never found my stride, and I still had wandering thoughts of BuddyPress & bbPress on my mind. 10up is an agency’s agency. They move fast, work hard, and aren’t afraid to kindly cut the anchor and sail on if something is dragging behind. Needless to say, I couldn’t hang.

The folks at WebDevStudios are doing awesome stuff with BuddyPress, but inside the WordPress community I’ve heard people say some surprisingly negative things about them. Code quality being bad, they’re unprofessional, etc… I don’t see it, I haven’t seen it yet, but if it’s true, these criticisms aren’t unique to WDS. I’ve seen worse code and experienced less professionalism from other hugely successful businesses. If those are WDS’s only problems, they are the company to bet on. They’ve doubled in size since last year, and aren’t showing any signs of slowing down.

My friends at HumanMade have a reputation for contributing huge amounts of time & effort to pushing WordPress as a platform farther than even the folks at Automattic have been able to pull off. I think this is accurate; they’re a talented bunch of engineers that love WordPress but aren’t consumed by it, which pays off by allowing them to influence it’s direction gently and with outside perspectives.

CrowdFavorite is, well, a favorite of mine. They’re an agency that’s known for going after and catching the whales, and being coy (in a good way) with the stories of how they caught them. From my perspective, they’re the agency that goes their own way and likes to challenge the WordPress status-quo, which is to say I like them a lot.

Pippin Williamson and his team have a reputation for their enormous momentum and huge earning potential if they maintain their current pace. Output, output, and more output. It’s intimidating, and inspirational, and having known Pippin a long time, I’m both happy for him and proud of what he’s accomplishing.

There are a bunch of other businesses, agencies, and independent WordPress developers out there, so it’s difficult to cite examples without injecting my own biases or forgetting some really influential people. Envato, Alley, Voce, Range, Reaktiv, WPEngine, Pagely, XWP, and on and on…

And me? Some days I feel like my ideas are far-fetched & silly, or the entire WordPress core team is against me, or they feel like I’m working against them even though I’m trying to work a few steps ahead without being a distraction. The rest of my days are spent working on my own little corner of the internet trying to mop up what’s left of the mess of my own career, since I’m back where I started 5 years ago with some added experience & perspective, and maybe a chip on either of my shoulders about it all if I’m being totally honest.

It reminds me a bit of an article about Jonathan Blow in The Atlantic in 2012, who earned a funny reputation in the video game industry, and once he had the zeroes in his bank account to prove his voice had value, his voice suddenly did have value. The same voice, but being backed by currency gave it breadth and range.

In many ways, his opinions of his industry are not dissimilar to mine with WordPress (though when given the opportunity I try maybe to be a bit less brash to the people pouring their hearts into their passions with their own foibles and comeuppances.)

There are a lot of similarities between the independent game scene and what’s going on with WordPress right now. There are huge, major players taking on and solving massive problems at a scale that no 1 individual can compete with anymore, but that also means there’s opportunity for someone to identify one specific sharp snaggy corner and file it away so no one hurts themselves on it again. I hope Flox achieves that with it’s offerings; I hope we manage to produce something widely popular so I can afford to relax for a while; I hope to earn a better reputation than I feel like I have with my colleagues and friends through cool & valuable output.

Reputations are usually accurate, and surprisingly fickle. One person or company can devote their entire focus to something and lose it instantly, while another can have questionable ethics and still manage relative success. My point, I guess, is that reputations are earned one way or the other.

It’s scary, and rewarding, but it’s easy to get caught up in the distraction, politics, and bureaucracy of it all, and accidentally live up to people’s perceptions of who they think you are instead of who you know you are and what you’re capable of achieving.

Focus less on reputation, and more on ethical output, and you’ll be just fine.

With each new software release that I’m fortunate enough to contribute to, I usually take some time (or lots of time) to reflect on a few different things that I think are critical to the project and myself:

  • What went right?
  • What went wrong?
  • What did I learn?
  • What can I do better?

With BuddyPress 2.2 imminent, here’s a brain-dump of my random and unrelated thoughts for January 2015, in no particular order:

  • Significant improvements have been made to cache-coverage, but many more are necessary, and some of our existing implementations are not ideal.
  • User statuses are pretty messy. A user’s status is a numeric value in the users database table, and there is no API in WordPress for interacting with it. Just like post statuses, anyone concerned with workflow (or activation flow in this case) is pretty much on their own.
  • The Member Type API is sweet, and I’m excited to see how developers use it. Hopefully I get to use it myself soon.
  • It seems like each ticket takes longer to test, confirm, fix, patch, and push.
  • How strictly do we enforce cache coverage, unit-test overage, inline documentation coverage, and all of the other nuances? I fear we are over-complicating each others lives with anti-progress and slowly forgetting what made BuddyPress fun to work on in the first place.
  • I need to write more unit tests.
  • I need to increase cache coverage.
  • I need to write more inline documenta… Ehh… maybe I’m okay here.
  • I sure wish PHPUnit were faster and easier to run. Netbeans has decent integration, but I haven’t figured out how to efficiently implement it into my workflow.
  • It’s been really great not juggling immense client and customer expectations in January, thanks to the funders of my recent IndieGogo campaign.
  • The old BuddyPress Default and Legacy templates are starting to look really out-of-date to me now. I wish we didn’t have so many templates to style and that creating themes was easier.
  • I continue to struggle with the cost of switching contexts during the day, between writing code, impromptu meetings, and random pings. Working nights used to help with this, and I need to come up with a healthy plan to improve my ability to come back to things once I switch away from them. I feel like I used to be better at this when I was younger.
  • That squirrel outside my window is looking pretty well fed considering it’s January.
  • I bought too much Lego over Christmas.
  • I need to take more small breaks and be more physically active during the day.
  • I need to prioritize blogging.
  • I need a nap, and it’s only 11am.
  • BuddyPress 2.2 is going to be sweet.
  • Boone did a really good job juggling both WordPress and BuddyPress core development. Note: be more like Boone, at least in this capacity (I don’t think I can eat that much pizza anymore.)
  • I’m excited for a vacation my wife and I are planning in March to celebrate our wedding anniversary. It will probably be much needed by then.
  • I broke my ankle 1 year ago, and it’s still not quite right. Likely won’t ever be the same I suppose. Guess I’ll never play the piano again.
  • Penny (our new rescue puppy) tested positive for heart-worm. Poor thing. Hopefully it’s not too bad and we get her all fixed up.
  • You are great. <3

I’ll probably regret making this, but here we go…


Yosemite Sam from:

Yosemite from:

Responsive design has become a quick-and-dirty way to say “Hey! We looked at this on not-just-a-PC!” Our users deserve so much better — something that intentionally works with the ever-increasing array of input methods. Keyboards, cursors, touch, voice, & motion; the digital world has never been simultaneously as accessible and as overtly complicated as it is today.

Netflix does a pretty good job at wrangling the chaos, designing experiences around the input method, reducing touches and navigational elements on more simple devices and taking advantage of all available screen real-estate to maximize an interfaces usefulness.

Maybe we’ll call it “Input Aware” or “Device Aware” design — I guess I don’t really care about the name as much as distinguishing the approach from the myriad of responsive hacks and shims floating aimlessly around our collective github toolboxes.

I was recently reminded of the spectrum of media-types available to the CSS2.1 media spec, which largely got me thinking about how bad we are at utilizing them:

  • all — Suitable for all devices.
  • braille — Intended for braille tactile feedback devices.
  • embossed — Intended for paged braille printers.
  • handheld — Intended for handheld devices (typically small screen, limited bandwidth).
  • print — Intended for paged material and for documents viewed on screen in print preview mode. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • projection — Intended for projected presentations, for example projectors. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • screen — Intended primarily for color computer screens.
  • speech — Intended for speech synthesizers. Note: CSS2 had a similar media type called ‘aural’ for this purpose. See the appendix on aural style sheets for details.
  • tty — Intended for media using a fixed-pitch character grid (such as teletypes, terminals, or portable devices with limited display capabilities). Authors should not use pixel units with the “tty” media type.
  • tv — Intended for television-type devices (low resolution, color, limited-scrollability screens, sound available).

CSS2.1 even comes with a handy media-groups spec to pair media-types to devices based on their anticipated attributes:

Media Types Media Groups
continuous/paged visual/audio/speech/tactile grid/bitmap interactive/static
braille continuous tactile grid both
embossed paged tactile grid static
handheld both visual, audio, speech both both
print paged visual bitmap static
projection paged visual bitmap interactive
screen continuous visual, audio bitmap both
speech continuous speech N/A both
tty continuous visual grid both
tv both visual, audio bitmap both

Typical responsive design approaches target the screen type (and maybe print) which is accidentally celebrating doing-responsive-design-wrong. To correctly respond to different devices, we need to target more than max-width and min-width in the screen media-type, and let browsers and rendering engines on our televisions and refrigerators do their jobs.

Unfortunately for me, the software libraries I live most of my life in right now (WordPress, BuddyPress, and bbPress) are all pretty bad at this. The WordPress iOS app is a crippled version of WordPress’s relatively fantastic interface; WordPress itself barely functions on small screens and touch devices; BuddyPress & bbPress do the bare minimum to inherit surrounding styling, but don’t own the experience or set a great example in this regard as much as they might in others.

The greater tech community needs to target more input devices, intentionally design better experiences, and stop patting ourselves on our backs for doing the bare minimum of design.

Sure… it’s an iterative process, and yes… we’re all working hard and putting in the long hours together to improve the digital world around us, but it’s a great time to lift up our heads, unsquint our eyes, and design for the world around us instead of for ourselves.

If you use Netbeans on Mavericks, and updated to Beta 6 (Build 13A558) you may have noticed your menu bar items fail to appear, looking something like this:

Netbeans no Menu

This comes from the default Java menu bar nib files being accidently removed from the build: /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/*.lproj/DefaultApp.nib

The workaround is to install the full Java SE 6 JDK from This reinstalls the Java SDK in the correct locations, and will be deleted on the next Mavericks update (so there’s no harm in this temporary fix.)

By default, Netbeans keeps dot files and directories hidden from the project tree. If you want to show them, never fear — there is a way.

Preferences > Miscellaneous > Files > Ignored Files Pattern


Basically, remove the .* at the end of the regular expression, and you’re good to go.

I’ve fallen into a routine when building WordPress plugins; a few general rules are:

  • Avoid creating new PHP globals.
  • Avoid executing PHP code in the global scope.
  • Generous use of Actions and Filters.

I’ve decided to name the pattern I use Slash, which stands for:

  • Singletons
  • Loaders
  • Actions
  • Screens
  • Handlers


I didn’t love singletons in PHP at first, and I’m still not convinced they are ideal, but they work well at avoiding yet-another-WordPress-related Global variable. bbPress is a good example.

The benefit of using PHP singleton’s in WordPress is they don’t create an additional PHP global to worry about getting stomped. They also allow your plugin to always exist in memory, without another plugin being able to unset it, while still working like a traditional PHP class.


These are basically bootstrap functions. Their only responsibility is to jumpstart a singleton, and put it in a place for easy access. See the bbpress() function in the above bbPress link. Loaders allow you to reference your Singleton without needing to use a global variable, or pass an instance around into functions and method calls. Used like: bbpress()->foo = 'bar';


By hooking everything into WordPress core actions, bbPress never runs any code inline in the global scope, other than the above loader function. Also, bbPress comes with it’s own sub-actions to piggyback WordPress’s, making writing bbPress specific plugins safe and simple.

This also includes WordPress Filters. The major difference with Filters is that they are generally more risky to use; you have to assume other plugins are already using them, and those same plugins aren’t designed to handle whatever you’re trying to do too.


Derived from BuddyPress, screens are basically “Views” if you’re familiar with MVC. They are how we output markup to the browser from inside PHP, WordPress, and our plugins. Screens can be modular (again, see bbPress) allowing them to work with shortcodes, widgets, and template parts. Screens typically contain all of the translatable strings and HTML markup, and sanitize any variables for output.


Handlers are the equivalent of controllers in MVC. They are responsible for containing the logic that comes from requests like forms, AJAX, JSON, XML-RPC, etc… They “handle” whatever the request is, performing capability checks, validating input data, and also checking for nonces.

Why not use MVC?

Honestly? No reason. Slash isn’t intended to compete or replace anything, and like anything else it’s constantly evolved over time to become what it is today, and will likely change tomorrow too. MVC and other architectures work really well, and Slash is just an approach that’s worked well for me. Putting a name on the routine should help it grow, or educate me on better approaches.

It’s also worth noting that Slash isn’t really anything new, but rather an assembly of separate methodologies combined into a single process that helps me translate my thoughts into code.

The best way to see the Slash approach in action is to browse through the BuddyPress and bbPress codebases. If you’re an experienced developer, I’m always looking for feedback. If you’re just starting out, maybe give the Slash approach a try. Take what’s in bbPress and remix it for your own use, and let me know how it goes.