[wp-trac] [WordPress Trac] #12702: Enable sticky post checkbox for custom post type Publish metabox

[WordPress Trac]

#12702: Enable sticky post checkbox for custom post type Publish metabox
-------------------------------------------------+-------------------------
 Reporter:  phlux0r                              |       Owner:
     Type:  feature request                      |      Status:  reopened
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Posts, Post Types                    |  Review
 Severity:  normal                               |     Version:
 Keywords:  dev-feedback has-patch 2nd-opinion   |  Resolution:
  close                                          |     Focuses:
-------------------------------------------------+-------------------------
Changes (by boonebgorges):

 * keywords:  dev-feedback has-patch 2nd-opinion => dev-feedback has-patch
     2nd-opinion close


Comment:

 IMO implementing the filter proposed in [attachment:wp_admin_meta-
 boxes.2.diff] is a non-started because of the workflow issues raised in
 nacin's comment here:
 https://core.trac.wordpress.org/ticket/12702#comment:28. A filter is an
 invitation to developers to add sticky post types. But simply making CPTs
 sticky is pretty lousy UX out of the box, because "sticky" is ambiguous
 between (a) stuck to the top of CPT archives, (b) stuck to the top of the
 home page when the CPT is included in the home page query, (c) stuck to
 the top of the home page no matter what. I'd wager that a fair number of
 users would expect any of these to be the behavior of the checkbox, which
 suggests that a checkbox is not a great UI for it.

 #23336 reenforces the decision, as it demonstrates that sticky support -
 even for posts - is not on solid ground. Encouraging devs to enable sticky
 CPTs will encourage a greater number of stickies, which will exacerbate
 these latent performance issues.

 Making sticky logic work for CPTs is going to be a larger project. As
 [https://core.trac.wordpress.org/ticket/12702#comment:45 mbijon suggests],
 this is a great opportunity to a feature plugin to show a better way to
 implement stickies, both in the UI and the underlying architecture.
 However, I disagree with this quote:

 > The reason we think it's a core issue is b/c stickies aren't currently
 filterable. We can't build a plugin that affects them directly. (a plugin
 that adds a "stickies" taxonomy, sure, but it wouldn't be any different
 from adding a tax' in your theme)

 Plugins can (1) add a meta box to add new UI, and (2) use filters like
 pre_get_posts. This is plenty to build a plugin that demonstrates a better
 way to do stickies. (I think a separate tax is probably worth exploring.)

 I'm suggesting we close this ticket as 'maybelater', with the
 understanding that "later" is "when a plugin shows how we can fix the
 underlying issues".

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