Thoughts on WordPress Data Portability

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';
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.

Posted in ,

4 thoughts on “Thoughts on WordPress Data Portability”

  1. Hi Alex. Another great post on the subject is by Mike McAlister, “Why I don’t Use Custom Post Types in My Commercial Themes”:

    Custom post types can definitely serve a purpose (think downloads in the Easy Digital Download plugin), but I have a feeling general purpose post types (like gallery, slider, etc) will likely migrate to post formats after they get some more UI love in WordPress 3.6.

    It’s actually pretty easy for non-developers to switch custom post types back to a standard post type if they use the Post Type Switcher plugin:

    But maybe theme authors who use custom post types should build in the migration script. e.g. Instead of just displaying a notice on the switch_theme hook, you also give them an option to migrate their custom post types back to regular post types.

  2. Thanks for the McAlister link. I agree that custom post types shouldn’t be overused, but I didn’t really want to get into the whole how-should-custom-post-types-be-used debate. My goal was to take a step back and say, “Regardless of how we’re using custom post types, can we make it more user friendly?” The Post Type Switcher plugin looks promising, and adding something like that to the switch_theme hook is a great idea! I’ll have to look into that further. Thanks for the suggestion!

    1. alexmansfield

      I haven’t tested this personally, so this is just speculation. If the post type is stored in the data you’re serializing/unserializing, it seems to me it should be preserved. However, if you’re only serializing, for example, the post title and content, the the post type wouldn’t transfer. It also seems that if you’re migrating the entire WordPress database, post types should be included. Keep in mind that custom posts types won’t be visible in the admin area after the migration unless the theme/plugin that defined the custom post type is active.

Leave a Comment

Your email address will not be published. Required fields are marked *