#14746 closed task (blessed) (fixed)
Post Formats
Reported by: | ryan | Owned by: | |
---|---|---|---|
Milestone: | 3.1 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Template | Keywords: | ongoing-project ui-feedback |
Focuses: | Cc: |
Description (last modified by )
Allow denoting a post as a certain format. Some example formats are aside, gallery, link, quote. This will allow themes to style these posts according to format.
This can be implemented as a custom taxonomy. post_format, for example. Terms within post_format would be the formats. The slugs and names will be stored as English as keys. Dummy gettext calls will get the strings into the catalog and later the fetched names can be run through translate().
UI on the edit post form will allow selecting from one of the types. Themes will be provided some simple API such as get_post_format(), set_post_format, and has_post_format().
Attachments (12)
Change History (167)
#4
@
14 years ago
Thinking we shouldn't have add_theme_support(). The idea for this is to carry across themes. You shouldn't be limited by the types supported by the current theme. You could switch later and wish you had set the type for previous posts.
#5
@
14 years ago
We need to take care to avoid confusion with Page Templates as well. Maybe we should call these templates and work these and page templates together into a shared UI.
#6
@
14 years ago
@Ryan:
Not trying to be a nattering nabob of negativity here. I guess I'm trying to grok how this functionality isn't already in place via simple category use. The functionality for styling posts differently per-category already exists in core.
What am I missing here?
#7
@
14 years ago
Using regular categories is very fragile. They can change with the language. They can be deleted. Their slugs can be edited. Thus the suggestion of a new taxonomy. One that will be hidden with no edit/manage UI exposed. The downside to a new taxonomy is an extra query.
#8
@
14 years ago
Alternatively, since there can be only one "template", forget taxonomies and use a post meta field. We fetch all post meta anyway.
#12
follow-up:
↓ 15
@
14 years ago
Is there a specific scenario that gave rise to this idea?
One advantage I can see to it over what we can already do (by using in_category() or has_tag(), for example) is that the “flag” will not be exposed on the front-end.
The language problem is indeed an issue, but it is easy to overcome. For example, I publish a theme and say:
If you want a post to be styled with the built-in Super Duper style, add the tag style-super-duper to it, or enter below another tag slug or tag name for the Super Duper style.
The main disadvantage I see to this trick is, as I said above, that the style-super-duper tag, while it is only for internal use and not useful to visitors, it will be visible to visitors.
Then, again, styling can be applied based on existing taxonomy terms. For example, applying a specific style to all posts of the Aside category or to all the posts of the News category. Then, nothing redundant is exposed to visitors.
I am not persuaded we need the extra complexity of an additional device here. (That said, I vote for the post-meta-field alternative if the idea is going to be implemented.)
#13
@
14 years ago
Something cross-theme, cross-language, consistent, and always there is the idea. Changing themes and having to re-tag everything for the purposes of styling is not a good experience.
#15
in reply to:
↑ 12
@
14 years ago
Replying to demetris:
The main disadvantage I see to this trick is, as I said above, that the style-super-duper tag, while it is only for internal use and not useful to visitors, it will be visible to visitors.
+1 for an additional taxonomy/standardized post meta keys
This has semantic value as well. For instance, how many "featured" post displays use categories and/or tags for this exact purpose? Categories and tags are ideally semantic values that indicate content structure and "folksonomy". I hate having to use multiple categories (News + Featured) or one non-semantic category (Featured) just so I can have something I can latch onto for display purposes.
#16
in reply to:
↑ 2
@
14 years ago
- Cc mikeschinkel@… added
+1 on the whole idea.
Replying to zamoose:
"Style" is too loaded of a word in HTML design circles. I think it conveys something we're not necessarily looking for here.
We've got custom post types already, but what you're proposing is a way to alter posts that would be returned intra Loop, yes?
I'm not sure what a suitable replacement would be -- genre? Variety?
I'm with zamoose, 'style' is too loaded and for me 'template' too generic. Variety works well...
#17
@
14 years ago
What we expose in the UI and what we use in API can be different. Something like "Content Type" could be used in UI. Using that in API could get confused with something to do with Content-Type though.
#18
follow-up:
↓ 19
@
14 years ago
Getting back to storage and queries, do we foresee a need to query all posts with a given "type"? I don't think we need to optimize for such a thing, thus post meta seems a good fit.
#19
in reply to:
↑ 18
;
follow-ups:
↓ 20
↓ 21
@
14 years ago
Replying to ryan:
What we expose in the UI and what we use in API can be different. Something like "Content Type" could be used in UI. Using that in API could get confused with something to do with Content-Type though.
My personal preference is consistency. It's hard to kept mentally between things like "featured-image" and "thumbnail" and just causes confusion for a lot of developers (me included.)
Replying to ryan:
Getting back to storage and queries, do we foresee a need to query all posts with a given "type"? I don't think we need to optimize for such a thing, thus post meta seems a good fit.
If you put it there querying on it will be needed. Maybe a form of #14513 would help?
#20
in reply to:
↑ 19
@
14 years ago
If you put it there querying on it will be needed. Maybe a form of #14513 would help?
That could be argued for anything in post meta. I don't see such an access pattern being common in this case.
#21
in reply to:
↑ 19
@
14 years ago
My personal preference is consistency. It's hard to kept mentally between things like "featured-image" and "thumbnail" and just causes confusion for a lot of developers (me included.)
Consistency is best, but I'd rather burden developers than create a bad experience for users.
#22
@
14 years ago
Replying to ryan:
If you put it there querying on it will be needed. Maybe a form of #14513 would help?
That could be argued for anything in post meta. I don't see such an access pattern being common in this case.
Yes it could, and I actually agree because you only have one post and not two.
Here's a consideration; would you ever entertain adding an optional meta_int
field to enable more performant relationships using meta? get_post_meta() and update_post_meta() could handle transparently.
#23
@
14 years ago
What about content types?
How confusing will that be to the millions of users who aren't exposed to post types? More or less, instead of equating post types to a "content type," we'd need to relate them to "object types" instead. Ironically, had we gone with "object type" for #9674, the perfect name for this might have been post types.
Alternative might be content styles. What questions will users ask themselves? I want to style this content this way? Or, what kind of content is this post? Seems like a dropdown in the publish box that has a label of "Style:", "Type:", or even "Content:" would all work just fine.
#24
@
14 years ago
Indeed. I'm thinking "Type: Aside _Edit_" in the Publish box next to Status and Visibility. Type really is the right term for this.
#25
@
14 years ago
Just my two bits, but from a UI design perspective, you could use the term "pattern" to describe this functionality. The "Shared Link" pattern. The "Featured Post" pattern. All the books describe differing web "parts" as "patterns", and even number them for indexing, etc.
#26
@
14 years ago
Examples of "patterns":
http://www.welie.com/patterns/
http://developer.yahoo.com/ypatterns/
http://patterntap.com/
#27
@
14 years ago
Replying to ryan:
Indeed. I'm thinking "Type: Aside _Edit_" in the Publish box next to Status and Visibility. Type really is the right term for this.
If Type then what would it be referred to internally and on blog posts explaining the matter? Won't it be too confusing for people to mix Type with Custom Post Type?
How about one of these? (from http://thesaurus.com/browse/purpose)
- Purpose
- Design
- Function
- Intent
- Scheme
- Usage
BTW, shouldn't Jane weigh in on this? JMTCW
#28
@
14 years ago
"What type of content is this" seems to be the question we're asking the user. Any word other than "type" feels like we're being purposefully oblique.
Internally, maybe content_type or post_content_type.
#29
follow-up:
↓ 30
@
14 years ago
Hmmm, maybe "Form" or "Format". Form: Text, Form: Short Message, Form: Quote
I think I still lean toward Type in the UI and post_content_type in the API.
#30
in reply to:
↑ 29
@
14 years ago
Replying to ryan:
Hmmm, maybe "Form" or "Format". Form: Text, Form: Short Message, Form: Quote
I think I still lean toward Type in the UI and post_content_type in the API.
I'll only comment on name once more so as not to beat a dead horse but "usage" seems like what we might be asking, i.e. "How do you want to use this content?"
But I would suggest again getting Jane's two cents...
#32
@
14 years ago
I like this. I could have used this exact thing in my last site refresh. Instead of this I ended up adding a post custom field, which is clunky in the extreme. So +1
#33
@
14 years ago
Post Phylum: Mollusca :)
Sounds a lot like what P2 does already, and Twenty Ten in a way inside the loop. But, it could be a unique way to use taxonomies to provide a decision making API that extends into other areas of post_type/taxonomy-term relationships.
If plugins could create custom post types, and then use a taxonomy and its terms to shape/shift the post river on the fly with custom loop parts base on the term names, that could be a neat little setup.
#34
@
14 years ago
Actually, a new taxonomy does not create a new query because we slurp all of the posts terms across all taxonomies in one go. So that eliminates that argument against a taxonomy. Since a taxonomy would allow plugins to more easily add their own types and will make querying more flexible, I say we go with a taxonomy.
#35
@
14 years ago
After seeing how diversely different themes are using this functionality, I don't think Type is appropriate. This is not always used to type the content. Often it is specifying pure window dressing. "Featured", for example, isn't a content type.
#37
@
14 years ago
We could turn this into a general template loading mechanism that would replace Page Template. Register template files for a given query and "type" setting. For page template back compat, we check the old meta setting and see if the template there corresponds to a registered one. For themes that use the registration API the Page Template headers could be ignored so that we don't show both. Themes could remove the Page Template headers once they are no longer concerned with < 3.1 back compat.
Some possible API:
// Register a template to be loaded for single queries for a particular post type // where the post has a given template_tag. register_template_file($template_tag, $post_type, $file); register_template('aside', array('description' => __('Short, inconsequential statement about what you just ate.'), 'name' => __('Aside'), 'post_types' => array('post', 'page') );
#38
follow-up:
↓ 40
@
14 years ago
A "template" does not have to map to a particular file. It could be used in a has_template() check or the theme might need it only for a template-$template class emitted in get_post_class().
#39
@
14 years ago
- Milestone changed from Awaiting Review to 3.1
- Type changed from enhancement to task (blessed)
#40
in reply to:
↑ 38
@
14 years ago
Replying to ryan:
A "template" does not have to map to a particular file. It could be used in a has_template() check or the theme might need it only for a template-$template class emitted in get_post_class().
This would work well with #13691 so that individual template parts could be pulled in to style a specific post type, falling back to default.
#42
follow-up:
↓ 43
@
14 years ago
Breaking it down. Core stuff and then extra stuff that can be added if desired.
- Register a new default taxonomy
- Create some agreed upon terms in that taxonomy during install
- Mark these terms for translation with some dummy gettext calls. This way they get into the default catalog and each theme does not have to provide translations.
That would be the bare bones, which leaves all UI and heavy lifting to themes.
Adding on:
- Inject the "template" slug into get_post_class() "template-$slug"
- Add has_post_template() and get_post_template() for wrapping up the taxonomy API calls.
- Add a template registration API for use by themes. Allows auto building a selection UI that can be included in the post edit screen.
- Load template files based on template slug. Themes register template files against a combination of post type and template slug. Selection UI can be built based on registration.
- Deprecate the Page Template feature in favor of the above, which is more consistent (themes register against agreed upon terms rather than store theme specific file names in post meta), more flexible (the template slug can be used for template loading, post classes, or whatever the theme wants), and is i18n friendly (unlike having strings in the theme header).
- Allow slug -> file registration and loading for any post type. Don't restrict it to pages as Page Templates currently are.
#43
in reply to:
↑ 42
;
follow-up:
↓ 44
@
14 years ago
Replying to ryan:
- Inject the "template" slug into get_post_class() "template-$slug"
Is there any chance that we can use some other terminology than "template"? It's not just that WP already has a meaning for "template"; it gets especially confusing because this system involves those other "templates" in sort of a meta-categorization of them.
Lemme suggest "mode" again: "gallery," "asides," and "videos" are descriptions of those posts in "a particular functioning condition or arrangement," or their "manner of acting or doing," or a "particular type or form of"---a "designated condition or status" of those posts. The quotations come from the definitions of "mode".
In other words, these posts are acting as "asides," whereas those compose the "gallery."
- Deprecate the Page Template feature in favor of the above, which is more consistent (themes register against agreed upon terms rather than store theme specific file names in post meta), more flexible (the template slug can be used for template loading, post classes, or whatever the theme wants), and is i18n friendly (unlike having strings in the theme header).
A quibble: a lot of people use Custom Page Templates to assign markup to one specific page, rather than a type or general class of page. For example, I see a lot of "About us" templates, meant to add things to an about page, such as maps and contact forms. Perhaps I'm misunderstanding what you want this system to do, but it doesn't seem to make much sense to speak of an "about us" kind of page or post, when that template has been tailor-made for one instance of a page.
#44
in reply to:
↑ 43
@
14 years ago
Lemme suggest "mode" again: "gallery," "asides," and "videos" are descriptions of those posts in "a particular functioning condition or arrangement," or their "manner of acting or doing," or a "particular type or form of"---a "designated condition or status" of those posts. The quotations come from the definitions of "mode".
There are also the French meanings of mode, which are well-suited for this. I'm fine with mode.
A quibble: a lot of people use Custom Page Templates to assign markup to one specific page, rather than a type or general class of page. For example, I see a lot of "About us" templates, meant to add things to an about page, such as maps and contact forms. Perhaps I'm misunderstanding what you want this system to do, but it doesn't seem to make much sense to speak of an "about us" kind of page or post, when that template has been tailor-made for one instance of a page.
True. This wouldn't generalize well to specialized templates that are meant as a means of assigning PHP code to a page.
#45
follow-ups:
↓ 49
↓ 52
@
14 years ago
Putting aside the add ons, we need a name for the taxonomy and a list of terms. "mode" or "post_mode" for the taxonomy? Possible terms:
- aside
- gallery
- photo
- video
- quote
- link
- chat
#47
@
14 years ago
Patch creates the default modes. Issues:
- The taxonomy system does not guarantee you will get the slug you ask for, especially if global terms are enabled. Taxonomy API enhancements might be need so the term associated with a certain slug can be used regardless of whether it's name matches the requested name.
- On multisite installs, this will be stored per blog even though it will always be the same. If plugins and themes will be adding their own modes (which defies part of the point), then this is a feature. Otherwise it is waste.
#48
@
14 years ago
Easy hedge against having a slug taken, make them more unique. mode-aside, mode-image, mode-*. We're not going to be uses the names stored in the terms table anyway due to i18n considerations.
#49
in reply to:
↑ 45
@
14 years ago
Replying to ryan:
Putting aside the add ons, we need a name for the taxonomy and a list of terms. "mode" or "post_mode" for the taxonomy?
I was thinking about that earlier, while playing about trying to create a little patch (but all I could come up with registering the taxonomy, I'll stick to finding small little erros to help fix!)
The way I see it at the moment, this is almost like a Post Status (which I know we already have) but would it be possible to mimic (in a way) and use the same kind of idea? -- Or have I potentially missed the whole idea behind all of this? Matt Mullenweg posted on WPDEVEL saying some stuff had gone a little out of what he'd been thinking, while I might like them, this can be built upon over time!
But going back to the suggested 'mode' I actually think it fits!
I'd love to test this out a bit more, when we've got more bits working...! :)
#51
@
14 years ago
Taxonomy API enhancements might be need so the term associated with a certain slug can be used regardless of whether it's name matches the requested name.
Yes please! If you supply a slug, it's because you want that slug. This is a huge annoyance when creating nice clean "deed restricted" taxonomies. You can easily end up with photo-2
as your "mode."
#52
in reply to:
↑ 45
;
follow-up:
↓ 53
@
14 years ago
Replying to ryan:
Putting aside the add ons, we need a name for the taxonomy and a list of terms. "mode" or "post_mode" for the taxonomy? Possible terms:
- aside
- gallery
- photo
- video
- quote
- link
- chat
Can you give a description and one or two examples for each of those, so it's easier to understand what those possible terms actually mean?
#53
in reply to:
↑ 52
;
follow-up:
↓ 55
@
14 years ago
Replying to hakre:
Can you give a description and one or two examples for each of those, so it's easier to understand what those possible terms actually mean?
The best way I could describe it is almost the way Tumblr works, you decide what *it* (being the type/mode) you want the content to show, it might be an Article, it might be a Photo, it could be a little one sentence Aside, something that links to an interesting Link on another site ... maybe you want to Quote a famous quote, and say something about it?
As I understand it, this would streaming the way things are done, it could be done in ANY theme as long as it's supported, and you'll not lose it because it'll be part of your WP install, nothing to do with your theme! How's that sound? :)
#54
@
14 years ago
Patch adds some API, makes mode slugs more unique by prepending 'mode-', and drops pre-installation of terms in favor of on-the-fly creation. On-the-fly is more feasible if we wrap some API around this to make sure the terms are created properly.
#55
in reply to:
↑ 53
@
14 years ago
Replying to markmcwilliams:
...
As I understand it, this would streaming the way things are done, it could be done in ANY theme as long as it's supported, and you'll not lose it because it'll be part of your WP install, nothing to do with your theme! How's that sound? :)
It sound that whatever is hardcoded into the application (quote, image, link, photos) can be something totally different and unrelated to what the user is using on the site because it's what the user defines, not the coder. The only problem is: It has already be defined in code.
How to resolve that dilemma?
#56
@
14 years ago
Note, registration and UI should and will be completely optional. A selector in the edit post UI is useful for themes like Twenty Ten, but useless for themes that provide their own microblogging style UI that is separate from the edit post UI. Themes that provide their own UI are only interested in having a naming and storage convention.
#57
follow-up:
↓ 63
@
14 years ago
Started a stub post intended to document the standardized formats on codex.
#59
@
14 years ago
- Description modified (diff)
- Summary changed from Post Kinds/Styles/Types to Post Formats
#62
@
14 years ago
Just a side note: Since "Photo", "Gallery", and "Video" and on the list, "Audio", "Playlist (Audio)", and "Playlist (Video)" (as a sort of Gallery type for Video and Audio) should be considered.
If "Playlists" are considered, a improved admin UI should be worked out for "better media management" (Which has been talked about various places) when dealing with collections of Audio and Video uploads (Ex. Insert "Audio Gallery" or "Playlist (audio)").
The above considerations would likely be a different ticket though, I only mention it for the post_mode taxonomy list.
#63
in reply to:
↑ 57
;
follow-up:
↓ 65
@
14 years ago
Replying to ryan:
Started a stub post intended to document the standardized formats on codex.
Based on what I've been working on two other formats seems to be very prevalent too:
- Listing (a list of items hand written or generated by a shortcode)
- Event (date/time/title/location, etc.)
#64
follow-up:
↓ 69
@
14 years ago
post_format is registered to page, post, and attachment. Should that only be post?
#65
in reply to:
↑ 63
;
follow-up:
↓ 67
@
14 years ago
Replying to mikeschinkel:
- Listing (a list of items hand written or generated by a shortcode)
- Event (date/time/title/location, etc.)
There seems to be some possible crossover as to what would be a post format and a custom post type. I would argue that anything that required extra data than what Post provides should not be a Post. I imagine it should only be a Post Format if it just refers to the styling / organisation of the Post's info. An event (which has a start time (different from publish date), end time, location etc) would not be suited to a Post as it only provides essentially a Title, Content Block and Image.
#66
@
14 years ago
- Cc jer@… added
Formats is a good name for it, mode would have been weird.
I think accounting for specific queries for posts in a format is important. My main site would probably use this for our "updates" (asides) but we show updates in the sidebar instead of the main content sometimes. Having them all as one post type is nice since we could merge them back together easily. Separating them visually means that e.g. On category pages we would be running a query for posts of x format that are also in y category, which gets expensive quickly. Currently we do this with a double-join on two categories (one for format one for actual topical category) so this new system should be at least as fast as that (which isn't very fast anyway).
#67
in reply to:
↑ 65
@
14 years ago
Replying to joehoyle:
Replying to mikeschinkel:
- Listing (a list of items hand written or generated by a shortcode)
- Event (date/time/title/location, etc.)
There seems to be some possible crossover as to what would be a post format and a custom post type. I would argue that anything that required extra data than what Post provides should not be a Post. I imagine it should only be a Post Format if it just refers to the styling / organisation of the Post's info. An event (which has a start time (different from publish date), end time, location etc) would not be suited to a Post as it only provides essentially a Title, Content Block and Image.
Great point, and I agree.
So I retract the "Event" type proposal but still think "Listing" is very commonly used and is frequently not a custom post type.
-Mike
#68
@
14 years ago
+1 for this idea. "Content Type" or "post format" seems appropriate. "Post Type" really should have been "Object Type."
I use Tumblr and there are seven content types/post formats: Text(Aside), Link, Quote, Chat, Photo, Audio, Video.
At some point, I'd like to leave Tumblr because it is a hosted platform and I'd like more control/flexibility. I'd like to be able to seamlessly import my tumblelog into WordPress. Since there will be others in that situation, it makes sense to me to have out-of-the box support for those seven custom types... if not in core, then at least in a canonical plugin. A Tumblr importer is needed too, but that's a different topic.
#69
in reply to:
↑ 64
@
14 years ago
- Cc paulgregory added
Three points:
1) Perhaps more thought is needed on how "normal" posts are marked as such - currently it appears to be the absence of a format, but I can't see how to use set_post_format to turn (for example) an aside back to "normal".
2) Replying to nacin:
post_format is registered to page, post, and attachment. Should that only be post?
I'm in favour of keeping post_format available for page. Obviously not all formats are relevant but gallery, chat, video and image certainly are.
3) An additional post format that may have merit is "liveblog" (or "live"). This is a type of post where additional content is being added while people are reading it. This could warrant changes to the way the post is displayed (such as auto-refresh) and input considerations (possibly the writer would use a custom edit box and the text would be appended to the beginning).
#70
follow-up:
↓ 71
@
14 years ago
- Keywords ongoing-project added
Sorry, I approved 'format' with ryan/nacin via skype while I was on the road and forgot to add comment here. That said, we need to get this wrapped up for inclusion in 3.1 before freeze. What's left?
#71
in reply to:
↑ 70
@
14 years ago
Replying to jane:
What's left?
I believe Mark planned to handle building the UI and moving the API over to add_theme_support().
#76
@
14 years ago
Currently browser jumps to the ID anchor when using the new post format links (edit, cancel, ok). Patch attached returns false in .click callback like we do for post visibility etc.
#77
@
14 years ago
Also the new UI is showing up for all post types, not just posts and pages (assuming post_format is supposed to be registered for posts, pages + attachments).
#80
@
14 years ago
Todo:
- Capitalization translation array for known types.
'aside' => __('Aside')
, etc. - Do we want this UI for pages too? I'm not sure that fits as well, but am open to it.
- Automatic creation of supported post format taxonomy entries, when used, if they don't already exist. This way theme authors don't need to do it. Much better.
- Convince Jane that this is the best location for this UI. I really think it is related to publishing the page, and anywhere else, it would be presented in a space-wasting manner.
#82
@
14 years ago
Todo:
- Do we want this UI for pages too? I'm not sure that fits as well, but am open to it.
- Automatic creation of supported post format taxonomy entries, when used, if they don't already exist. This way theme authors don't need to do it. Much better.
- Convince Jane that this is the best location for this UI. I really think it is related to publishing the page, and anywhere else, it would be presented in a space-wasting manner.
- "Format" column on Edit Posts screen
#83
@
14 years ago
Booched it.
Todo:
- Do we want this UI for pages too? I'm not sure that fits as well, but am open to it.
- Automatic creation of supported post format taxonomy entries, when used, if they don't already exist. This way theme authors don't need to do it. Much better.
- Convince Jane that this is the best location for this UI. I really think it is related to publishing the page, and anywhere else, it would be presented in a space-wasting manner.
- "Format" column on Edit Posts screen
#84
follow-up:
↓ 86
@
14 years ago
Thinking posts, not pages or attachments. IIRC, Matt agreed that this was designed specifically for posts.
Instead of a format column, what about bringing it into the title column, either with [Aside] prepended, or -- Aside suffixed, like post statuses? It works, except for sorting/filtering. A column itself doesn't allow for filtering, however, which I imagine would be more beneficial than sorting here. (Does another row of filtering links make sense, as a drill-down? Too much?)
#86
in reply to:
↑ 84
@
14 years ago
Replying to nacin:
Thinking posts, not pages or attachments. IIRC, Matt agreed that this was designed specifically for posts.
Will we be able to add format support to any post type (even 'page') with a "supports" value using register_post_type() and/or add_post_type_support()? (I scanned the code but I wasn't able to tell.)
#87
@
14 years ago
I don't see a problem with removing the post_type restriction in r16191, and going just with supports.
That said, I do want to remove the filter for adding new post types. We are going for consistency + 80%. Switching themes and having the same formats, etc. Not that we shouldn't solicit (especially from theme shops) over the next weeks or so exactly what formats we should have in core, but I feel that needs to be a decision so we can be consistent. Or that's at least how I interpreted the idea as a Codex page originally.
#88
@
14 years ago
Instead of a format column, what about bringing it into the title column, either with [Aside] prepended, or -- Aside suffixed, like post statuses?
Might be harder to scan, visually. Especially appended.
#92
@
14 years ago
Trying a post-status label, as Nacin suggested. It wasn't standing out enough next to "Draft" or "Sticky" ones, so I enclosed it in square brackets. Seems to help. Feedback solicited.
Looks like this:
I made the post format label last, so you can maybe can down the right edge and pick it up. But there are arguments for it going first, too. Thoughts?
#93
@
14 years ago
My first reaction is wishing the formats were icons instead of text if they are going to be coupled in with the title and status. Realistically I know there's no time to come up with some kind of additional icon API for them, and icons come with a learning curve, etc... I could see merit in having it be a new column considering the ability to sort by post format and get a one click solution for that.
Won't have access to code until Wednesday to offer a visual solution or contribute a patch, so take my opinions for what they're worth (which ain't much without a patch.)
#94
@
14 years ago
I like the suggestion of splitting it into its own column - it could then be sorted, or the column could be easily hidden for those who aren't using post formats.
My only other suggestion (and its a completely selfish one) would be for an extra class to be added to each <tr> indicating the post format (as is already done for the post status which I'm using to do this http://d.pr/NAKJ ), then I could potentially add my own icons...
#95
@
14 years ago
In addition to the post formats that are already going to be offered i was thinking of others like 'review' or 'profile' that might be useful to people, but the more I think about it I think those specific examples might be better suited to being custom post types rather than post formats - maybe I need to put more thought into it.
#96
follow-up:
↓ 98
@
14 years ago
- Cc brandondove added
+1 for this feature in general. Thanks to markjaquith for pointing this out. I just pulled trunk and created two twentyten child themes.
The first theme, I just copied the code from the codex and it works beautifully:
add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );
In the second theme, I added the rest of the post formats using the following syntax, but none of the new post formats showed up:
add_theme_support( 'post-formats', array( 'aside', 'chat', 'gallery', 'link', 'image', 'quote', 'status', 'video' ) );
It seems like once the post formats taxonomy is initially set, they don't update with new values.
#98
in reply to:
↑ 96
;
follow-ups:
↓ 105
↓ 113
@
14 years ago
Replying to brandondove:
In the second theme, I added the rest of the post formats using the following syntax, but none of the new post formats showed up:
add_theme_support( 'post-formats', array( 'aside', 'chat', 'gallery', 'link', 'image', 'quote', 'status', 'video' ) );It seems like once the post formats taxonomy is initially set, they don't update with new values.
No, that's not how it works. I just tested that. Works fine. That line doesn't set up the taxonomy. It just controls the UI/saving. Terms are created and/or added to the post format taxonomy as needed, on post save. But the dropdown list will show the things you specify in your add_theme_support()
call.
Do you perhaps still have the old theme active? :-)
#99
in reply to:
↑ 97
;
follow-up:
↓ 101
@
14 years ago
Replying to markjaquith:
(In [16200]) Post Formats generate output in post_class() (format-foo), and body_class() (for single... single-format-foo). Now themers can support Post Formats with one line of PHP and by adding CSS! see #14746
haha, you beat me to it :P
#101
in reply to:
↑ 99
@
14 years ago
Replying to ptahdunbar:
haha, you beat me to it :P
Doh! But it wasn't all for naught. Your patch alerted me to the fact that get_post_format()
can return a WP_Error
, which the code I've been writing doesn't take into account. Do you want to code up a patch that adds that test to the code I've committed on this ticket? I'm done for the night.
#103
@
14 years ago
Themes need a way to easily drop in new formats. This can currently be done like so:
add_theme_support( 'post-formats', array( 'example', 'example-2' ) );
But, these formats don't have associated strings so a user can't see how to select them.
#104
follow-up:
↓ 107
@
14 years ago
The idea here is to standardize. Post Formats are, to start, not much more than a taxonomy convention with a UI wrapper. So if you have “Asides” on one theme, you can transport them to another theme. If people create their own formats, their portability will be zero, or close to zero. While this feature is getting started, at least, I think it makes sense to have requests for new formats go through core. That way we can announce new ones with fanfare, put them on the Codex page, and themers can update their themes to support them. Maybe once we’ve iterated a few times and have covered all the common use cases, we can make it easier to deviate. But to start, a managed economy will result in better standardization.
It’s an unusual way to do things for WordPress — the difference here is that the main sell we’re offering is portability, and flexibility would hamper that goal.
#105
in reply to:
↑ 98
@
14 years ago
Replying to markjaquith:
Replying to brandondove:
In the second theme, I added the rest of the post formats using the following syntax, but none of the new post formats showed up:
add_theme_support( 'post-formats', array( 'aside', 'chat', 'gallery', 'link', 'image', 'quote', 'status', 'video' ) );It seems like once the post formats taxonomy is initially set, they don't update with new values.
No, that's not how it works. I just tested that. Works fine. That line doesn't set up the taxonomy. It just controls the UI/saving. Terms are created and/or added to the post format taxonomy as needed, on post save. But the dropdown list will show the things you specify in your
add_theme_support()
call.
Do you perhaps still have the old theme active? :-)
Actually, I thought the same thing (having the wrong theme active), so I deleted my original themes and created an additional theme with all of the post formats and it still didn't work. =(
#106
@
14 years ago
- Keywords ui-feedback added
The [Aside] at the end looks lame, I agree. I also agree with JJJ that an icon would be sweet. If Jane likes, maybe reach out to Ben?
I don't like the idea of the extra column, only because it's a lame way to present this and because filtering these by type is far more important than sorting these by type. Ideas?
#107
in reply to:
↑ 104
@
14 years ago
Replying to markjaquith:
The idea here is to standardize. Post Formats are, to start, not much more than a taxonomy convention with a UI wrapper. So if you have “Asides” on one theme, you can transport them to another theme. If people create their own formats, their portability will be zero, or close to zero. While this feature is getting started, at least, I think it makes sense to have requests for new formats go through core. That way we can announce new ones with fanfare, put them on the Codex page, and themers can update their themes to support them. Maybe once we’ve iterated a few times and have covered all the common use cases, we can make it easier to deviate. But to start, a managed economy will result in better standardization.
It’s an unusual way to do things for WordPress — the difference here is that the main sell we’re offering is portability, and flexibility would hamper that goal.
Here's what's going to happen though if we limit flexibility:
- A theme dev is going to figure out a way to work around this.
- That theme dev is going to share this code with other theme devs.
- Other themes will start being packaged with extra code just for a workaround.
With a simple filter hook, we could offer the flexibility some of us will make happen on our own anyway while still providing a standard for most of the theme development community. We could also avoid needless hacks for something that's much better handled with one line of code in core.
Suppose we stick with a standard pool of formats. Further suppose that the "audio" format isn't within this pool. Essentially, this tells theme developers that they must wait until the next major release of WordPress to hope (because it's not guaranteed) the audio format will be pushed into the standard pool. It'd be much easier for theme developers to go ahead and use the audio format while trying to get it added to the standard list at the same time.
Also, it's us theme developers who will have to explain to users how to create new formats. I can guarantee you that I'll receive requests to do so from users the very day I add this feature to one of my themes. It'll be some off-the-wall format that none of us have thought of, but it'll be important to a user.
I like the idea of standardization and portability, but intentionally limiting flexibility is just not the WordPress way. If that's the route we take, then we need to cover more scenarios. A lot more scenarios. And, this pool needs to be decided upon by a much larger set of people than the developers viewing this ticket.
Here's a few other ideas for the standard pool of post formats:
- slideshow
- audio
- media
- list
#108
follow-up:
↓ 110
@
14 years ago
Any chance the "standard" list could be pulled and cached from a web service on WordPress.org? That way the standard list could be decoupled from release and the community could add desired Post Formats more quickly, maybe by using an ongoing polling mechanism to see what people need?
Just a thought...
#109
follow-up:
↓ 116
@
14 years ago
I like the idea of standardization and portability, but intentionally limiting flexibility is just not the WordPress way.
The whole point of this feature is standardization and portability. Really, the initial idea was just a Codex page -- the taxonomy and UI is a whole other matter.
If that's the route we take, then we need to cover more scenarios. A lot more scenarios. And, this pool needs to be decided upon by a much larger set of people than the developers viewing this ticket.
I said earlier:
Not that we shouldn't solicit (especially from theme shops) over the next weeks or so exactly what formats we should have in core ...
I'll talk with Adii of WooThemes specifically about this when I see him at WordCamp NL tomorrow. FWIW though, I think we used Woo's list of formats to generate ours. I'm all for a brainstorm on wpdevel and having theme developers and companies provide feedback. I'm not interested in rejecting formats, but the list should also be refined to the point where we can expect and encourage developers to offer an experience for all of them, if they're going to offer any of them.
#110
in reply to:
↑ 108
;
follow-up:
↓ 111
@
14 years ago
Replying to mikeschinkel:
Any chance the "standard" list could be pulled and cached from a web service on WordPress.org? That way the standard list could be decoupled from release and the community could add desired Post Formats more quickly, maybe by using an ongoing polling mechanism to see what people need?
Interesting idea, but I think revisiting this every 4-6 months (i.e. every major release) seems sensible. The goal is for people to switch themes and for all of their content that they curated by format to continue to have special treatment. Just tacking on more formats as we go whenever someone comes up with a use case is against the goal of having consistency and a standard across just one area of theme development. A constantly moving standard is impossible to hit.
#111
in reply to:
↑ 110
@
14 years ago
Replying to nacin:
Interesting idea, but I think revisiting this every 4-6 months (i.e. every major release) seems sensible.
Not saying my solution is the correct approach, but I think you'll find 4-6 months way too long for the initial follow-up.
Once people start using Post Formats there will be a flood of ideas for how to use them initially as the 80 percentile use-case patterns emerge (almost by definition you will not have gotten all of them right no matter how hard you try.) If there is no near-term way for these common use-case patterns to be added in a project timeframe people will get frustrated. If there is not some form of "relief" value people will likely do an end-run as @greenshady suggests which will likely torpedo the stated goal of interoperability.
Just tacking on more formats as we go whenever someone comes up with a use case is against the goal of having consistency and a standard across just one area of theme development.
Not "when someone comes up with a use-case" but when it becomes clear there is an large number of people need the use-case. I'm talking the ability to add 2-3 a month, not hundreds. Digg-like voting could surface that; I'm sure there's a plugin that could support that on a WordPress post somehow.
A constantly moving standard is impossible to hit.
All standards that are not-moving are by nature dying, as well as those that were not well-vetted by the broader community in advance. Providing a simple process to announce the release of new formats on a monthly or bi-monthly timeframe could allow for crowdsourcing of the needed options.
As always, JMTCW.
#112
@
14 years ago
Been lurking all day. Still haven't browsed trunk to play. What happens if you wp_set_object_terms directly on a post and post-format taxonomy? Can a post have multiple formats like how terms work? Are there checks in place for that scenario?
#113
in reply to:
↑ 98
@
14 years ago
Replying to markjaquith:
Replying to brandondove:
In the second theme, I added the rest of the post formats using the following syntax, but none of the new post formats showed up:
add_theme_support( 'post-formats', array( 'aside', 'chat', 'gallery', 'link', 'image', 'quote', 'status', 'video' ) );It seems like once the post formats taxonomy is initially set, they don't update with new values.
No, that's not how it works. I just tested that. Works fine. That line doesn't set up the taxonomy. It just controls the UI/saving. Terms are created and/or added to the post format taxonomy as needed, on post save. But the dropdown list will show the things you specify in your
add_theme_support()
call.
Do you perhaps still have the old theme active? :-)
The reason why WP wasn't picking up the post formats I set up in my twentyten child theme was because twentyten was defining it's own abbreviated set. So I guess whatever is set in the parent theme overrides what's in the child theme eh?
#114
follow-up:
↓ 115
@
14 years ago
+1 for theme developers being able to add extra formats when they deem fit.
BIG +1 for encouraging theme developers to use the standardised formats. Perhaps a way to encourage this, without forcing it on them would be to use add_theme_support() again to add support for customisable formats? add_theme_support( 'custom-post-formats' ) would be enough to make it obvious to developers that they probably don't need to create their own custom formats, yet still allow those who do require the extra flexibility to create their own custom formats for their particular implementation.
Support for some sort of conditional system would be handy too. Perhaps something like the following:
if ( is_post_format( 'video' ) echo 'this is the video format';
#115
in reply to:
↑ 114
@
14 years ago
- Cc trac@… added
Replying to ryanhellyer:
Support for some sort of conditional system would be handy too. Perhaps something like the following:
if ( is_post_format( 'video' ) echo 'this is the video format';
You can use has_post_format() for conditionals.
#116
in reply to:
↑ 109
;
follow-ups:
↓ 117
↓ 118
@
14 years ago
the problem with soliciting opinions for a set of standard formats is it's more time consuming. individuals and groups have their own list of must-have or standard formats. asides, galleries, quotes, events, links, images, videos, and audios to list a few. even with a large enough pool of voters, not all popular formats would be included if there's a limit on number of formats you can include.
this leads to developers creating custom work-arounds and everyone waiting on core to announce the next format. it's not the way WordPress work. fanfare is unnecessary and none of us need to drool at the thought of our suggested format being the next one to be included with core. it's not a pretty sight :)
standards should be set from the bottom up starting with theme users' demands. next is the theme developers' willingness to support the trending format. if a new format proves useful for most users, theme developers will be forced to support it. otherwise, they'd lose business to their competition.
maximum portability means standardizing with a minimalistic set of features per format. for a format like Aside, that could work. for more complicated formats, it's easier said than done. time is needed to figure out what's necessary/unnecessary for each popular format. leaving it in the hands of users and developers will speed up this process, which is why setting standards from the top down and making people wait will be more time consuming.
flexibility and portability may be equally important, but if you leave room for flexibility to grow first, it will sort out the standards for portability quickly and precisely.
#117
in reply to:
↑ 116
@
14 years ago
Replying to SmallPotato:
standards should be set from the bottom up starting with theme users' demands.
Not always. Kevin Kelley tells a brilliant story about why top-down control is sometimes required. I first read that anecdote in his 1998 book New Rules for the New Economy and its lesson has stayed with me ever since. In looking for it today I was glad to see that he recently extracted that story as a blog post so I can now link directly to the story.
#118
in reply to:
↑ 116
;
follow-up:
↓ 121
@
14 years ago
Replying to SmallPotato:
the problem with soliciting opinions for a set of standard formats is it's more time consuming. individuals and groups have their own list of must-have or standard formats. asides, galleries, quotes, events, links, images, videos, and audios to list a few. even with a large enough pool of voters, not all popular formats would be included if there's a limit on number of formats you can include.
maximum portability means standardizing with a minimalistic set of features per format. for a format like Aside, that could work. for more complicated formats, it's easier said than done. time is needed to figure out what's necessary/unnecessary for each popular format. leaving it in the hands of users and developers will speed up this process, which is why setting standards from the top down and making people wait will be more time consuming.
flexibility and portability may be equally important, but if you leave room for flexibility to grow first, it will sort out the standards for portability quickly and precisely.
Also, there's also a benefit in embracing constraints. There have been several people promoting the idea of embracing constraints lately, for example. This probably started recently with 37 Signals ''"Getting Real"'' book (although I'm really not a fan of 37 Signals I do generally agree with them on this topic.)
Some of my best work has come from when I've embraced constraints given to me, and some of my worst has been when I allowed myself uncontrolled freedom to implement whatever.
#120
@
14 years ago
I really believe we ought to be giving developer's the opportunity to determine their own post formats.
I don't see how this is anymore "dangerous" than custom post types or custom fields. Many sites use these custom data structures without the assurance their data will work in other themes. If thats the concern -- big mistake on custom post types.
Post formats are essentially custom fields with a different UI. Why handcuff developers? Building constraints into an open-source project simply doesn't work the same way it does with a hosted application.
IF, and I really hope otherwise, it comes down to a standard list I'd like to see a poll on the .org blog or similar to get a sense of what post types we're missing and which ones should definitely be included.
#121
in reply to:
↑ 118
;
follow-up:
↓ 122
@
14 years ago
Replying to mikeschinkel:
Replying to SmallPotato:
the problem with soliciting opinions for a set of standard formats is it's more time consuming. individuals and groups have their own list of must-have or standard formats. asides, galleries, quotes, events, links, images, videos, and audios to list a few. even with a large enough pool of voters, not all popular formats would be included if there's a limit on number of formats you can include.
maximum portability means standardizing with a minimalistic set of features per format. for a format like Aside, that could work. for more complicated formats, it's easier said than done. time is needed to figure out what's necessary/unnecessary for each popular format. leaving it in the hands of users and developers will speed up this process, which is why setting standards from the top down and making people wait will be more time consuming.
flexibility and portability may be equally important, but if you leave room for flexibility to grow first, it will sort out the standards for portability quickly and precisely.
Also, there's also a benefit in embracing constraints. There have been several people promoting the idea of embracing constraints lately, for example. This probably started recently with 37 Signals ''"Getting Real"'' book (although I'm really not a fan of 37 Signals I do generally agree with them on this topic.)
Some of my best work has come from when I've embraced constraints given to me, and some of my worst has been when I allowed myself uncontrolled freedom to implement whatever.
i see your point. however, it seems neither of the two examples referenced are applicable. (correct me if i'm wrong. i might be confused.)
designers use constraints for direction in order to finish the job quickly and objectively. it's unlike limiting post formats.
in design, the client tells the designer you can use anything you want to design the site, but work around my needs. admittedly, that is setting standards from the top down in which constraints are helpful. in limiting post formats, you're the designer telling the client only Photoshop tools are available, no Illustrator, therefore, no illustration or vector work. that's setting standards from the top down for your convenience, not for the good of the clients or theme users.
second example referenced an experiment, which i will not summarize here. in that experiment, the controller knew what to do and the audience didn't, which means more tools = higher learning curve for the audience to get right. in WordPress, the audience or theme users actually know what they want. they're the ones who should determine what needs to be built. from their demands, we filter out the necessary constraints for each format.
#122
in reply to:
↑ 121
@
14 years ago
Replying to SmallPotato:
i see your point. however, it seems neither of the two examples referenced are applicable. (correct me if i'm wrong. i might be confused.)
Embracing constraints is a general principle as such I wasn't providing an exact matching use-case but instead highlighting other discussions of the principle.
Look at the WordPress API, for example. We can't change it and the core team changes it slowly and carefully. That's a good thing otherwise we'd have a moving target to hit.
Look at HTML. Does v4.0.1 have everything we want? Not by a long shot, but the fact that it was a stable target and made it possible for people to build many wonderful things with it. If HTML had been designed to allow extensible markup like XML; do you think we've have seen the uptake we did? Highly unlikely because there would have been so little common ground.
OTOH, let me make another proposal that might make everyone happy? Stand on the shoulders of giants and use the same approach as the Internet Media Types. The standard Post Formats will be named as-is and Custom Post Format could get prefixed with "x-
".
Then over time the core team could survey somehow to figure out what the commonly needed new Post Formats are and add those into the next version of WordPress. They could even add functionality that would automate the use of "x-" as a prefix for all custom post formats.
It worked for Content Types on the web, why not WordPress Post Formats too?
#123
@
14 years ago
I'm with Justin on this, Post Formats shouldn't bar non-standard formats, or at least, they deserve some consideration.
A list of formats, on the codex page or some definition in core, should serve as the list of formats that have achieved standardization, and when working with these, consistency and portability are expected and important.
And yet, emerging standards, ones not yet on the list, should have their place. Do we want them in the new system somehow, or is Category Styles way of doing it the place for non-standard formats. (Or perhaps Mike's prefixing solution above.)
The limitation as is will simply prompt people to do it the old way: Style up Categories. I'm assuming here that we'd prefer Theme designers to adopt the add_theme_support way of doing things.
#124
@
14 years ago
If post formats are supported, then 'default' should always be supported and should be enforced as the default, even if nothing is stored yet for that post.
#125
@
14 years ago
From Twitter, it looks like the answer to my above question is: Don't use add_theme_support on a non-standard, non-portable, (pre-standard?) Format.
For a non-standard post format, Use a plugin (or custom theme functions) to style up a taxonomy (category) and if it gets popular, it might make the list. (Much of the suggested post format extensions seem better as CPTs anyway).
Non-extensibility protects the standard list from being ignored/obsolete, and protects the *Feature* (in it's entirety) as a Fully portable standard (pragmatic I guess).
I still see Justin's (and other's) point that a non-standard format wouldn't effect the portability of the standard formats, and that an extension API would be cleaner for yet to emerge standards. (Formatting Categories is still possible, if less clean.)
But over all, even without the extendability, it's a really cool feature. :-)
#126
follow-up:
↓ 127
@
14 years ago
The spec if more than defining a name. It will define where certain things should be stored and provide guidelines for presentation. Non-standard formats would have to use a prefix to avoid stomping a future standard format which may differ in spec. In that case, you might as well use your own taxonomy or postmeta, which is trivial to do as evidenced by the post format wrappers.
#127
in reply to:
↑ 126
;
follow-up:
↓ 138
@
14 years ago
Replying to ryan:
Non-standard formats would have to use a prefix to avoid stomping a future standard format which may differ in spec.
Any chance of choosing "x-" as a guidance for a recommended prefix for when people inevitably hack the post formats and add their own?
#129
follow-up:
↓ 133
@
14 years ago
The above patch checks if the current theme supports post formats before displaying the post format on the post listing page. Maybe a check if the post type supports formats would be needed too, but I left it out for now.
#133
in reply to:
↑ 129
@
14 years ago
Replying to greenshady:
The above patch checks if the current theme supports post formats before displaying the post format on the post listing page.
I was torn on this. The post still has the formatting designation, even if the theme doesn't support it. They could later switch to a theme that does support it. Might be alarming to the user if those designations disappear.
#135
@
14 years ago
Slightly related: #15421
Ticket allows devs to more easily add something like icons for the format on the edit posts screen.
#136
follow-up:
↓ 137
@
14 years ago
Just occurred to me that if people are going to use post formats for things they used to use with tags or categories then they will probably want URLs that display a list of those things like they had with tags and categories. I haven't had the time to install all the patches but I assume we do not have URL support for Post Formats?
#137
in reply to:
↑ 136
@
14 years ago
Replying to mikeschinkel:
Just occurred to me that if people are going to use post formats for things they used to use with tags or categories then they will probably want URLs that display a list of those things like they had with tags and categories. I haven't had the time to install all the patches but I assume we do not have URL support for Post Formats?
#138
in reply to:
↑ 127
;
follow-up:
↓ 139
@
14 years ago
Replying to mikeschinkel:
Any chance of choosing "x-" as a guidance for a recommended prefix for when people inevitably hack the post formats and add their own?
This doesn't stop multiple conflicting x-event formats, and therefore is not better than categories at enabling portablility between themes.
As a counter proposal, how about reverse domain notation?
eg:
com.examplethemedeveloper.event
Most of the time these non-standard formats are only going to be portable between themes from the same vendor anyway, so they may as well be explicit.
I do not propose changing the existing set to "org.wordpress.aside".
--
Will there be a quick way to set the Format of all posts in a particular Category (eg all posts in category 'Asides' to format 'aside')?
#139
in reply to:
↑ 138
@
14 years ago
Replying to paulgregory:
Replying to mikeschinkel:
Any chance of choosing "x-" as a guidance for a recommended prefix for when people inevitably hack the post formats and add their own?
This doesn't stop multiple conflicting x-event formats, and therefore is not better than categories at enabling portablility between themes.
Nope, sure doesn't, but then "x-" formats would not be for portability but instead of when people needing to do implementation-specific Post Formats much like how the "x-" does not stop conflicting MIME types either.
As a counter proposal, how about reverse domain notation?
eg:
com.examplethemedeveloper.event
Most of the time these non-standard formats are only going to be portable between themes from the same vendor anyway, so they may as well be explicit.
Ugh. That would make WordPress coding start to look like working with Enterprise Java Beans. Too complex. Not my vote.
Will there be a quick way to set the Format of all posts in a particular Category (eg all posts in category 'Asides' to format 'aside')?
Using $wpdb->query()
would do it quickly.
#141
@
14 years ago
My thoughts: do what Tumblr do - they've spent a lot longer pondering this question than we have. Introduce other things later (or not) based on demand.
#142
@
14 years ago
Enhancement request: in_category can accept an array of categories to check against. has_post_format should be able to do the same.
Example usage: if (has_post_format(array('aside','quote'))) ...
#144
@
14 years ago
I created related ticket: #15582 "Format: Default" provides no info, and default might change
#145
@
14 years ago
- Cc gazouteast added
Coming in late on this right in the middle of a site build that uses a lot of Custom Post Types, Custom Taxonomies, Custom Meta Boxes, and far too many Custom templates per each of the above - leads me to approve the original intent, which having read all the way down the ticket, seems to have evolved and mutated from the original intent.
Going back to the top quarter of the ticket and what to call these "things" - mode seems better suited than format, as it implies usage, but of itself is incomplete. I "get" and understand the i18n issues, and can't help wondering if putting a new word int he dictionary is needed here (after all, it seems to be a favourite activity of the IT industry generally) - perhaps a concatenation of something "data" and "role" - two words everyone understands and which translate nicely, therefore instead of "post-format" we could have "datarole"
"Datarole" is short enough to not clog naming conventions, can be postpended with post uses (post-datarole, page-datarole, etc) when applied to where the data will be used, and can be prepended for which type of format it will be used in (datarole-post, datarole-aside, datarole-widget, etc). Thus you could have usage terminology such as -
- post-datarole-footnote = post content, identified with [exampletag] exampletag, which is repeated in the footnotes between the post end and the comments form (just an example)
- post-datarole-aside = post content with a different tag-pair, grabbed automatically from main post content and displayed in the aside widget or inline-aside div.
- datarole-post = a custom input (e.g. on public pages) via form or edit post screens that is saved with the intent of using it for a post (subject to editorial approval etc), and/or allows for purpose assignment exactly as per nacin's UI screengrab above.
- datarole-aside = input in same manner as now as an aside - appears only in the asides widget, and the asides taxonomy archive, and on pages structured in the style of a posts-based index.php - does not appear as a single post on single.php or any custom variants (but needs option for use with (e.g.) BuddyPress, bbPress, or other forum type plugins, showing as the first post in a discussion thread / or having been pulled from somewhere like that, and via a highlighting mechanism, tagged as datarole-aside.
Like I said - sorry I got in late on this, I wish I'd found the topic 3 months ago, but my mind was focussed on other functionality at that time and I missed this one.
Gaz
#146
@
14 years ago
Darn - forgot to mention - the key point here, is that despite having read the whole ticket, "post format" to me just screams "visual layout" and not "content purpose".
"datarole" would remove that ambiguity, and I guarantee it would scuttle a thousand support topics (requesting clarification) before they were launched.
#147
@
14 years ago
- Resolution set to fixed
- Status changed from new to closed
Resolving this as fixed. Further bug reports should go into individual tickets.
#148
in reply to:
↑ 140
@
14 years ago
- Cc gary@… added
Replying to Otto42:
Attached a patch to add the audio format.
Obviously minor, but any reason 'audio' isn't in alphabetical ordering as per everything else ("standard" being a special case).
#149
follow-up:
↓ 150
@
14 years ago
They should be in functional order. Alphabetical won't apply to other languages, and I'd rather not add such a sort.
I didn't even realize they were in alphabetical order.
This works for me:
standard, aside, status / gallery, image / link, quote, chat / video, audio
#150
in reply to:
↑ 149
;
follow-up:
↓ 151
@
14 years ago
Replying to nacin:
They should be in functional order. Alphabetical won't apply to other languages, and I'd rather not add such a sort.
Fair point.
This works for me:
standard, aside, status / gallery, image / link, quote, chat / video, audio
I'd personally suggest:
standard, aside, status / image, gallery / video, audio / quote, chat, link
to have the different types of media together, the single image before multiple images (gallery), and the link format last as I'm guessing this might be used more than quote and chat, so making it last makes it that bit quicker / easier to find (if this ordering was carried through to the radio buttons UI too).
#151
in reply to:
↑ 150
@
14 years ago
- Cc 24-7@… added
Replying to GamajoTech:
This works for me:
standard, aside, status / gallery, image / link, quote, chat / video, audio
Replying to nacin:
I'd personally suggest:
standard, aside, status / image, gallery / video, audio / quote, chat, link
to have the different types of media together, the single image before multiple images (gallery),
I would group them by display size (the amount of space they need to get displayed). My opinion:
standard(default) / image, gallery, video / aside, status, link, chat, quote / audio
And yes i know, the text-length is not equal.
Replying to nacin:
and the link format last as I'm guessing this might be used more than quote and chat, so making it last makes it that bit quicker / easier to find (if this ordering was carried through to the radio buttons UI too).
+1 - Should (imo) be the most important argument for the order. They won't grow too much, so you don't need to search by name. By "used most" (row) and "size groups" (columns) would be easy, i think.
#152
follow-up:
↓ 153
@
14 years ago
Oh and it would be great if the array containing the post_format(s) would be in some central $var or function, that you could call from theme/template files.
#153
in reply to:
↑ 152
@
14 years ago
Replying to F J Kaiser:
Oh and it would be great if the array containing the post_format(s) would be in some central $var or function, that you could call from theme/template files.
get_theme_support('post-formats');
Or if you want all of them, use the returned keys of get_post_format_strings();
#154
@
14 years ago
How did you implement the Link format?
It seems that the whole content block should be made to a link, or that the link url should be placed in the title or the content. But then you would have parse the diffrent variations trying to extract the right link, and then generate the content and the title for display.
Other plugins seems to use a custom field for the title url.
I can't see any code example for how it's supposed to work in 3.1.
"Style" is too loaded of a word in HTML design circles. I think it conveys something we're not necessarily looking for here.
We've got custom post types already, but what you're proposing is a way to alter posts that would be returned intra Loop, yes?
I'm not sure what a suitable replacement would be -- genre? Variety?