setup_postdata should be able to accept a Post ID, currently requires full WP Post object

[sc0ttkclark]

You should have to get_post before calling setup_postdata, the function (and by extension $wp_query->setup_postdata) should be able to accept an ID.

Currently, setup_postdata() expects a full WP_Post (or faux standard post) object.

Something as easy as this could allow for this to function:

	public function setup_postdata( $post ) {
		global $id, $authordata, $currentday, $currentmonth, $page, $pages, $multipage, $more, $numpages;

		if ( ! is_object( $post ) ) {
			$post = get_post( $post );

			if ( ! $post ) {
				return false;
			}
		}

		$id = (int) $post->ID;

This also has a fallback with a return false, which sticks with the bool typed return already documented.

It solves cases where you may want to use WP template tags but all you have is a Post ID from another variable or from an option / transient / cached object.

This can allow for 3 additional tests to be added to test setup_postdata( $post_id ) will return true and setup the post, setup_postdata( $null_or_anything_invalid ) will return false, and setup_postdata( $post ) will return true and setup the post as normal with little to no overhead or ill effects.

[sc0ttkclark]

I have found only one gotcha, which would be that get_post() will return the current global post object, if $post is empty.

This can be alleviated by:

	public function setup_postdata( $post ) {
		global $id, $authordata, $currentday, $currentmonth, $page, $pages, $multipage, $more, $numpages;

		if ( empty( $post ) ) {
			return false;
		} elseif ( ! is_object( $post ) ) {
			$post = get_post( $post );

			if ( ! $post ) {
				return false;
			}
		}

		$id = (int) $post->ID;

[boonebgorges]

This seems reasonable. We should be able to simplify your suggested logic a bit: if ( ! ( $post instanceof WP_Post ) ) { $post = get_post( $post ); } will cover either an int or a faux-WP_Post object.

I'd like to see some unit tests for the various scenarios you've laid out (int, faux post, WP_Post; $post global populated vs not populated).

[sc0ttkclark]

I'll work up the unit tests, etc.

I think at the same time, what should be happening is the global $post be set from setup_postdata too, since setup_postdata sets all other globals, but leaves out the $post global itself.

I further propose we add a global $post set from the $post variable sent to setup_postdata at the end of the local $post setup in if ( ! ( $post instanceof WP_Post )

[mordauk]

30970.patch modifies setup_postdata() to support passing a post ID or post object.

[mordauk]

Oh, 30970.patch also changes it to setup the global $post var.

[mordauk]

Modifying the global $post was breaking tests and, in hindsight, is probably really dangerous, so 30970.2.patch is an updated version that does not modify $post.

30970-tests.patch includes some simple unit tests.

[wonderboymusic]

30970.diff​ combines and cleans up the patches. I'm not really sure what the point of Tests_Query_SetupPostdata::test_fake_post() is...?

[boonebgorges]

In 34089:

Allow setup_postdata() to accept a post ID.

Previously, it accepted only a full post object.

Props sc0ttclark, mordauk, wonderboymusic.
Fixes #30970.