Data portability within WordPress is a big deal. However, best practices regarding how to properly make data portable are hazy at best. Where should custom post types be defined? What should happen to the data when a user switches themes?
In this post I will attempt to summarize the various arguments, point out one overlooked fact, and offer a limited solution that can be implemented regardless of your particular views on data portability.
Attempted Summary: Themes vs Plugins
For the sake of simplicity, I will be discussing data portability as it applies to custom post types. It seems that the true question that everyone is trying to answer is this:
What is the most user friendly way to implement theme-related custom post types, and what should happen to the data when a user switches themes?
For example, let’s say you’re creating a portfolio theme using a custom post type to hold the portfolio items. At first glance, it appears that defining the custom post type within your theme would make the most sense, because the data is specific to your theme.
However, more and more developers are pointing out that if a user switches themes, their portfolio items will disappear, both from the front end and the back end. Obviously, this is not an ideal end-user experience, and so the suggestion is made to define the custom post type in a plugin. Now if the user switches themes, the data is visible on the back end, although it still disappears from the front end.
Is this a step in the right direction? Yes, probably. However, let’s not pretend that this is good usability. Which is more confusing, trying to figure out why your data is missing completely, or why it’s only missing on the front end? I really don’t have an answer for that. Neither of them are good options. (more…)