WordPress Custom Post Types & Pods: What’s Next?
On more than on occasion I’ve been asked about my future with Pods specifically given the immanent release of WordPress 3.0 featuring Custom Post Types. On the spot, I didn’t have to ponder too much, but I did want to let things seep in for a while before explaining my stance in full. There’s a lot to consider with both Custom Post Types and Pods and also a lot of theory and philosophy behind each, in my opinion. I’m going to avoid the technical details in this overview and keep it simple.
What are Custom Post Types?
First and foremost we need to understand what Custom Post Types are. I’ll try to do my best to sum them up as quickly and as easily as possible in my own words.
Custom Post Types defines our new ability to better organize more advanced content structures within our WordPress sites. That is to say, using Custom Post Types will allow us to create groups of content in addition to the stock Posts and Pages. Subsequently, we’re also able to define the data fields used in each group. Further, we’re able to take advantage of many standard features built into WordPress such as creating custom taxonomies (used for categorization among other things) and more.
If I had to label one final stake in the ground that WordPress is fantastically stating that it is no longer a “blogging” platform and instead a content platform, it would be Custom Post Types.
Custom Post Types have got a ton of attention lately, and as such deserves it. I can’t emphasize how much of a game changer this is on a platform level not only for WordPress developers, but for users as well. We’re going to see a lot of changes on the theme level which in turn will spread the word about WordPress’ adaptiveness.
Where does Pods fit in?
Now for the extended version.
Pods and Custom Post Types, although they have some overlapping functionality, don’t directly compete with one another top to bottom. Custom Post Types open a lot of doors, and I plan on using those doors as often as possible. Pods, however, is functionally superior to Custom Post Types in ways that I’ve been taking advantage of on nearly every project in recent memory.
The superiority lies in the fact that instead of being a new group of Custom Posts or Pages, Pods focuses on the relationship factor by keeping the doors wide open when it comes to how the data is displayed, how users interact with it, and how you use it. Additionally, the Pods developers are super focused on performance. That’s not to say that I’ve noticed a performance problem with WordPress, but it’s great to read that they’re focused on speed and integrity to the level of creating one-off database tables every time Pods needs one for your content types.
Pods takes a different approach entirely when it comes to the database level. WordPress Custom Post Types simply append your new content groups to the Posts table and under the hood are using Custom Fields to take care of your custom data. This is nowhere near magic to anyone who has written a plugin before that accomplishes the same thing. Attachments, for example, uses that philosophy to function.
Don’t take me wrong, I don’t think that’s wrong to do, not by any means. I always try to KISS and I think Custom Post Types do the same thing. I also appreciate, though, that Pods focuses on performance at its root.
Pods also offers more when it comes to functionality offered. Custom Post Types leave things pretty open-ended for you to get done what you’d like, but I’m not sure how easy it will be to relate one Post to another, or multiple for that matter in that group. What about relating that Post to a Post from a completely different group? What if you want to limit that list of available Posts to include a certain number of Posts from one group, and more from another? Pods has you covered out of the box.
I’ve also become addicted to the way Pods UI lets you present the Pods you’ve created. You’re able to organize and group your content types in such a way that it makes perfect sense when your client needs to hop in the driver’s seat. Pods UI is founded on built-in WordPress functions and I’m not sure to what extent it can be replicated with Custom Post Types at this stage, but I’m smitten with Pods UI and hopefully that functionality can eventually find its way to Custom Post Types.
I’ve become very comfortable with the advanced features offered by Pods, especially when Pods UI comes into play, and I won’t backtrack at this point just to take advantage of built-in functionality (my personal preference by default). I think Pods still stands on its own two feet by a long shot.
Will they blend?
That said, I plan on using a combination of Custom Post Types and Pods until a new catalyst enters which will cause me to reevaluate the situation at that point. I have a set of rules that help me build sites on top of WordPress and incorporate Pods all to make things as easy as possible for my clients to use and I will continue with that school of thought now that Custom Post Types are here.
I’ve got a lot to learn about Custom Post Types and what’s technically functional, possible, and stable. You can be sure I’ll be posting my findings along the way. I feel that Pods and Custom Post Types make a good team and will continue to do so beyond the launch of WordPress 3.0.