WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 years ago

#14746 closed task (blessed)

Post Kinds/Styles/Types — at Version 36

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 style/type/kind. Some example styles are aside, gallery, link, quote. This will allow themes to style these posts according to kind.

This can be implemented as a custom taxonomy. wp_post_style, for example. Terms within wp_post_style would be the styles. Some core styles will be pre-populated. The slugs and names will be stored as English. Dummy gettext calls will get the strings into the catalog and later the fetched names can be run through translate().

It can also be implemented as a post meta field. Since there can be only one type per post, a taxonomy could be overkill. Using a taxonomy would, however, make it easier for plugins to add new types persistently.

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_style() and has_post_style().

Change History (36)

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)
Note: See TracTickets for help on using tickets.