Articles, tips, and resources for WordPress-based development.

The Importance of Following The WordPress Coding Standards

Today, I’m attending WordCamp Atlanta. I’ll be speaking on the topic of The Importance of Following The WordPress Coding Standards.

The WordPress Coding Standards

It’s been a couple of years since I was able to attend a WordCamp (primarily because my wife and I were growing our family and welcoming additional humans to Planet Earth :).

Anyway, I’m excited to be back.

Avoid Loops With save_post in WordPress

When working on WordPress projects, there may be times during which you have to do some sort of processing on the content or attributes of the post before saving it to the database.

There are a number of ways to do this, but one of the most straightforward ways to go about it is to setup a custom function hooked to the save_post action and then handle the attributes of the post in that function.

If you opt to go this route, there are a few considerations that you need to make (mainly that help you avoid some type of infinite loop) in order to properly adjust the content to your liking.

Debugging with Query String Parameters

There are a number of ways that we debug our WordPress-based projects.

  • Some people end up going through the code and setting up print_r statements or var_dump statements
  • Some end up working through the code and changing variables or function names until they find where something breaks (or changes)
  • Some use debugging software (or the debugging features in their IDE)
  • Some use a combination of plugins and other techniques
  • And some likely use some strategy that isn’t listed here

Personally, I’m partial to using some of the developer tools that are provided by WordPress through the use of setting constants and using plugins that are available to us, but I’m also a fan of using Codebug App (which is the content for another point).

Codebug App

But, for the purposes of this post, that’s beside the point.

The Basics of How WordPress Works

If you’re getting started in WordPress development, odds are it won’t be long until you bump up against the concept of hooks. That is, points during the WordPress life cycle that allow us to add our own functionality to customize how WordPress behaves.

Of course, this is how both themes and plugins are made to do some of the neat (or not so neat, depending on the project) things that they do. And though I obviously recommend reading up on them in the Codex, I think it’s also important to understand how the WordPress application loads itself.

More specifically, I think it’s important to understand how WordPress works. There are a lot of resources out there available to read and review; however, John Blackbourn has been working on a no-frills version of this very idea that I believe to be worth starring and referencing.

On WordPress Theme-Specific Plugins and Theme Lock-In

When it comes to working with WordPress themes and plugins, there’s a general rule of thumb that most experienced designers and developers follow:

Themes are for presentation, plugins are for functionality.

Sure, there’s a little bit of blurring of lines, but this is the goal for which we strive when working through our code. And yes, there’s a lot that can be said (and has been said) about themes that include a ton of features, options, bundled plugins, and so on, but that’s not where this is going.

Instead, I’ve been thinking about how this relates to general theme development, niche theme development, and using WordPress as a platform for application development.

Code Quality Is Not a Feature

One of the things that I think is easy to forget about working within the WordPress space is that we’re often talking to a circle of [many of] the same people. By that, I mean that developers are largely talking to other developers (and likely some designers), designers are talking to other designers (and likely some other developers), and so on.

I mean, I have no expectations that anyone who reads this blog is outside the scope of someone who writes or wants to write WordPress code.

And though there’s nothing inherently wrong with this – I mean we’re naturally all about creating groups and communities – I think that it can negatively influence how we may be marketing our products or even discussing our work with other people.

In fact, I’d argue that one of the biggest problems that we have as it relates to marketing our WordPress projects is the fact that we use phrases “clean code” or something similar when trying to sell others on our work.

What Are WordPress Theme Extensions?

Most experienced WordPress developers will likely make the case that themes are for presentation and plugins are functionality. I agree with this and it’s something that I try to take into account with each project that I work on.

That is, whenever I have a project that consists of some unique functionality, then I’ll build out said functionality into a plugin and then either advise the customer or the user of the theme to download the plugin (for which there are some great tools available for this) or I’ll include it in such a way that the theme will include it and activate it.

Honestly, I’m not a big fan of the latter – it assumes the user doesn’t already have a version of the plugin installed, it creates a dependency that’s harder to manage, and it’s activating something that the user may not want activated even though we may see it as something that’s crucial for the site to function properly.

This is something that could probably be argued ad nauseam and though that’d make for a lot of fun in writing up a blog post and chatting in the comments, that’s not the purpose of this post so I digress.

Instead, it’s to offer up the idea that perhaps there are shades of gray as it relates to building specific functionality for highly niche themes.

On Maintaining Free WordPress Plugins

If you’re ever interested in getting into WordPress plugins, then there’s a wide array of material available for you to read – this includes material across who-knows-how-many blogs, people on Twitter, and even physical books available on Amazon or likely your local bookstore (well, maybe – heh).

But when it comes to building and maintaining a free plugin (let alone several), I’ve found that there’s not as much discussion, sharing, and overall dissemination of information available. To that end, I thought it might be worth looking at four things that I’ve found useful when maintaining free WordPress plugins.

Is There a Lack of Integrity in WordPress?

A few years ago, I was working on a WordPress theme that had some really cool features (if I can say that without sounding as if I’m bragging). The features were brainstormed by a team and gathered through feedback through a number of customers and users, and all were implemented over a long period of time.

When the time came to actually release the theme, it proved to be worth it – it was well-received.

As with any product, we then went into maintenance mode doing the usual round of fielding bug reports, features requests, and so on, and then continued maintaining the product with periodic releases in order to provide bug fixes, minor feature updates, and so on.

Generally speaking, it was great. There was a lot to be proud of and things were going well.

But, as with anything, things couldn’t continue on the up and up forever and during one of the releases, I neglected to remove a line of code that was intended only for the development environment.

We shipped it.

And it negatively affected all of the customers who applied the update.

The Versions of WordPress and PHP

One of the biggest challenges that comes with working with PHP and WordPress is determining which version of PHP to use.

From the WordPress.org Requirements page:

PHP version 5.2.4 or greater (recommended: PHP 5.4 or greater)

With respect to PHP, a lot has changed between 5.2.4 and 5.4. And the problem, for developers, usually comes down to something like this:

If we opt to stick with the oldest supported version then we have the largest audience appeal, but if we stick with newer versions then we get some nice, new features in the language but at the expense of certain hosts.

So when it comes to WordPress and PHP, what do we do?