WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#33921 closed defect (bug) (worksforme)

Twenty Fourteen: Featured_Content::get_sticky_posts() not checking post_status

Reported by: stode Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8
Component: Bundled Theme Keywords: 2nd-opinion
Focuses: Cc:
PR Number:

Description

As the method static method Featured_Content::get_sticky_posts() only gets the sticky_post IDs from wp_options table, but does not check that the post_status is equal to publish.

My suggestion would be:

/**
* Return an array with IDs of posts marked as sticky.
*
* @static
* @access public
* @since Twenty Fourteen 1.0
*
* @return array Array of published sticky posts.
*/
public static function get_sticky_posts() {

		 $args = array(
		 	'fields'           => 'ids',
			'numberposts'      => self::$max_posts,
			'post_type'        => 'post',
			'post_status'      => 'publish',
			'suppress_filters' => false,
			'post__in'         => get_option( 'sticky_posts' , array()), 
		);
		$sticky_post_ids = get_posts( $args );

		return $sticky_post_ids;
	}

Change History (6)

#1 follow-up: @SergeyBiryukov
4 years ago

  • Focuses accessibility removed
  • Keywords reporter-feedback added

Hi @stode, welcome to Trac!

I could not reproduce the issue. My steps:

  1. Create a draft sticky post.
  2. Make sure I don't have a featured tag.
  3. Clear the 'featured_content_ids' transient in the database.
  4. The featured content section displays published sticky posts, but not the draft post.

Featured_Content::get_sticky_posts() indeed just returns the value of 'sticky_posts' option without any further checking.

However, when Featured_Content::get_featured_posts() calls get_posts() later, the implicit default post_status value is applied, which is publish.

#2 in reply to: ↑ 1 @stode
4 years ago

Thanks @SergeyBiryukov,

Your observation is right.

I did not describe the problem properly. The test case for me was that I had a limit set to fetch five IDs by Featured_Content::get_sticky_posts() and all of the IDs were drafts. No featured posts were returned, because the method did not get to those IDs that had a post_status equal to publish.

Bottom line I was expecting five featured posts, but got none.

Replying to SergeyBiryukov:

Hi @stode, welcome to Trac!

I could not reproduce the issue. My steps:

  1. Create a draft sticky post.
  2. Make sure I don't have a featured tag.
  3. Clear the 'featured_content_ids' transient in the database.
  4. The featured content section displays published sticky posts, but not the draft post.

Featured_Content::get_sticky_posts() indeed just returns the value of 'sticky_posts' option without any further checking.

However, when Featured_Content::get_featured_posts() calls get_posts() later, the implicit default post_status value is applied, which is publish.

Last edited 4 years ago by stode (previous) (diff)

#3 @stode
4 years ago

  • Keywords reporter-feedback removed
  • Summary changed from Twenty Fourteen: Featured_Content::get_sticky_posts() getting also non published posts to Twenty Fourteen: Featured_Content::get_sticky_posts() not checking post_status

I would ask that, do you @SergeyBiryukov, think that this is a too much of an edge case or a relevent addition to the method to check for post_status?

#4 @obenland
4 years ago

  • Version changed from trunk to 3.8

#5 @karmatosed
4 years ago

  • Keywords 2nd-opinion added

I'm not sure about adding post status there. I can see how it would avoid but if you have lots of drafts this is something you'd also expect. I'm open to changing it if enough think it's not edge though.

#6 @karmatosed
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

For now, I am closing this as there are issues with reproducing and the issues around this.

Note: See TracTickets for help on using tickets.