Before Google practically destroyed the word ‘beta,’ people used to go about getting feedback on their work through closed testing, tight feedback loops, and other forms of getting work in front of others in a closed group of people to see how a sample of users would interact (or just simply react).

Movie production companies still do this – they test audiences: They see how they react to certain actors, certain endings, certain takes, and all that fun stuff.

In software, we still do that, but we throw words around like alpha and beta to the point where they have no real meaning anymore. At one point in the life of projects, alpha testing was solely for an internal group of testers, then beta testing was when it was open to a small group of people in the public in order to gather more feedback and to shake out bugs. Then there were release candidates followed by the final version (or the 1.0).

After that, we rinsed, and we repeated it.

Now, far more people have access to alpha-level software, and projects usually remain in beta as a way to excuse any problems that may occur during the course of using the application. After all, it is beta, so it’s use at your own risk, right?

Anyway, I could say a lot more on this, but I digress.

Continue reading

If you’re in the business of creating WordPress plugins for yourself or for others, then it’s likely that you’ve done work with custom post types.

On top of that, there’s a chance that you’ve needed to introduce some functionality into a custom post type based on what’s selected in the plugin settings (which I discussed all of that fun stuff in a previous post).

And I’ve seen a number of different ways in which this is done: Some of them involve complexity such as reading the select post types into an array, iterating through the list, comparing the current post type, setting a boolean, and so on.

But there is a cleaner way that this can be done. I’m not claiming it’s the best way (perhaps you could share some insight on your opinions on this in the comments), but it’s way that I’ve found useful and that I’ve been using a few times over throughout several projects.

Continue reading

As I’ve been working through a number of different plugins both for myself and for client projects, one of the things that has started to become glaringly apparent over the last few projects is just how unintuitive WordPress plugin settings can be.

I know, isn’t a new idea, but bear with me because I’m not talking about your standard run-of-the-mill plugins that have a settings page or that may add some type of shortcode functionality to the editor (though that’s unintuitive unto itself).

Instead, I’m talking about plugins that include a little bit of both: settings pages, additions to custom post types, perhaps the additions of shortcodes or buttons to the editor, and so on.

Continue reading