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.

Continue reading

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.

Continue reading

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.

Continue reading

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?

Continue reading