Repository navigation
[Playground Web] Prefetch initial wp-admin update checks - #2295
Merged
Merged
Conversation
adamziel
marked this pull request as ready for review
June 23, 2025 09:57
adamziel
commented
Jun 23, 2025
| 'https://playground.wordpress.net', | ||
| 'http://localhost', | ||
| 'http://127.0.0.1', | ||
| 'http://127.0.0.1:5400', |
Collaborator
Author
There was a problem hiding this comment.
Turns out the local proxy wasn't proxying the network calls – the origin contains a port number
Collaborator
Author
There was a problem hiding this comment.
Maybe we could also clean up the port-less entries above
Collaborator
Author
There was a problem hiding this comment.
Actually no, I'll leave them for testing on port 80.
Collaborator
Author
|
This is a low-risk change. I'll go ahead and merge. |
adamziel
added a commit
that referenced
this pull request
Jun 24, 2025
Enables the `networking` setting by default on playground.wordpress.net. It grants new Playgrounds network access without having to explicitly enable it. It can still be disabled. Having networking disabled by default is a performance optimization but also a major gotcha. Server-side WordPress typically has unrestricted network access. #2295 resolves the performance issue, removing the last blocker to changing the default setting. This PR also updates the documentation pages. Solves #1225 Solves #85 ## Testing instructions * Open local Playground and confirm the networking is enabled. * Play with the networking checkbox in Playground settings, confirm you can disable and re-enable network access. * Ditto for `?networking=yes|no` in the query params * Ditto for `{"features": { "networking": true | false }}` in Blueprints cc @fellyph
Comment on lines
+310
to
+318
| /** | ||
| * Do not await these promises. They're already in the cache at this point, | ||
| * and calling await setupFetchNetworkTransport() is only meant to await | ||
| * loading these requests into the cache, not await the responses. If the caller | ||
| * wants to await the responses they can call Promise.all() on the returned | ||
| * array. | ||
| */ | ||
| return fetchPromises; | ||
| } |
This was referenced Aug 4, 2025
adamziel
added a commit
that referenced
this pull request
Aug 6, 2025
#2295 added pre-fetching of all the api.wp.org/update-check requests in Playground Web. Unfortunately, it also generates some noise in the output: ``` [04-Aug-2025 17:10:25 UTC] PHP Warning: wp_update_plugins(): An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /wordpress/wp-includes/functions.php on line 135 [04-Aug-2025 17:10:25 UTC] PHP Warning: wp_update_themes(): An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /wordpress/wp-includes/functions.php on line 135 [04-Aug-2025 17:10:25 UTC] PHP Warning: wp_version_check(): An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /wordpress/wp-includes/functions.php on line 135 ``` This PR suppresses those warnings without suppressing other errors. cc @draganescu ## Testing instructions 1. Go to http://127.0.0.1:5400/website-server/?php=8.0 2. Confirm the warnings mentioned above are not present in the browser devtools
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
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.
This PR improves /wp-admin/ initial loading speed by pre-fetching all the
api.wp.org/update-checkrequests.Motivation
Enabling networking by default is a frequently requested feature. The only limiting factor is how
/wp-admin/takes 5-10 seconds to load for the first time because of all theapi.wp.orgrequests it performs on the first visit. It checks for PHP and browser compatibility with the corrent WP version and for newer versions of plugins, themes, and WP core. That's 5 sequential requests in total.It's typically not a problem on a server, but in Playground it can be painful: the requests are already slower (e.g. due to preflight) and also the user experiences the slowdown every time they create a new Playground. This PR alleviates that pain.
Implementation
This PR parallelizes this initial burst of 5 network requests. Here's how:
After WordPress is set up, we call all the update checks, remember the requests, and respond with error 500 without actually interacting with the network:
Then, we initiate all these requests in parallel via
Promise.all([ fetch(request1), fetch(request2), ... ]). We don't actually block the boot on the completion of these requests. We only initiate them and store the promises for later.When WordPress runs these network requests again on the initial
/wp-admin/load, we reuse the pre-initialized promises.Testing instructions