Month: August 2012

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.