WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 4 months ago

#48954 new defect (bug)

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

Reported by: johnjamesjacoby Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: administration Cc:

Description

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.

Attachments (1)

Screen Shot 2019-12-12 at 3.58.40 PM.png (101.0 KB) - added by johnjamesjacoby 4 months ago.
Sticky Page in Pages List Table

Download all attachments as: .zip

Change History (3)

@johnjamesjacoby
4 months ago

Sticky Page in Pages List Table

#1 @johnjamesjacoby
4 months ago

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?

Last edited 4 months ago by johnjamesjacoby (previous) (diff)

#2 @johnjamesjacoby
4 months ago

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.

Note: See TracTickets for help on using tickets.