Merge release/27.2 into trunk - #25916
Merged
Merged
Conversation
Collaborator
Generated by 🚫 Danger |
Contributor
Author
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 33854 | |
| Version | PR #25916 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 702001b | |
| Installation URL | 1ssdkaf93jrq0 |
Contributor
Author
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 33854 | |
| Version | PR #25916 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 702001b | |
| Installation URL | 1hbg9toa91t5g |
…25903) * Rediscover the REST API root when its host does not match the site A blog's stored restApiRootURL can go stale: WP.com Simple sites advertise a public-api.wordpress.com rest_route proxy root, which breaks direct wp/v2 requests once the site migrates to Atomic and an application password starts being used, and a domain change leaves the root pointing at the old host. Because the stored value was never re-validated, features on the core REST API path (such as tags) failed with rest_no_route while WP.com v1.1 features kept working. Treat a host mismatch between the stored API root and the site URL as stale and run API discovery again, persisting the rediscovered root. When rediscovery fails, keep using the stored root so sites with unreachable or disabled discovery are no worse off than before. Roots on the site's own host are used as is, with no extra network traffic. * Propagate cancellation before falling back to the stored REST API root A cancelled API discovery surfaces as a discovery failure rather than a CancellationError, so the stored-root fallback could let a cancelled operation keep running. Check for task cancellation explicitly before applying the fallback. * Compare API root and site hosts using URL values The stale-root check parsed both the stored REST API root and the site URL strings again just to read their hosts. Fetch the site URL as a URL, reuse the already-parsed root, and compare their hosts directly, dropping the string-parsing helper. * Document the expected call frequency of createPasswordIfNeeded
* Attach the current site to the notifications_accessed event The notifications list spans all sites, so no single site is truly scoped to the event. Attach the currently visible (or last used) site so the account-level event carries a blog_id, consistent with other tab-access events. * Attach the site to Jetpack Stats analytics events The Stats analytics bridge (WPAnalyticsStatsTracker) forwarded every JetpackStats event without a blog_id. Pass the viewed site's ID into the tracker and stamp it on each event, so site-scoped Stats events such as jetpack_stats_card_shown and jetpack_stats_main_screen_shown carry a blog_id. * Attach the site to the editor_settings_fetched event * Attach the site to the free_to_paid_plan_dashboard_card_shown event * Attach the site to the blaze_entry_point_displayed event * Attach the site to the my_site_dashboard_shown event * Attach the site to the blogging_prompts_my_site_card_viewed event trackCardViewed is generic across dashboard cards, so this also attaches the site to jetpack_install_full_plugin_card_viewed. * Track notifications_accessed with the currently visible site Switch from currentOrLastBlog() to currentlyVisibleBlog() so the event carries a blog_id only when a site is actually on screen. When none is, track it without a site rather than stamping a stale last-used one. * Remove unused trackBlazeEntryPointDisplayed ObjC bridge The method has no remaining callers. * Attach site_type to Jetpack Stats analytics events Pass the site's BlogAnalyticsProperties snapshot to the Stats bridge instead of a bare site ID, and track through the canonical blogProperties path so every Stats event carries site_type alongside blog_id, consistent with the other site-scoped events.
* Never fall back to plaintext XML-RPC endpoints for https sites When the entered site address is https, WordPressOrgXMLRPCValidator no longer probes an http variant of the same host, and any endpoint that discovery resolves to (via redirects or RSD links) is rejected unless it is also https. Previously the username and application password were sent to the http endpoint whenever the https xmlrpc.php probe failed, and the plaintext endpoint was persisted (GHSA-qxpr-7v78-mh5g). * Use an https XML-RPC endpoint for https sites at request time Older app versions could silently downgrade a site's discovered XML-RPC endpoint to http and persist it, so later XML-RPC traffic and the credentials it carries crossed plaintext (GHSA-qxpr-7v78-mh5g). Blog.xmlrpcURL returns the https-upgraded endpoint for an https site, and every credential bearing XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check) instead of the raw stored value. The persisted xmlrpc and the Keychain keyed by it are left unchanged, so credential lookups still resolve; only the request endpoint is upgraded, at the point the client is constructed. This closes the downgrade regardless of launch timing or store restoration, with no migration pass. * Add a release note --------- Co-authored-by: Jeremy Massel <1123407+jkmassel@users.noreply.github.com>
* Prefer the discovered REST API root over the xmlrpc-derived URL for self-hosted sites `WordPressOrgRestApi(blog:)` built its base URL from `Blog.url(withPath:)`, which rewrites the raw `xmlrpc` string. An older app version could persist an http `xmlrpc` endpoint for an https site (GHSA-qxpr-7v78-mh5g), so the self-hosted REST client — and the application password it carries as a Basic auth header — could be built on http and sent in plaintext. Prefer `restApiRootURL`, the root observed during REST discovery (https for an https site, and always written alongside the application token), falling back to the xmlrpc-derived `wp-json/` URL only when no discovered root was persisted. * Add a release note
crazytonyli
force-pushed
the
merge/release-27.2-into-trunk
branch
from
August 20, 2026 01:18
adbefbe to
702001b
Compare
crazytonyli
approved these changes
Aug 20, 2026
crazytonyli
enabled auto-merge
August 20, 2026 01:21
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Aug 20, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merging
release/27.2intotrunk.Via intermediate branch
merge/release-27.2-into-trunk, to help fix conflicts if any: