WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 years ago

#14746 closed task (blessed)

Post Formats — at Version 59

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 ryan)

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().

Change History (66)

comment:1 @iandstewart5 years ago

  • Cc ian@… added

comment:2 follow-up: @zamoose5 years ago

"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?

comment:3 @zamoose5 years ago

  • Cc zamoose added

comment:4 @ryan5 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.

comment:5 @ryan5 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.

comment:6 @zamoose5 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?

comment:7 @ryan5 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.

comment:8 @ryan5 years ago

Alternatively, since there can be only one "template", forget taxonomies and use a post meta field. We fetch all post meta anyway.

comment:9 @ryan5 years ago

  • Description modified (diff)

comment:10 @ryan5 years ago

  • Description modified (diff)

comment:11 @ryan5 years ago

  • Description modified (diff)

comment:12 follow-up: @demetris5 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.)

comment:13 @ryan5 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.

comment:14 @markmcwilliams5 years ago

Yes, I am I fan of the Tumblr-Related stuff! +1

comment:15 in reply to: ↑ 12 @dangayle5 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.

comment:16 in reply to: ↑ 2 @mikeschinkel5 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...

comment:17 @ryan5 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.

comment:18 follow-up: @ryan5 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.

comment:19 in reply to: ↑ 18 ; follow-ups: @mikeschinkel5 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?

comment:20 in reply to: ↑ 19 @ryan5 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.

comment:21 in reply to: ↑ 19 @ryan5 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.

comment:22 @mikeschinkel5 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.

comment:23 @nacin5 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.

comment:24 @ryan5 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.

comment:25 @dangayle5 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.

comment:27 @mikeschinkel5 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

comment:28 @ryan5 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.

comment:29 follow-up: @ryan5 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.

comment:30 in reply to: ↑ 29 @mikeschinkel5 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...

comment:31 @filosofo5 years ago

post_mode

comment:32 @mrmist5 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

comment:33 @johnjamesjacoby5 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.

comment:34 @ryan5 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.

comment:35 @ryan5 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.

comment:36 @ryan5 years ago

  • Description modified (diff)

comment:37 @ryan5 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') );

comment:38 follow-up: @ryan5 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().

comment:39 @ryan5 years ago

  • Milestone changed from Awaiting Review to 3.1
  • Type changed from enhancement to task (blessed)

comment:40 in reply to: ↑ 38 @dangayle5 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.

comment:41 @voyagerfan57615 years ago

  • Cc WordPress@… added

comment:42 follow-up: @ryan5 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.

comment:43 in reply to: ↑ 42 ; follow-up: @filosofo5 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.

comment:44 in reply to: ↑ 43 @ryan5 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.

comment:45 follow-ups: @ryan5 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

comment:46 @iandstewart5 years ago

Perhaps "image" for "photo"?

@ryan5 years ago

comment:47 @ryan5 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.

comment:48 @ryan5 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.

comment:49 in reply to: ↑ 45 @markmcwilliams5 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...! :)

comment:50 @sbressler5 years ago

  • Cc sbressler@… added

comment:51 @markjaquith5 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."

comment:52 in reply to: ↑ 45 ; follow-up: @hakre5 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?

comment:53 in reply to: ↑ 52 ; follow-up: @markmcwilliams5 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? :)

@ryan5 years ago

register_post_mode(), set_post_mode(), on the fly term creation

comment:54 @ryan5 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.

@ryan5 years ago

More API, untested

@ryan5 years ago

Selection UI in publish box

@ryan5 years ago

comment:55 in reply to: ↑ 53 @hakre5 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?

comment:56 @ryan5 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.

@ryan4 years ago

Reduce to the essentials

@ryan4 years ago

Rename to post_format

comment:57 @ryan4 years ago

Started a stub post intended to document the standardized formats on codex.

http://codex.wordpress.org/Post_Formats

comment:58 @ryan4 years ago

(In [15777]) Post formats, take one. see #14746

comment:59 @ryan4 years ago

  • Description modified (diff)
  • Summary changed from Post Kinds/Styles/Types to Post Formats
Note: See TracTickets for help on using tickets.