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.

Details: Single Purpose vs Widely Distributed Themes

Some developers take a stand somewhere in the middle and suggest that defining custom post types within a theme is fine when working with a single site, but that they should be defined in a plugin if the theme will be made available to the public. The assumption seems to be that users of widely available themes are more likely to be switching themes and running into trouble than users who had their theme custom built for their site. This may be true, but is it enough to justify separate usability standards and best practices? Also, is it good usability to force an end user to download a separate plugin just to get a theme to work? I’m not really sure which is better/worse on the usability scale.

Overlooked Fact: Developers are Always Required

Regardless of whether the custom post type is defined in the theme or in a plugin, a typical user can’t make the data work after switching themes without the help of a developer. They may be able to see the data in the back end and take comfort in the fact that it isn’t completely lost, but is that really the best we can do? Are we actually promoting the practice of surprising the user with disappearing front end data and calling it good usability just because they can still see it in the back end? Really?

Simple Solution: Tell the End User What’s Happening

Here’s my request for developers on both sides of the argument:

Please, please tell the user what’s happening! I don’t care where you define your custom post types. Just let the user know what they’re about to experience when they change themes. Thanks!

I’ll be the first to admit that this isn’t the easiest thing to do. I looked around and was unable to find a clean and simple way to display a message when a theme is deactivated. However, I did find and ugly way to do it.

function cpt_warning() {
	$msg = '<div class="updated"><p><strong>Please note:</strong> Your portfolio will no longer be visible.</p></div>' . $input;

	add_action( 'admin_notices', create_function( '', 'echo "' . addcslashes( $msg, '"' ) . '";' ) );

	unset( $_GET['action'] );
	require ABSPATH . 'wp-admin/themes.php';
	exit;
}
add_action( 'switch_theme', 'cpt_warning' );

I’m sure this code could use some improvement. I’m posting it here primarily as a way to further the data portability discussion, not to provide an elegant technical solution. If you know a better way to code something like this, please don’t hesitate to let me know.

What do you think? I’d love to hear your take on WordPress data portability in the comments. There has to be a better way to handle this than what we’re doing now.

Credit: The code above was based on this Stack Exchange thread.