[wp-trac] [WordPress Trac] #12702: Enable sticky post checkbox for custom post type Publish metabox
noreply at wordpress.org
Thu Mar 10 18:35:40 UTC 2016
#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:
Comment (by MrGregWaugh):
Replying to [comment:66 azizur]:
> Hello everyone,
> As someone who invested a lot of energy into this about 6 years ago. I
have left it here for many reason. I have since them moved to do other
things, because at the time I miss understood what was expected by
#comment:28, #comment:29, #comment:42, and #comment:45. I guess I did not
totally understood the requirements defined by @nacin at the time.
> As for the solution proposed by @MrGregWaugh it would not work as
mentioned in #comment:58.
> If you really want this feature here is what I assume you'd need to do:
> * Create a feature plugin
> * Address all the concerns raised in the discussion here in regards to
> * define a better user experience
> In the plugin you'll need to think about few UX concerns raised in
> > 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.)
> Depending on how you implement stickies you'll have to figure out how it
all works for majority of users. I am so far removed from WordPress lately
so I can only help shape the requirements and guide on implementation.
So it seems to me there are a few separate items being discussed here:
1. Is this a "good idea" to offer sticky support of custom post types?
(not technically, philosophically)
2. Is the current UI pattern for sticky posts where we would like it to
3. Is the current implementation of sticky posts where we would like it
My responses to my own questions:
1. I believe that if there is functionality that benefits users, and is
being asked for and effectively already exists, I cannot see why it would
be blocked only at the UI level (due to a a hard-coded post_type = 'post'
conditional). Since this would be not enabled by default, there would be
no impact on the current install base.
At the end of the day the only difference between 'post' and a custom post
type should be entirely semantic. I don't really agree that there should
be special behavior that only works on 'post', and not any others. Not
everybody uses CPTs in exactly the same way, and offering an option for
those uses seems like a step forward.
2. I would be surprised to hear people jumping up to say that the UI as
it exists in the post editor is ideal. However, it is the UI we have now
-- and for better or worse, is what the entire WP user base is used to.
3. Same as above I would suspect. I don't believe anybody believes that
the current implementation is ideal either, and we'd all like for a new
way to do it. Once again though, it is the implementation we have today
and there is no roadmap that I'm aware of to replace it in core.
In terms of performance concerns, I get that it's far from the idea
solution. However there's nothing that would prevent those concerns from
occurring the way it works now, and there's no way to be sure that just by
having this enabled would be any worse than now. If it's really as so bad
as to be a great concern, let's deprecate the entire thing in a future
The fact that sticky posts on CPTs work out of the box, limited only by
the display of the checkbox in the UI is the source of this ask. The
functionality is 98% complete, so can we just do the last 2%? Since there
is no imminent replacement, and no imminent plan to remove sticky posts
for 'post' post types from core, I'm suggesting this one small tweak.
Thanks for your time!
Ticket URL: <https://core.trac.wordpress.org/ticket/12702#comment:67>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac