WordPress Post Format Fallbacks

While our post formats admin UI is getting a nice warm reception (100+ tweets, pings and comments, wow!), there is a concern that has popped up a few times – one that I included a nod towards in my original post.

What happens when publishers put important data in the post format custom fields, then choose to change to a theme that doesn’t support these fields?

It’s a legitimate concern, and (as noted previously) one that I had an interesting discussion with Ian about at WordCamp SF this year. His idea of core functionality that could tack the data on at output seems like a great solution.

In Open Source, code talks.

I’ve put together a proof-of-concept plugin that does exactly this with the data fields supported by our post formats UI plugin.

Post Format Fallbacks

With this plugin enabled, the information in custom fields is automatically added to the post content. In the event the publisher switches to a theme that either doesn’t support post formats (or doesn’t support the custom fields our admin UI provides for), they could enable this plugin and their posts would have all the information displayed that they expect.

Once WordPress 3.3 is out the door, I’ll submit these plugins for consideration and discussion to be included in core. In the meantime, this should at least minimize data portability concerns for theme developers.

Fellow developers, please help this improve! Fork it on GitHub, provide feedback and enhancements, etc. This was put together in a few hours yesterday afternoon, so it is very lightly tested and should be considered a starting point. There are some simple checks in place to try to avoid situations where the auto-added content would duplicate content manually inserted into the post, but I’m guessing that can be improved a bit (it’s entirely lacking for image formats, for example).

This post is part of the project: Post Formats Admin UI. View the project timeline for more context on this post.