[wp-hackers] post format types
Philip M. Hofer (Frumph)
philip at frumph.net
Thu Jan 6 20:32:35 UTC 2011
Just a question, this code isn't parsed unless add_theme_support is
initiated right? because this bit of code is practically useless to me in
it's current designed limitations I wouldn't want to have the overhead.
----- Original Message -----
From: "Otto" <otto at ottodestruct.com>
To: <wp-hackers at lists.automattic.com>
Sent: Thursday, January 06, 2011 12:20 PM
Subject: Re: [wp-hackers] post format types
On Thu, Jan 6, 2011 at 2:13 PM, Philip M. Hofer (Frumph)
<philip at frumph.net> wrote:
> Author is just a reference of a type, there should be registerable post
> format types and functional abilities to make it easy for designer to
> functionality for their theme. Whether it's author, comic, education,
> random thought, the ability to change the post format of the look of the
> post should be up to the disgression of the theme designer themself, not
> confined to a specific set.
If you don't confine it to a specific set, then it's useless. One
theme designer uses "random-thought", another uses "thoughts", another
uses "thought"... So when the user switches themes, all their old
assigned formats go out the window.
If you want to define your own set of things, then you should define a
custom taxonomy with your things in it and use those instead of
mucking up the tables for everybody else.
> If the post format doesn't exist in other themes, it uses a fallback to
> standard, not a big deal.
Not a big deal for you, but a big deal for the user switching themes
and wondering why all their post formats don't work anymore, because
some theme designer defined a whole bunch of useless custom formats.
At least with a custom taxonomy and a custom meta box, there is
branding ensuring that the user *knows* that these formats he's using
are custom to the theme and won't work in other themes.
> instead of people using this "feature" we have to write our own code
> anyways. That makes this code near pointless beyond its defined
> parameters. Which again, i'm not saying is bad, its just confined to it's
> specific implementation and nothing else.
The confining of it to the specific implementation is a good thing.
That's the beneficial part, from a user's perspective.
As a user, if I make an "aside" post, then I know that the "aside"
will still work if I change to another theme that supports asides.
Because the naming doesn't change. Because the format is in a fixed
list. Because theme authors creating themes will want their users to
Theme authors don't need to be creating custom stuff in order to
lock-in their users. Or if they do, then they don't need to be
supported in doing this unethical sort of lock-in behavior by the
WordPress core code.
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers