fix: Fixes the broken caching issue in get_blog_details()

[apermo]

When get_blog_details() is called with $get_all = true first, the full result is cached. A subsequent call with $get_all=false incorrectly returns the full cached result instead of a short one.

The "try the other cache" block now discards the full cache hit when short is requested, allowing WP_Site::get_instance() to build a clean short result without an extra DB query.

Trac ticket: https://core.trac.wordpress.org/ticket/63518#ticket

Use of AI Tools

AI used to dig deeper into the issue, to write documentation and to help writing unit test.
Everything generated was reviewed afterwards.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[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 apermo, johnjamesjacoby, wildworks, dmsnell, westonruter.

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

[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.

[apermo]

Failing test: Tests_Error_Protection_wpRecoveryModeKeyService::test_validate_recovery_mode_key_returns_wp_error_if_bad

Issue: Expects 'invalid_recovery_key_format' but gets 'token_not_found'
Likely unrelated to get_blog_details() or the changes from the PR. AI research is suggesting a cache-related race condition in that test.

[apermo]

@dmsnell @westonruter does anyone of the two of you have time to review this maybe?

[Copilot]

Pull request overview

This PR fixes a multisite caching edge case in get_blog_details() where a cached “full” site object could be returned for a later “short” request, causing callers to receive extra fields they didn’t ask for.

Changes:

• Adjusts the “try the other cache” fallback so a short request will not return a full cached object.
• Adds PHPUnit coverage for the call-order scenarios that previously produced incorrect (full) fields for short requests.

Reviewed changes

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

File	Description
src/wp-includes/ms-blogs.php	Prevents short requests from returning a full cached object by discarding that cache hit and rebuilding a proper short result.
tests/phpunit/tests/multisite/getBlogDetails.php	Adds regression tests ensuring short requests return only short fields even after full-cache priming.

---

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

[dmsnell]

@apermo I’m quite behind on reviews, and focusing 100% on security right now. I’m not familiar enough with this code to feel capable of giving it a proper review. I would recommend trying to find someone with more experience in the caching or query layer.

not sure if @peterwilsoncc would know whom to recommend, or if he has time.

[westonruter]

@apermo This is now closely related to #13270 for Core-65962.

It seems like additional type hardening could be done, and some of the logic seems redundant in trunk. If a serialized WP_Site is what is being stored in object-cache, it seems this should be what is checked for. At first glance this seems warranted:

diff --git a/src/wp-includes/ms-blogs.php b/src/wp-includes/ms-blogs.php
index 30e8cf1894..d8bb35cdd9 100644
--- a/src/wp-includes/ms-blogs.php
+++ b/src/wp-includes/ms-blogs.php
@@ -191,7 +191,7 @@ function get_blog_details( $fields = null, $get_all = true ) {
 	$details = wp_cache_get( $blog_id . $all, 'blog-details' );
 
 	if ( $details ) {
-		if ( ! is_object( $details ) ) {
+		if ( ! $details instanceof WP_Site ) {
 			if ( -1 === $details ) {
 				return false;
 			} else {
@@ -210,23 +210,23 @@ function get_blog_details( $fields = null, $get_all = true ) {
 	} else {
 		$details = wp_cache_get( $blog_id, 'blog-details' );
 		if ( $details ) {
-			if ( ! is_object( $details ) ) {
+			if ( ! $details instanceof WP_Site ) {
 				if ( -1 === $details ) {
 					return false;
 				} else {
 					// Clear old pre-serialized objects. Cache clients do better with that.
 					wp_cache_delete( $blog_id, 'blog-details' );
-					unset( $details );
+					$details = null;
 				}
 			} else {
 				// Full cache is set but short was requested. Discard so a clean
 				// short result is built from WP_Site::get_instance() below.
-				unset( $details );
+				$details = null;
 			}
 		}
 	}
 
-	if ( empty( $details ) ) {
+	if ( ! $details instanceof WP_Site ) {
 		$details = WP_Site::get_instance( $blog_id );
 		if ( ! $details ) {
 			// Set the full cache.
@@ -235,10 +235,6 @@ function get_blog_details( $fields = null, $get_all = true ) {
 		}
 	}
 
-	if ( ! $details instanceof WP_Site ) {
-		$details = new WP_Site( $details );
-	}
-
 	if ( ! $get_all ) {
 		wp_cache_set( $blog_id . $all, $details, 'blog-details' );
 		return $details;

I'll admit that the logic in get_blog_details() is unfamiliar to me (and somewhat confusing to me too).