[wp-trac] [WordPress Trac] #48954: "Sticky" post state shows even for non-Post post-types

[WordPress Trac]

#48954: "Sticky" post state shows even for non-Post post-types
-------------------------------+------------------------------
 Reporter:  johnjamesjacoby    |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+------------------------------

Comment (by johnjamesjacoby):

 This is ''immediately'' because the `is_sticky()` function does not
 discriminate between types of posts, which I actually think isn't really
 the ultimate problem.

 WordPress appears to check for post-type-stickiness in 2 different ways,
 if at all:

 * `get_inline_data()` uses `if ( ! $post_type_object->hierarchical ) {`
 * `post_submit_meta_box()` uses `elseif ( $post_type == 'post' &&
 is_sticky( $post->ID ) )` and `<?php if ( $post_type == 'post' ) : ?>`
 * `get_post_states()` uses `if ( is_sticky( $post->ID ) ) {`
 * XML-RPC uses `( $entry['post_type'] === 'post' && is_sticky(
 $entry['ID'] ) )`

 Looking at this problem architecturally, I believe stickiness should be
 something that is part of the Post Type Support API, announced via
 `register_post_type()` and checked via `post_type_supports()`.

 Using the above approach, we can normalize these checks similar to Post
 Formats, and we can be confident that the Admin Area UI will never leak
 this information to the user, even if it happens to exist in meta data (or
 in options in this specific case).

 My suggestion could technically be perceived as a breaking change, as
 there is some possibility that someone is making non-Posts sticky, and
 relying on this quirk to display the State. My counter-argument against
 this, is that `get_post_states()` is the only place this quirk exists, and
 `get_inline_data()` is really doing the totally incorrect check no matter
 what.

 Thoughts?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48954#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform