I think that one of the more underestimated aspects of building solutions with WordPress comes with leveraging custom post types and custom taxonomies.

For those who are currently building products for others – be it plugins, custom themes, or web applications – then you’re likely familiar with how powerful these two features can be.

Specifically, if you’re used to the ideas of models and views, or data objects and a presentation layer (or whatever language your framework of choice uses to describe this information), you can think of custom post types as a bit of a hybrid of models and views.

Similarly, you can think of taxonomies as an easy way to stamp your data – in WordPress, we think of these as categories and tags – but sometimes, I think the terminology may limit us in thinking how we can leverage the features.

Nonetheless, if you’re used to working with WordPress, custom post types, and custom taxonomies, then you’ve likely faced a time when you’ve needed to query information based on a combination of the two.

And though there are a variety of different ways to retrieve custom post types and how they are tagged, here’s one way to grab information that’s stamped with multiple taxonomies.

Continue reading

This is post two of two on how to upload files in WordPress and created associated meta data. Read the first post here.

In the first post in this series, I mentioned that I’ve been working on a plugin in which the users needs to upload a file to a custom post type without the use of the Media Uploader.

This is basically done via use of an `input` type of `file`, WordPress `nonce` values, and some basic PHP functionality, but if you’d like to read more, then be sure to review the first post.

As mention in the first article, the second part of being able to store files and their associated meta data is so that you can also remove the files (and the meta data) when the user triggers the appropriate action.

Specifically, the plugin must do the following:

1. Verify the request’s incoming `nonce` value
2. Use (or somehow retrieve) the specified meta key for the file to be deleted
3. Delete the file from the file system
4. Remove the database entries – that is, the meta data – associated with the file

Just as in the last article, we’ll take a look at each step and the code required for each, as well.

Continue reading

You’ve gotta be prepared for the future, just in case you end up there.

For those of you who have read this blog long enough, you know that I’m a big advocate for using WordPress for web application development.

No, I don’t think it’s the end all, be all of foundations for web applications, but it’s one that shouldn’t be overlooked depending on the nature of your requirements.

Anyway, a friend of mine recently contacted me asking what I do to future proof WordPress when I begin to use it build applications on top of it. Specifically, he asked what steps I take when working on projects that may end up breaking with the next WordPress upgrade.

Since I don’t recall ever sharing the steps and tools that I use, thought it would be good to cover here.

Note that these aren’t all the things that I do or that can be done (and I’m sure you guys have some great suggestions, too), but these are the things that came to mind that I’ve found to be absolutely critical.

Continue reading