One of the things that Pippin, Norcross, and I have been talking about during the course of building Comments Not Replied to is the best practices for instantiating WordPress Plugins.

Specifically, we’ve gone from simply creating an instance of the plugin, to storing it within the PHP $GLOBALS variable, as well and then debating whether or not to implement the plugin as a singleton.

There’s more to this that I’ll cover in a follow-up post, but the most significant thing worth sharing in this post is why we’re discussing how to instantiate our plugin.

Continue Reading…

One of the nicest and most flexible aspects of the WordPress API is the ability to associate meta data with certain models – for lack of a better term – in the database.

That is, we can assign meta value to Users, Posts, Authors, and so on.

Retrieving the data is typically trivially easy. Simply supply the ID of the model in question and then pass the key value for said post meta.

But what if you need to get the post ID or post meta key by the meta value instead?

Continue Reading…

When it comes to WordPress development, there typically tends to be two camps (with a third that’s on the rise):

1. There are theme developers
2. There are plugin developers
3. Then there is the growing field of application developers

Personally, I’m a fan of building plugins. Obviously, it’s not because I have anything against building themes, but I’m a programmer – not a designer – by nature, so I add to the WordPress experience through functionality rather than functionality and design.

In fact, I think if I had to design, it’d probably take away from the experience .

But plugins are software and there are problems that have existed as long as software has existed. In fact, entire markets have been created around said problem: filing bug reports.

I’m not here to provide the ultimate solution for how to provide a WordPress plugin bug report – if that existed, it would have been solved long before today; however, I do want to share a couple of things that I’ve noticed.

Continue Reading…

If you're an experienced developer, you may wish to skip to the code.

If you’ve ever done any work with building a plugin or building a feature of a theme that includes a custom meta box or that includes functionality that is fired on the save_post action, then you’ve likely seen WordPress save_post called twice.

The thing is, this is expected behavior, but because of how it’s used, you may not always want your code to execute until the user actually clicks on the save button.

So here’s a quick tip on how to properly manage the case when save_post is called twice.

Continue Reading…

If you're an advanced developer, then you may want to skip directly to the code.

As soon as you begin working on an advanced plugin or an application in which you try to maintain some form of solid cohesion (or even an API), then you end finding that there’s a function you need that isn’t available in the Codex.

This isn’t unique to WordPress. Any programming language that has a rich API ultimately has a set of solid features that allow you to build upon them to write more power functions.

For me, I try to publish most of my helper functions here on the site. It makes things searchable, available, and even available for code review for the more critical readers .

Case in point: In a recent project, I needed to find the permalink by slug in WordPress and there wasn’t a function available to do exactly that, so here’s what I ended up doing.

Continue Reading…