[wp-hackers] Better approach for post formats

[Dagan Henderson]

Ah the joys of an open-source project. Adding new features like Formats is pretty much par for the course in open-source/community projects. Several developers have similar wants that more or less align around Formats, so the feature gets added. Then it takes a version or two to pound out the details of what people really want to see. If you look at the history of the Internet, you'll see that's exactly how it evolves (consider the histories of HTML, CSS and JavaScript), so it's hard to throw stones here.

Also, the Twenty Eleven theme is typically used as an example of how developers can employ new features, and post formats are no exception. IMHO, the clear usage is varied CSS formatting on the front end, not different input fields on the backend. Formats are the same content fields formatted differently. If what you're looking for is totally different fields, you may want to consider different post types instead--that's where the complete customization lies. Again, IMHO, I actually think the UI is much friendlier if very different content is published via different sub-panels (e.g. a "status update" is one sub-panel and a "post" is another), which is accomplished through post types, not formats.


-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of 24/7
Sent: Monday, October 24, 2011 6:56 AM
To: wp-hackers at googlegroups.com
Cc: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Better approach for post formats

So we now simply got it in core, which means that it's pretty unlikely to see post formats ever disappear - no matter if they are used or not. After reading this [1] (was this the initial ticket?), I still don't understand how and where "post formats" made its way into core (I guess IRC?).

Anyway: What I don't understand is why there's absolutely no recommendation in the related Codex page. I'd have expected to see some example implementation that recommends what to put where (example: "don't use custom fields - extract stuff from content/excerpt" or "use custom fields - name them exactly like the post format", etc.), to make it easier for a) developers to have a discussion base and b) for users what to expect. 
Haven't we got Theme development guidelines [3] for a reason? Example: Why are developers forced by a) core and b) the guidelines to use a comments.php file, but are left without any hint on how to implement post formats? I absolutely agree with @Andrés Sanhueza "(...) yet is much likely the way many current blogs with post formats can became broken when switching themes".

I really hope that those who pushed for post formats and implemented them will step in and start the discussion. If not, I hope automattic will step in and tries to bring theme devs on a table to get a "standard" 
implementation recommendation on the table.

Thanks.

[1] Trac Ticket <http://core.trac.wordpress.org/ticket/14746>
[2] WPSE js display switcher<http://wordpress.stackexchange.com/questions/14707/post-formats-how-to-switch-meta-boxes-when-changing-format>
[3] Theme Dev Guidelines <http://codex.wordpress.org/Theme_Development>