wordpress-playground
wordpress-playground copied to clipboard
WordPress
CSS files are not loading in the site editor
These files appear to be bypassing the ServiceWorker's fetch listener. The thing they all have in common is being triggered for fetch via react-dom
The site editor is rendered in an iframe and all the requests bypassing the ServiceWorker originate in that iframe:
That nested document seems to be rendered through a React portal:
https://github.com/WordPress/gutenberg/blob/a84db76d51617ed3e3a518ce8ffeb0ad038b13b1/packages/block-editor/src/components/iframe/index.js#L319-L370
Its source is:
> $0.contentWindow.location.href
'about:srcdoc'
It doesn't show up in ServiceWorker's clients.matchAll() and therefore isn't a controlled frame:
It's a known bug in Chrome.
The intended behavior is an about:srcdoc iframe should inherit the ServiceWorker from the parent document – see the discussion in the ServiceWorker repo. That's what Firefox does – see the related issue. I don't know about other browsers.
We can't re-route the static asset requests in the ServiceWorker, but we can do it on the server. We only need to remove the WordPress instance scope from the URL like this:
Before:
/scope:0.8798659149475636/wp-includes/css/dist/block-editor/style.min.css?ver=6.0.1
After:
/wp-includes/css/dist/block-editor/style.min.css?ver=6.0.1
This repo could ship a .htaccess file in dist-web for the Apache users out there, and then provide some documentation to explain the problem.
The iframe also sends a request to load-styles.php and this can't be resolved by simple URL rewriting. Fingers crossed #43 will make that request go away entirely.
Workaround introduced in 5f03281. This behavior still need to be documented.
There's another option here - Make WordPress not output scoped URLs for static resources in the first place.. bypassing the need for the serviceworker to handle it.
This can probably be done through the filters for site_url simply have any links to wp-(content|includes) or wp-admin/*.(css|js) return the scopeless URL..
Perhaps easier though, would be to use the script_loader_src filter which should be able to be used to return scope-less URLs. That probably won't handle the wp-content/* urls to theme assets though.
Make WordPress not output scoped URLs for static resources in the first place.. bypassing the need for the serviceworker to handle it.
Great idea! It should help with most URLs. I don't think serviceworker can be bypassed completely, though, because all the uploads like media files or plugins needs to be served from Wasm's MEMFS. That being said, filtering as you proposed would at least reduce the number of requests routed through the serviceworker.
It's a known bug in Chrome.
The intended behavior is an
about:srcdociframe should inherit the ServiceWorker from the parent document – see the discussion in the ServiceWorker repo. That's what Firefox does – see the related issue. I don't know about other browsers.
@ellatrix explained me that srcDoc was used to force the iframe to use the standards mode and not the quirks mode. I patched the site editor with src: "/doctype.html" and a doctype.html file containing just <!doctype html> and it worked beautifully.
I committed the short-term for this repo in https://github.com/WordPress/wordpress-wasm/commit/b7ca7374a97d74a31fbc6d13f770b0e9245a7951. In the longer term, that fix should be merged directly to Gutenberg.
The original server-side fix can was reverted in 5f0328109ef099e617a1e04e25857da47911c24e.
The only thing left to do here is to open a Gutenberg PR to remove the srcDoc usage in core.
Let's track the Gutenberg PR in https://github.com/WordPress/wordpress-playground/issues/91.