"Sticky" post state shows even for non-Post post-types

[johnjamesjacoby]

Reported in the support forums: ​https://wordpress.org/support/topic/sticky-tag-remains/

When users of my Post Type Switcher plugin switch a Post into a Page, that page still shows as "Sticky" in the Pages list-table UI, even though Pages do not support the "sticky" functionality.

[johnjamesjacoby]

Sticky Page in Pages List Table

[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 3 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?

[johnjamesjacoby]

Note that no other post type other than Posts currently shows any of the "Stick to the top of the blog" UI in the Public meta-box or Status & Visibility section of Gutenberg.

So even once a non-Post type post gets added as a Sticky, there is no user-facing way to manage that stickiness within WordPress Admin. This makes sense in a way, because technically the data does not match the expected behavior, but again... I would argue that the availability of the UI depends on either the post-type supporting it or it already being a sticky, not and. That way it can be properly unstuck if desired, without breaking anything.