Contributing to WordPress, BuddyPress, & bbPress

Siobhan McKeown recently authored an amazing post at Smashing Magazine about contributing to WordPress. I was fortunate enough to have the opportunity to share some of my own thoughts, mostly surrounding BuddyPress and bbPress.

If you’re a part of the WordPress community, this is a great read, with ideas and suggestions from a few of the most iconic WordPress contributors. I’ll leave you with my two favorite snippets from my pals Matt and Mark:

The number one skill you need for just about any job, but specifically working on open source, is communication skills. You need to have clarity, consistency, compassion, relatability, a little bit of a thick skin and a decent sense of humor. — Mark Jaquith

You can’t knock on the door at Google and say, “Hey, do you mind if I help you out with your home page? I have some ideas for you.” But you could come to us and say, “Hey, I have some ideas for your dashboard, and here are some patches.” — Matt Mullenweg

SLASH Architecture – My approach to building WordPress plugins

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

Singletons

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.

Loaders

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';

Actions

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.

Screens

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

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.

PHP5 Visibility and WordPress

tl;dr – PSA about PHP5 visibility and it having the potential to change what we love about WordPress. Ergo: use it correctly.

—-

Leading projects like BuddyPress and bbPress, I tend to work closely with the WordPress team and mirror the development paradigms as much as it makes sense to. We’re doing tandem development, after all — it’s like pair programming, but from 1,000 miles away and with less spooning.

As of WordPress 3.2, the minimum requirement for what PHP version WordPress would run on was upped to 5.2.4. With this, came the ability to determine the scope of class variables and methods. This can be dangerous if used incorrectly, and extremely relieving for everyone else when used correctly. Even though the world of PHP developers outside of WordPress have had this for years, many of us are only recently getting our feet wet.

Part of what makes WordPress popular is its low barrier of entry. Watching any person, at any level, of any skill-set, immediately influence code that +40 million people use (and exponentially more interact with) never ceases to amaze me. As a developer of 18 total years (14 professionally if I count a small hiatus) what makes WordPress as a project different to me is how the lead team has maintained its global and procedural nature.

Ask someone that’s not a WordPress developer, and they’ll tell you that the reason they don’t use WordPress is because the code is antiquated, or inefficient because of the way that it was architected from the beginning. They want more objects, MVC, or some other trendy and fun way of doing things. I don’t disagree with them, but I think the procedural code style is actually what make WordPress strong; it’s simplicity is easy to understand, it’s easy to figure out what the code is doing at a glance, and you’re able to trace code back with relative ease compared to other more complex coding paradigms.

In most of WordPress, developers have unlimited access to directly manipulate global values. This makes for an unpredictable environment, but also means there are no training wheels; if a plugin goes rogue and nullifies the $post global, that’s what it intended to do, and that’s just how it works.

Since WordPress has been restricted to PHP4 for most of its adult life, so have theme and plugin developers. As such, the power to protect your code with private and protected variables and methods is pretty awesome. We can finally prevent other plugins from messing with our code, which is a great and amazing ability. I’ve seen a few places where class variables were protected or private inside of plugins (even by developers that I love and respect) which makes it impossible to extend or manipulate that code. If it’s done really poorly, it might not even be possible to repair that API without creating a new one.

Maybe these decisions were made on purpose; maybe it was not knowing any better; maybe it was copy/paste from some tutorial somewhere. What I do know is it’s frustrating to be on the receiving end of poorly architected code, and PHP5 visibility introduces problems that the WordPress community hasn’t had to deal with for very long.

Whatever the case, it’s frustrating to drill down deep into something, only to find you can’t drill through the last few inches.

One could argue there are currently places in the WordPress core code that should be on lock-down — and that might be true; but being able to manipulate almost *anything* at runtime is, for me, a major part of what makes WordPress appealing and fun to use.

I purposely kept the good/bad code examples out of this blog post, as I plan on doing a more technical write-up later on our developer blog. Anyhow… If you’re a WordPress developer, and you’re unfamiliar with PHP5′s visibility, look into how it works and how WordPress core uses it now. By using it appropriately, you’ll help your future self, your team, your users, and any other developers that might be interacting with your code.

WordPress as an Environment

As WordPress has matured over the past few years, my perspective has shifted to think of it as the environment I develop in. I no longer really associate myself as being a PHP developer, a front-end or back-end developer, an architect, or a designer.

This both scares and delights me.

To be a good WordPress developer, it helps to understand how all of the skills come together to create the perspectives I just mentioned, and how they apply specifically to WordPress — far beyond the conventions of everyone’s favorite PHP stack.

  • Front-end WordPress development requires knowledge of WordPress’s theme options, template tags, template hierarchy, theme hierarchy, and action order.
  • Back-end WordPress development requires knowledge of WordPress’s object cache, action order, what filters to use when and why, when to use custom tables, and having a plan to scale beyond WordPress’s built in table schema.
  • Architecting for WordPress requires extensive knowledge of WordPress’s action order, WordPress’s included functions and APIs, the WordPress coding standards, and liberal use of phpdoc and inline documentation.
  • Designing WordPress themes requires an intimate knowledge of what WordPress is actually designed to do, and then being able to think outside of that box to create visually stunning sites that push WordPress to it’s limits.

Because of this, it’s safe to say WordPress is our environment now, and PHP is just the platform it runs on. WordPress is popular and complex enough now where it’s a great time to specialize on one area, and become the go-to person in that area. Taking this a step further, focusing on individual plugins or themes is actually where we are today.

Part of what makes being a WordPress developer so fun is being able to load-up a new installation and start creating new and amazing things in a matter of seconds. As WordPress evolves with smarter warnings, sandboxing of plugin activations, and doing_it_wrong() notices, we’re watching WordPress shape-shift from a bunch of PHP scripts on a server, into the environment we create, live inside of, build enhancements for, all while individually influencing it’s direction.

It’s at this point, WordPress and it’s community of contributors deserve much more recognition and thanks than they usually get.

Building an environment, is hard to do.

“WordPress as an Environment” is what comes next; a future where WordPress shields us from annoying things it can detect and protect us from, both as users and developers; an environment where WordPress can detect two plugins are trying to perform the same action, and safely prevent conflicts; one where several posts of different types will be allowed to have the same slug without colliding with each other. More over, I can’t wait until WordPress allows plugins to register template parts, so completely theme-agnostic features can be built with no additional effort. (BuddyPress, bbPress, Shopp, and WP eCommerce are making huge strides here.)

When you think of WordPress as an Environment, you realize how much we depend on WordPress core to protect us from ourselves and each other. A future where the correct safeguards are in place to help us not shoot our own feet or get caught in cross-fire is one I hugely look forward to.

Custom Plugin Header Image Label

Back in December of 2011, Matt and friends added the ability for WordPress plugins to have really pretty header images. For BuddyPress, I went through a few design iterations before settling on the header image pictured at the bottom of this post. I wanted it to be minimalistic and unique, so I took an hour to extend the label area with the buddies at the end. Below is the basic approach to make that happen:

  • Take a screen shot of the header image without the extended icon area.
  • Open that screen shot in Photoshop or your favorite image editor.
  • Make a new layer.
  • Fill the new layer with a black close to whatever the primary color of the label is. (#181818)
  • Hide that layer, select the background layer.
  • Magic wand the label.
  • Extend the selection to the size you want it to be (Usually 50px or so.)
  • Switch to your all black layer.
  • Right click; Select inverse; Delete.
  • Tweak the opacity of your black layer to match as closely as possible. Take your time with this; even if it’s the slightest bit off, it’s pretty noticeable.

Retina 2x downsampling

While working on some 2x retina images for WordPress.com, and the bbPress and WordPress open-source projects, I found an image rendering issue that I haven’t seen documented anywhere yet. Here’s the WordPress core retina ticket, for reference.

The first image highlights the difference between the WordPress core 2x icons, and the bbPress 2x icons. Notice how the icons next to Forums, Topics, and Replies have a slightly thicker black outline, specifically in 2x mode. The icons next to Posts, Pages, et all, are WordPress’s icon32 equivalents, with the same border thickness as the original 32px icons used in the 1x headers.

Using the original 32px icons was a great idea for a first-pass win at having 2x icons in WordPress core, and there are 64px equivalents now too! The difference between the WordPress and bbPress icons is subtle but important when you look at the second image in the gallery.

If the browser loads 2x images, but the display (for whatever reason) renders in 1x mode, you naturally end up with downsampled 2x images. To purposely duplicate this behavior:

  • Have a Retina MacBook Pro.
  • Connect Cinema Display.
  • Open Safari.
  • Move Safari 50% between the rMBP display, and the Cinema Display.
  • Watch any 2x images downsample to 1x size.

While edge case, the circumstances where a browsers’ calculated pixel ratio does not match the display are a new bug from a new convention. Arguably, operating systems and graphics cards should handle this more smoothly, and I suspect they will eventually. Until then, if the risk is providing a worse experience than plain-old 1x images, it’s our responsibility to include 2x images that will downsample to a usable state in 1x mode.

Weird, wild stuff!

Confessions of an Open Source Workaholic

Hi, my name is John, and I’m an Open Source Software workaholic. I touched on it a bit in my WPCandy interview, and I thought I’d finish the story here with a few added thoughts.

I live in a great neighborhood on the east side of Providence, RI. I work from home, rarely drive my car (ignore the frequent road trips), and enjoy the luxury of being walking distance from food, laundry, spirits, and anything else I might need to live a happy and comfortable life.

By day, I work for Automattic. I love my job. I love my colleagues. I love everything about what I do. To say it’s a dream job is an understatement. I work on some really awesome stuff going on around WordPress.com, Jetpack, Gravatar, and try to poke my head into other interesting social bits as much as possible.

By night, I’m the lead developer of bbPress, BuddyPress, and maintain both of the bbPress.org and BuddyPress.org sites. I believe both projects are two of the strongest spokes attached to the WordPress hub, and it’s my pleasure and privilege to be so closely involved with them. I am passionate about their success and enjoy iterating and improving them both equally, and love to help their users whenever I can.

That said, I’m in a unique and misunderstood position.

I work 40+ hours at a job that I love. Most days when I’m done with work I switch gears to my hobbies; usually that’s bbPress and BuddyPress. Other days, I enjoy going to the park with my dog Paul, watching Netflix, or enjoying a nice meal with friends.

In 2010 and 2011, I had the pleasure of mentoring some really bright individuals as part of the Google Summer of Code and the Google Code In projects. Gautam Gupta, a 15 year-old student from India, placed 6th by working closely with me contributing to the first major release of bbPress in two years; helping to totally refactor bbPress into a plugin for WordPress, skyrocket its popularity, and reinvigorate something great that hadn’t had much attention in a while.

My point, is that working on the bb’s is not something I am directly paid by Automattic to do. Instead, my job at Automattic enables me the means to keep my skills sharp *and* work on the software that I love, at the same time; it allows me to spend my free time giving as much back to the community as I am willing and able to. I choose to concentrate on bbPress and BuddyPress.

While Automattic does donate the time of several full-time people directly back into WordPress, and while it benefits Automattic as a business to be coupled so closely to its active development, it is not Automattic’s responsibility to staff anyone to contribute back to any open source project anymore than it is your own to do the same.

WordPress is free and open for anyone to build off of and dedicate resources towards. The bb’s are both free and open like WordPress is, with a lower barrier of entry to make a a much larger impact. If you’ve ever been intimidated by the amount of activity happening around the development of WordPress, or have been afraid your contributions aren’t good enough: 1. you’re wrong; 2. use the bb’s as your training ground.

If you choose to stick around and help work on the bb’s, your influence carries more weight because there are fewer people contributing. Dedicated contributors walk up the ranks quickly, earning core commit access like Boone Gorges, Paul Gibbs, and I with both BuddyPress and bbPress. We’re not the founding developers, we’re the currently active ones, and we would love to have your help. From code to codex, everything is an iterative work-in-progress.

Who knows, maybe eventually you’ll be an open source workaholic, too.