REST API: Restore the global post after preparing a revision

[MicahelE]

Trac: https://core.trac.wordpress.org/ticket/65495

WP_REST_Revisions_Controller::prepare_item_for_response() sets the global $post and calls setup_postdata(), but never restores them, so the change leaks for the rest of the request.

The autosaves controller delegates here, and the block editor preloads /autosaves on every load. When the post has a pending autosave, the global $post is left pointing at the autosave, so the editor can initialize with the wrong post id and redirect to it. That presents as the editor randomly opening a different post.

This captures the previous global $post and restores it on every return path (including the HEAD early return), which also covers the autosaves endpoint.

Reproduction (no browser):

wp eval '
$pid = wp_insert_post( array( "post_status" => "publish" ) );
wp_create_post_autosave( array( "post_ID" => $pid, "post_content" => "x", "post_type" => "post" ) );
global $post; $post = get_post( $pid ); setup_postdata( $post );
rest_get_server()->dispatch( new WP_REST_Request( "GET", "/wp/v2/posts/$pid/autosaves" ) );
echo $GLOBALS["post"]->ID === $pid ? "OK" : "LEAKED";
'

Before: LEAKED. After: OK.

Tests: Adds coverage for the restore (GET, HEAD, and the no-global-post case). The existing "sets up postdata" tests were asserting the leak, so they now confirm rendered fields still reflect the revision while the global post is restored.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.8
Used for: Initial implementation and test drafting; final code and tests were reviewed, edited, and verified by me.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props micahele, wildworks, westonruter, dhrupo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Hi there! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

• PHP Coding Standards
• CSS Coding Standards
• HTML Coding Standards
• JavaScript Coding Standards
• Accessibility Coding Standards
• Inline Documentation Standards

Thank you,
The WordPress Project

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[dhrupo]

Test Report

Patch tested: this PR (#12248), applied on top of trunk.

Environment

• WordPress: 7.1-alpha (trunk, 62161-src)
• PHP: 8.3.30
• Web server: nginx 1.29.8
• Database: MySQL 9.7.1
• OS: Debian GNU/Linux 13 (trixie) — the official wordpress-develop Docker environment
• Browser: n/a (verified server-side via WP-CLI)
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: none
• Plugins: none

Steps to reproduce

1. Clean single-site install, default theme, no plugins.
2. Create a published post, then create a pending autosave for it.
3. Set the global $post to the published post and call setup_postdata() (simulating normal page context).
4. Dispatch GET /wp/v2/posts/<id>/autosaves with context=edit — this is exactly what block_editor_rest_api_preload() runs on every block-editor load.
5. Inspect the global $post ID after the request returns.

Reproduction script (WP-CLI), taken from the ticket:

wp_set_current_user( 1 );
$pid = wp_insert_post( array( 'post_title' => 'Repro 65495', 'post_content' => 'original body', 'post_status' => 'publish' ) );
wp_create_post_autosave( array( 'post_ID' => $pid, 'post_title' => 'Repro 65495', 'post_content' => 'autosaved body', 'post_type' => 'post' ) );
global $post; $post = get_post( $pid ); setup_postdata( $post );
$before = (int) $GLOBALS['post']->ID;
$req = new WP_REST_Request( 'GET', "/wp/v2/posts/$pid/autosaves" );
$req->set_param( 'context', 'edit' );
rest_get_server()->dispatch( $req );
$after = (int) $GLOBALS['post']->ID;
printf( "before=%d after=%d => %s\n", $before, $after, $after !== $before ? "LEAKED to $after" : "OK" );

Expected result

After the request, the global $post should still point at the post being edited.

Actual result — trunk (before the patch)

post ID=18, global $post before=18, after=19  =>  LEAKED (now points at autosave revision 19)

The global $post is left pointing at the autosave revision. In the block editor this means edit-form-blocks.php can build wp.editPost.initializeEditor() from the wrong post id, and the editor's history sync then "redirects" to the revision — an intermittent bug that only shows up when a pending autosave exists.

Result — with this PR applied

post ID=20, global $post before=20, after=20  =>  OK (restored)

The previous global $post is restored. Verified as consistent across repeated runs by reverting and re-applying the patch on the same install.

Automated tests

phpunit --filter 'WP_Test_REST_Autosaves_Controller|WP_Test_REST_Revisions_Controller'
OK (105 tests, 549 assertions)

All green, including the new coverage added by this PR:

• WP_Test_REST_Revisions_Controller::test_get_items_restores_global_post
• WP_Test_REST_Revisions_Controller::test_get_items_head_request_restores_global_post — the HEAD early-return path
• WP_Test_REST_Revisions_Controller::test_get_items_without_global_post_leaves_it_unset
• WP_Test_REST_Autosaves_Controller::test_get_item_sets_up_postdata_without_leaking_global_post

Notes

The fix captures the previous global $post before setup_postdata() and restores it on every return path, including the HEAD early-return. It correctly leaves the global unset when there was none beforehand rather than clobbering it, which matches the root cause and the wp_reset_postdata() finding noted in the related #43502. Reproduced the regression, confirmed the fix, and the suite is green — looks good to me. 👍

[westonruter]

@MicahelE Thank you for the PR. Please add the AI disclosure section from the PR template to the description:

wordpress-develop/.github/pull_request_template.md

Lines 22 to 33 in 8071b4a

	## Use of AI Tools
	<!--
	You are free to use artificial intelligence (AI) tooling to contribute, but you must disclose what tooling you are using and to what extent a pull request has been authored by AI. It is your responsibility to review and take responsibility for what AI generates. See the WordPress AI Guidelines: <https://make.wordpress.org/ai/handbook/ai-guidelines/>.
	Example disclosure:
	AI assistance: Yes
	Tool(s): GitHub Copilot, ChatGPT
	Model(s): GPT-5.1
	Used for: Initial code skeleton and test suggestions; final implementation and tests were reviewed and edited by me.
	-->

[MicahelE]

@westonruter I will do that, thanks

[t-hamano]

@MicahelE, do you have the bandwidth to address the feedback? Thank you!

[Copilot]

Pull request overview

Fixes a REST API global state leak where WP_REST_Revisions_Controller::prepare_item_for_response() overwrites global $post / postdata via setup_postdata() and fails to restore them, which can cause downstream request handling (notably block editor autosaves preloading) to behave as if the autosave/revision is the “current” post.

Changes:

• Capture and restore the previous global post when preparing revisions (including the HEAD early-return path).
• Add/adjust PHPUnit coverage to ensure the global post is restored for revisions and autosaves responses.
• Update existing “sets up postdata” tests to validate rendered fields while confirming no global $post leakage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php	Saves/restores the prior global post context during revision response preparation.
tests/phpunit/tests/rest-api/rest-revisions-controller.php	Adds tests for restoring global $post (GET, HEAD, and no-global-post scenarios) and updates postdata assertions.
tests/phpunit/tests/rest-api/rest-autosaves-controller.php	Updates autosave postdata test to verify rendered fields without leaking the global post.

Comments suppressed due to low confidence (1)

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:733

• rest_prepare_revision is applied after calling reset_post_data(), so callbacks for that filter can no longer rely on the revision’s setup_postdata() context (template tags would resolve against the restored post instead of the revision). To avoid a behavior change for existing hooks while still preventing leaks, reset the globals after apply_filters() returns.

		$this->reset_post_data( $previous_post );

		/**
		 * Filters a revision returned from the REST API.
		 *
		 * Allows modification of the revision right before it is returned.
		 *
		 * @since 4.7.0
		 *
		 * @param WP_REST_Response $response The response object.
		 * @param WP_Post          $post     The original revision object.
		 * @param WP_REST_Request  $request  Request used to generate the response.
		 */
		return apply_filters( 'rest_prepare_revision', $response, $post, $request );

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MicahelE]

@t-hamano Thanks for the ping, and for merging trunk in.

I've pushed 8a9d73e, which applies @westonruter's three suggestions:

• @since corrected to 7.1.0
• reset_post_data() now takes ?WP_Post $previous_post and returns void
• The saved global post is guarded with an instanceof WP_Post check

The AI disclosure section was already added to the description.

WP_Test_REST_Revisions_Controller and WP_Test_REST_Autosaves_Controller are green locally (105 tests, 549 assertions).

The Copilot review that came in alongside your comment raises two behavioural points — resetting the globals before rest_prepare_revision fires, and wp_reset_postdata() potentially repopulating $GLOBALS['post'] from $wp_query. I'll look at those separately.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:627

• The global post is reset before running the rest_prepare_revision filter. Any filter callbacks that rely on setup_postdata() having prepared globals for the revision (e.g., calling get_post()/template tags without passing an ID) will now see the previous global post instead, which is a behavior change. Consider restoring globals after the filter runs (but still before returning) so callbacks observe the same revision context while still preventing leakage beyond this method.

		if ( $request->is_method( 'HEAD' ) ) {
			$this->reset_post_data( $previous_post );

			/** This filter is documented in wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php */
			return apply_filters( 'rest_prepare_revision', new WP_REST_Response( array() ), $post, $request );

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:724

• reset_post_data() is called before the final rest_prepare_revision filter. For consistency with existing behavior, filter callbacks should still run while the revision is the global post/postdata, with globals restored immediately afterwards (before returning) to avoid leaking outside this method.

		$this->reset_post_data( $previous_post );

		/**
		 * Filters a revision returned from the REST API.
		 *

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:754

• When there is no previous global post, wp_reset_postdata() may be a no-op (e.g. when $wp_query->post is empty). In that case the other globals populated by setup_postdata() ($id, $authordata, etc.) will still contain the revision’s values and continue leaking into the rest of the request even though $GLOBALS['post'] is unset.

		} else {
			unset( $GLOBALS['post'] );
			wp_reset_postdata();
		}

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:754

• When $previous_post is null, wp_reset_postdata() can repopulate $GLOBALS['post'] from the main query (WP_Query::reset_postdata() sets $GLOBALS['post'] when $wp_query->post is non-empty). That contradicts the intent to leave the global post unset when it was unset before. Unset $GLOBALS['post'] after calling wp_reset_postdata() to preserve the previous state.

		} else {
			unset( $GLOBALS['post'] );
			wp_reset_postdata();
		}

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:627

• reset_post_data() runs before the rest_prepare_revision filter and return. Other REST controllers (e.g. WP_REST_Posts_Controller::prepare_item_for_response() in class-wp-rest-posts-controller.php:1889-1897) keep $GLOBALS['post']/postdata set to the item while running rest_prepare_* filters, so restoring early changes the filter context and can break filter callbacks that rely on global post state. Apply the filter first, then restore globals, then return.

		if ( $request->is_method( 'HEAD' ) ) {
			$this->reset_post_data( $previous_post );

			/** This filter is documented in wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php */
			return apply_filters( 'rest_prepare_revision', new WP_REST_Response( array() ), $post, $request );

src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:720

• reset_post_data() is called before the final rest_prepare_revision filter, which changes the global-post context seen by filter callbacks compared to other REST controllers (which run rest_prepare_* with $GLOBALS['post'] set to the item). Consider running the filter first, then restoring globals, then returning the filtered response.

		$this->reset_post_data( $previous_post );

tests/phpunit/tests/rest-api/rest-autosaves-controller.php:750

• This test indexes into $response->get_data() without asserting the response was successful first. Adding a status assertion improves error reporting if the request fails and avoids notices from unexpected response shapes.

		$request  = new WP_REST_Request( 'GET', '/wp/v2/posts/' . self::$post_id . '/autosaves/' . self::$autosave_post_id );
		$response = rest_get_server()->dispatch( $request );
		$data     = $response->get_data();

tests/phpunit/tests/rest-api/rest-revisions-controller.php:730

• This test reads $response->get_data() and indexes into it without first asserting a successful response. Adding a status assertion here makes failures easier to diagnose and avoids notices if an error response is returned.

		$request  = new WP_REST_Request( 'GET', '/wp/v2/posts/' . self::$post_id . '/revisions/' . $this->revision_id1 );
		$response = rest_get_server()->dispatch( $request );
		$data     = $response->get_data();

[westonruter]

Two follow-ups from reviewing this, neither blocking the fix itself.

1. rest_prepare_autosave now sees the restored global post

WP_REST_Autosaves_Controller::prepare_item_for_response() delegates to the revisions controller and then does the rest of its work:

• delegates to WP_REST_Revisions_Controller::prepare_item_for_response() (line 472)
• computes preview_link (line 485)
• runs add_additional_fields_to_object() (line 489)
• fires rest_prepare_autosave (line 503)

Since the restore happens inside the delegated call, the last three now run with the global post restored, where previously they saw the autosave. So any rest_prepare_autosave callback — or any autosave register_rest_field() get_callback — relying on get_the_ID() or template tags will behave differently after this change.

That looks intended rather than accidental, and it follows naturally from fixing the leak. Flagging it mainly so it can be captured on the ticket and considered for a dev note, since it is a behavior change visible to extenders that the tests here would not catch.

Worth noting the revisions controller itself is unaffected on this point: its add_additional_fields_to_object() call happens before the restore, so revision additional-field callbacks still see the revision.

2. The same unrestored setup_postdata() pattern exists elsewhere

Correction to the original version of this comment: I listed the posts-controller case as an untracked follow-up. It is not — it is Core-43502, the parent ticket that Core-65495 is the counterpart to. Core-65495's own description already says "See Core-43502 (parent/posts controller). This patch is the revisions-controller counterpart and can be committed alongside it." Apologies for the noise.

So, restated:

• WP_REST_Posts_Controller::prepare_item_for_response() sets $GLOBALS['post'] and calls setup_postdata() (lines 1889–1891) with no restore. Already tracked in Core-43502 (status new, milestone Future Release, good-first-bug has-patch has-unit-tests).
• WP_REST_Block_Renderer_Controller::get_item() declares global $post; and calls setup_postdata() (lines 154–162), likewise unrestored. This one I could not find tracked on either ticket, so it may be worth its own.

The posts-controller case is less harmful in the reported scenario, since the post it leaves behind is usually the post being edited rather than an autosave, but it is the same underlying issue.

On the ticket's own reproduction

For what it is worth, the reproduction script in Core-65495's description passes on this branch (before=N after=N => OK) and fails on trunk with the same script (LEAKED), so the ticket's stated symptom is addressed.

One small coverage note: that reproduction uses the autosaves collection route (/wp/v2/posts/<id>/autosaves), whereas the autosaves test added here uses the single-item route (/autosaves/<id>). The revisions tests do cover their collection route. Same delegation either way, so the risk is low, but a collection-route assertion would match the ticket's repro exactly.

Links are pinned to 4eaba0e so the line references stay accurate.

---

This comment was written by Claude Code (model: Claude Opus 5, 1M context) during a review of this PR, and posted after I checked it over. Line references were verified against the pinned commit. Edited to correct the #43502 attribution noted above.

[westonruter]

This ended up being more involved than I thought!

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62952
GitHub commit: 593166d

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.