Enable sticky post checkbox for custom post type Publish metabox

[phlux0r]

When a custom post type is created, there is no checkbox to mark it as a "Sticky" post.

In meta-boxes.php there is a check: if ($post_type == 'post'): <Show sticky checkbox> endif;

Can this be removed?

The sticky posts feature currently can't handle custom post types.

@ryan

OK that's interesting because I hacked the code to enable stickies for all post types and it seems to work as I expect.

Still, you know the code better than I do :) so I have to take your word for it.

Cheers.

phlux0r: You may submit a patch if you wish, I see no reason why it couldnt be implemented in 3.1.

I was hoping to use this feature and came across this trac item. But if this is added, I think it should be listed as one of the "supports" features in the register_post_type call. As not everyone will want that behaviour, and there needs to be a way to disable/enable.

Currently working on a project that require stickies on custom post types.

I have a working patch to enable support for stickies on custom_post_type for review.

This is my second patch on WordPress core so be gentle with your reviews.

Enable sticky post checkbox for custom post type

Replying to azizur:

This is my second patch on WordPress core so be gentle with your reviews.

As requested:

Strings cannot be broken up like this: 'Stick this '. $post->post_type .' to the front page'. Instead, we'd use sprintf notation, such as 'Stick this %s to the front page'. However, that is not translatable, so we wouldn't do that either.

In this case, I would suggest we introduce a new string: 'Stick this to the front page', and just use that. If that is not obvious enough for newer users (we have the Help tab remember that is used to explain what 'Stick' means anyway) then we can have one string that includes 'this post' and one that just says 'this'. It beats needing to have a new string registered by the post type.

post_type_supports() is a very fast function, so for readability purposes it would be better to just use post_type_supports('sticky-posts') instead of assigning it to a variable.

Also, instead of conditionally checking for the 'post' post_type, sticky-posts should instead be added to the supports argument of the register_post_type for the 'post' post type. Keep in mind such support could also be removed via remove_post_type_support() -- internal post types should be treated like any other custom post type as much as possible.

Finally, something not addressed in the patch that I thought about when I saw this ticket a few weeks ago. I think implementing this might cause some themes or widgets to get a little weird. Some themes grab get_option('sticky_posts') and send that right into a query via post__in, which means they might end up with posts of custom post types all of a sudden, and that might not be desired. I'm not sure if this is something we need to prevent, as a custom post type is kind of a package deal on a site, something the theme needs to be cognizant of and designed for. (Alternatively, we could introduce a new option that stores all sticky posts regardless of type.)

Thank you Andrew for your feedback.

I am thinking how best to implement this patch. My working copy does the following:

For each custom_post_type there will be a additional sticky_{custom_post_type} option. Which will leave current sticky_posts option untouched. Only drawback on this is that we'd end up with more options (one per custom_post_type).

Replying to nacin:

Finally, something not addressed in the patch that I thought about when I saw this ticket a few weeks ago. I think implementing this might cause some themes or widgets to get a little weird. Some themes grab get_option('sticky_posts') and send that right into a query via post__in, which means they might end up with posts of custom post types all of a sudden, and that might not be desired. I'm not sure if this is something we need to prevent, as a custom post type is kind of a package deal on a site, something the theme needs to be cognizant of and designed for. (Alternatively, we could introduce a new option that stores all sticky posts regardless of type.)

Here is what I am thinking of doing and would be interested on your views.

How about converting the option 'sticky_posts' to a object for example:

sticky_posts => array('posts'=>array(current_data), 'custom_1'=>array(), 'custom_N'=>array());

This would reduce the number of options but also would break any plugin currently accessing this option directly.

Replying to nacin:

... Some themes grab get_option('sticky_posts') and send that right into a query via post_in, which means they might end up with posts of custom post types all of a sudden, and that might not be desired. ...

We could introduce a new default conditional parameter 'show_all_sticky' == false on get_posts() and use it to address above issue.

This will give developers additional query parameter to get combined sticky post across all post_types that has support for 'sticky'. Good for grabing all the stickies and then display accordingly.

Patch 2: Enable sticky post checkbox for custom post type

For each custom_post_type there will be a additional sticky_{custom_post_type} option.

In doing so, you've bypassed the problem of

I think implementing this might cause some themes or widgets to get a little weird. Some themes grab get_option('sticky_posts') and send that right into a query via postin, which means they might end up with posts of custom post types all of a sudden

If a theme wants to display a list of sticky posts in all post types, then it's simple to array_merge() them all, or if a plugin wants their sticky posts to show in the list of sticky posts on the front end, its a simple filter addition (if !is_admin(), add filter for pre_get_option_sticky_posts, array_merge in get_option('sticky_issues'); ), ie. Leave it up to the plugin to deal with that side of things..

Reviewing the second patch:

Instead of sticky_{post_type} we can do a single option that holds all sticky IDs, grouped by post type. We can then just keep sticky_posts sync'd for theme usage purposes.

It's actually not the O(N) options that concern me, but the fact that they're not properly set up and thus we may be running queries on nonexistent options. That's no fun.

Anyone else have an idea on how to store it all?

Replying to nacin:

Instead of sticky_{post_type} we can do a single option that holds all sticky IDs, grouped by post type. We can then just keep sticky_posts sync'd for theme usage purposes.

I agree with you about single option. We'd need to upgrade the current option such way that it does not break the site. I'll work on a patch for review.

Enable sticky for custom post type r15659

New Patch ready for review.

I assumed as part of the 3.1 release we'd have an upgrade script to move current stickies to new format (stickies grouped by post type).

The implementation of #8466 is affected by this.

I was talking with dd32 and we were wondering whether we could indeed get away with storing custom post type stickies in get_option('sticky_posts'). The only contraindication I can think of is a theme that fetches that value and counts it, or something along those lines. As it is, that approach is already flawed, as a post can be sticky but doesn't need to be published, so their count would be off. Thus, we're only adding an additional dynamic as allowing posts of other types to be stickies.

(In [15742]) Sticky post support for post types, first pass. see #12702, props azizur.

Due to some logic in WP_Query, non-post sticky posts are being shown at the top of the loop. That needs to be corrected.

	if ( current_user_can( 'edit_others_posts' ) ) {
		if ( !empty($post_data['sticky']) )
			stick_post($post_ID);
		else
			unstick_post($post_ID);
	}

Just stumbled across that code in edit_post(). Thinking we need to pull the post type object and do a proper cap check there, otherwise someone will need the post edit_others_post cap for a custom post type to properly stick/unstick.

(In [16004]) Don't check the raw edit_others_posts cap. see #12702.

This needs to get wrapped up in the next couple of days if it is going to make it into 3.1.

Replying to nacin:

Due to some logic in WP_Query, non-post sticky posts are being shown at the top of the loop. That needs to be corrected.

I am unable to reproduce it using trunk (tried it against r16073). I assume any this issue has been resolved.

Punting due to beta.

This is already done, minus a potential bug I need to try to reproduce again.

After some deliberation and an epiphany of sorts, I'm strongly considering a complete revert of this.

Currently, sticky posts are only integrated into the loop if is_home and not is_paged.

Sticky posts of a custom post type would thus only be included if the loop also includes that post type in the query. (Looks like that logic is there.)

However, this opens up an issue where we're blurring the line between CPTs and posts, such that CPTs should be non-post content. If you want stuff to appear in the main loop everywhere, then chances are you shouldn't be using a CPT.

It also further opens up an issue where the post type and the loop must cooperate and be in sync. If the loop doesn't include that post type, then a post type supporting sticky-posts is just a useless UI element.

The other option is that a stickied CPT should then appear at the top of is_post_type_archive rather than is_home. (Indeed, is_home is roughly synonymous to is_post_type_archive, but for posts.) But then that requires the support of has_archive.

I should note that stick_post() and unstick_post() make no checks on the post type. So I'm thinking I leave [16004] in, and revert [15742] to be considered again in the future.

Replying to nacin:

The other option is that a stickied CPT should then appear at the top of is_post_type_archive rather than is_home. (Indeed, is_home is roughly synonymous to is_post_type_archive, but for posts.) But then that requires the support of has_archive.

This is the only scenario in which sticky posts of a CPT should be supported in core. If putting them in the main blog posts loop, they probably should just be regular posts.

(In [16680]) Revert [15742]. Custom post types and sticky posts don't mix. fixes #12702.

Should the 'sticky' option also be removed from the 'supports' argument in register_post_type?

Looks like that wasn't properly merged out. Thanks.

(In [16698]) Remove sticky arg from post support. props michaelh, see #12702.

Not sure what the current status is here, but I would like to see the option of adding "sticky" to CPT. I have created a CPT for Testimonials and the option to show one as sticky would be greatly beneficial. I would argue that not all items that would be used as sticky should just be a standard post. While I could use posts and create a category named Testimonials, this would be more complicated than a nicely setup Testimonials interface for the end user.

If you look at the ever popular Book/Movie custom post type examples, I could see the application of a "Featured Book" or "Featured Movie" in which the sticky feature would be of great benefit. And yes, we could also use custom fields to manage this, but again, this is more complicated than just a checkbox to make it sticky. That's why the feature was added to begin with, because it was popular and this was easier than developers always using custom fields to make this happen (very complicated for the casual user.)

Please reconsider this as an added feature. I do think it would have great benefits to developers and users, as well as bring consistency from standard WP posts to custom post types for the same features.

Re-closing this as fixed on 3.1.

Comments 28 and 29 describe the thinking on how this should be implemented. Honestly, I don't see sticky posts being particularly relevant here. It sounds like it should be left to a plugin to add a checkbox and store the value.

Any proposals belong in a new ticket.