Backfill the assets removed from minified WordPress bundles#1604
Conversation
…mments and errors
| } | ||
|
|
||
| /** | ||
| * If the browser is online we can download WordPress assets asynchronously to speed up the boot process. |
There was a problem hiding this comment.
I got a bit confused why that's optional – this should clarify it:
| * If the browser is online we can download WordPress assets asynchronously to speed up the boot process. | |
| * If the browser is online we download the WordPress assets asynchronously to speed up the boot process. |
Also, let's clarify this comment talks about the minified WordPress bundles and that we're not doing either of these when a full production build is used (since it ships all the static assets already).
There was a problem hiding this comment.
I'm reopening this conversation because this isn't addressed yet:
Also, let's clarify this comment talks about the minified WordPress bundles and that we're not doing either of these when a full production build is used (since it ships all the static assets already).
There was a problem hiding this comment.
Done 2ef0bcd. I kept that part short because it's described in detail in the function docblock.
| * If the browser is online we can download WordPress assets asynchronously to speed up the boot process. | ||
| * Missing assets will be fetched on demand from the Playground server until they are downloaded. | ||
| * | ||
| * If the browser is offline, we download WordPress assets synchronously to ensure the Playground is fully functional on load. |
There was a problem hiding this comment.
How are we downloading assets if the browser is offline?
Also, nitpick: Synchronous means blocking, meaning the event loop would be stopped until the download is complete. In here, however, we're not pausing the entire worker but just awaiting the download before continuing the boot process.
There was a problem hiding this comment.
The comment was misleading, this is what it needs to say: _ If the browser is offline, we backfill WordPress assets synchronously from the cache to ensure Playground is fully functional before boot finishes._
There was a problem hiding this comment.
I'm reopening this conversation because this isn't addressed yet:
Synchronous means blocking, meaning the event loop would be stopped until the download is complete. In here, however, we're not pausing the entire worker but just awaiting the download before continuing the boot process.
There was a problem hiding this comment.
I get it now. In my mind, the comment sounded the same, but await and synchronous definitely aren't the same. 3e4cd07
|
Most of my notes are about comments and code style. The only technical blocker I see is this:
How would it download the static assets when the browser is offline? Would it use the |
Co-authored-by: Adam Zieliński <adam@adamziel.com>
The comment was misleading. The difference is that in offline mode boot waits for the backfill to finish, and when offline it doesn't. For offline support to work, the |
Co-authored-by: Adam Zieliński <adam@adamziel.com>
Co-authored-by: Adam Zieliński <adam@adamziel.com>
|
@adamziel I addressed your comments and will merge it now to unblock development. |
…1614) ## Motivation for the change, related issues #1604 accidentally introduced recursive calls to `webApi.backfillStaticFilesRemovedFromMinifiedBuild`. ## Implementation details Update `webApi.backfillStaticFilesRemovedFromMinifiedBuild` to call `phpApi.backfillStaticFilesRemovedFromMinifiedBuild`. ## Testing Instructions (or ideally a Blueprint) - checkout this branch - confirm that there are no errors related to calls to `backfillStaticFilesRemovedFromMinifiedBuild` in the browser console
Motivation for the change, related issues
To achieve offline support we need to download all WordPress files into the Playground filesystem. Today Playground downloads WordPress partially on boot and downloads assets as they are needed using fetch requests.
This PR downloads all assets into the Playground filesystem without blocking the boot process.
Implementation details
Zip files are generated using the WordPress build script and are accessible in the
/wp-VERSION/folder like any other assets.The download is triggered after WordPress is installed. The fetch is async and won't block the boot process.
In case some of the assets are needed immediately on boot they will still be downloaded using fetch to ensure they are available to WordPress.
Once the assets are downloaded they are stored in the Playground filesystem and will be served from there.
Testing Instructions (or ideally a Blueprint)
npx nx bundle-wordpress:nightly playground-wordpress-buildspackages/playground/wordpress-builds/public/wp-nightly/wordpress-static.zipfile was createdwordpress-static.zipfile was downloaded/wp-admin/