Wherein I revisit a debate from a year and a half ago to stir up trouble.
WordPress 3.1 dropped in February of 2011 and introduced Post Formats, a new taxonomy indicating a post’s front-end presentation context. Formats include Aside, Status, Image, and Video among others, and the idea is for themes to vary their presentation based on what the thing is. Twitter-like post about what you’re doing right now? Give it a Status format, and smart themes will, for example, omit the title in the front-end. Short-form note? Call it an Aside, and perhaps a theme will slap an “aside” watermark in the margin and hint with typography that this is one of your less-serious works (of brilliance).
The WordPress core team decided to standardize the available formats, and not offer APIs to extend them, so that you could expect your content to port gracefully when switching to a new theme. Theme developers were evidently in an uproar about this, considering the number of articles lead developers wrote around the time of 3.1’s release to explain and clarify their rationale for rigid standardization. See Otto’s for example, and a longer list linked on the Codex page under External Resources. WordPress’ philosophy includes decisions, not options — but developers typically enjoy a back-door escape clause when the decided defaults don’t suit them, in the form of functions, filters, and hooks to add to– and override defaults. In this case, post formats fundamentally require standardization, thus extensibility would undermine the entire feature, and thus no APIs exist to add “custom post formats” (which, to be clear, do not exist — there are only the standard formats). The core team’s explanations focused on this point, and on the fact that post formats are merely a custom taxonomy, and that in fact site developers already can create their own custom alternatives if they need to, using the same APIs that core uses to implement post formats.
I get that. Standardization is important.
But, I’m also sympathetic to the themers’ desire to add to the array of standard formats without having to do any re-implementation. Re-implementation seems inelegant — I’m thinking mainly of code bloat.
I know I am extremely late to this party, but there is a compromise that seems… well, obvious to me. I can’t imagine I’m the first to consider this, and there’s probably a compelling argument against it — which I’d like to hear.
I would propose to have custom post formats that require a fallback to a standard format. In practice, when loading a post, WordPress would check to see if it’s format was supported by the theme, and if it is, it would be passed to the theme as that format, but if not, it would be passed to the theme as the standard fallback format. It would be up to the theme developer to consider graceful degradation in their design process.
I believe this would only require two API methods: (1) A function to register custom post formats, that requires you to declare a fallback to one of the standard formats. This code would be inappropriate for a theme and would belong in a plugin (because if the theme were swapped out, the database entries specifying the new custom post format would be left with garbage). (2) A function to add theme support for a specific non-standard format.
I would use a mechanism like this to, for example, register a custom format for dictionary Definitions. I’d make them fall back to the Aside format.
Can anyone explain why this isn’t a good idea?