Orange Flower


Rants WordPress

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.

Software WordPress

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.

bbPress WordCamp


A highlight from my bbPress presentation at WordCamp San Francisco 2012.

[wpvideo tG3NrSDs]

BuddyPress Software WordPress

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.