Feel free to disregard this post if the thought of coding, parsers and things brings you to your knees, or makes your eyes roll back. It’s gonna be that kind of post.
I’ve been working on a new WordPress Plugin for an unserved market, at least as far as WordPress is concerned, although there are a lot of peripherally similar plugins.
For this plugin, I had to figure out how to store up to 10,000+ imported items that would later be searchable, but not display on the site.
My initial solution added a custom table to the WordPress install with columns for all the various features. It also included a ton of custom code to figure out how to import the content, convert it, store it in the database and then search it.
I had an email conversation with Mike Schinkel who spent a good deal of time trying to convince me of the value of Custom Post Types in this instance, but I wasn’t willing to open my mind. I got hung up on the “Post” part and thought they were truly Posts, but I’ve learned they are more than posts.
Why use Custom Post Types (or Custom Content Types as they’re better named)? Several reasons…
- No custom tables. My solution, in a multisite environment, would have created a custom table for each blog
- Extensible. I can use custom fields, taxonomies and other constructs to extend the information.
- Forward compatible. Using the approved WordPress API for everything means better “future proofing” against change.
- Auto-indexing for searches. Everything is indexed like WordPress does for posts.
- Less coding. Yeah, I had to learn the hard way, and spend a bunch of time learning stuff, but ultimately spent WAY less time writing code. That means smaller footprint, and easier maintenance.
There’s other reasons I can’t think of, and I’m sure someone will argue against me, like I did in the beginning, but I’m beginning to see the real power of Custom Content Types.