stylesheet-relative url(...)s not rewritten in post-processed editor styles

[strarsis]

Description

stylesheet-relative url(...)s are not rewritten in post-processed editor styles.
As the post-processed CSS is added as inline-styles, these stylesheet-relative URLs don't resolve correctly anymore.
While in frontend the URLs are correctly loaded, in editor/backend they fail to load.

Edit: There is actually a test for rewriting those URLs:

gutenberg/packages/block-editor/src/utils/transform-styles/transforms/test/url-rewrite.js

Line 8 in 239a7ce

it( 'should replace relative paths', () => {

But it doesn't work for these styles...

Step-by-step reproduction instructions

1. Add a CSS file with stylesheet-relative url(...)s (e.g. .test { background: url('images/test.jpg'); }) as editor style (add_editor_style(...)) inside a theme.
2. Open the Gutenberg editor using that theme, so the editor styles are used.
   Note that the injected, post-processed CSS still uses the stylesheet-relative url(...)s.

Screenshots, screen recording, code snippet

E.g. app.css:

.test {
  background: url('images/test.jpg');
}

Environment info

• WordPress 5.9.3
• Gutenberg Plugin 13.2.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[strarsis]

Update: The underlying issue for the missing URL rewriting isn't located in the CSS transform but the editor style definition passed to the Gutenberg Block Editor, where for remotely fetched editor styles (by URL) no baseURL is added.

Related WordPress trac ticket: https://core.trac.wordpress.org/ticket/55728#ticket

[ndiego]

I am closing this issue in favor of the Trac issue, but can confirm the issue exists.

[ethanclevenger91]

@ndiego That trac ticket doesn't seem to be the same thing. That trac ticket is regarding using an absolute URL as an argument to add_editor_style, while this issue is about relative URLs within the stylesheet.

[skorasaurus]

This can be now closed with the introduction of PostCSS; I did attempt to reproduce this and I am unable to; the image loads as expected in the editor

[cb3rnard]

Hello !
I have a similar configuration and while the url are ok within the post editor, I still have issues in the Full Site Editor iframe. In that case, my styles added with
$relAppCssPath = asset('app.css')->relativePath(get_theme_file_path());
add_editor_style($relAppCssPath);
are not prefixed with '.editor-styles-wrapper' and relative url (to fonts) aren't working.
Could it be because of the url of the iframe, which is prefixed with "blob:" ?

[strarsis]

@cb3rnard: asset('app.css')->relativePath suggests this being usedin a roots.io Sage theme.
On first glance this looks correct (see this Sage 10 + FSE example: https://github.com/strarsis/sage10-fse/blob/master/app/setup.php#L42-L43).

Are those styles added at all, simply not prefixed?
You would find the injected, original styles nested inside the passed JavaScript argument, inside the editor page HTML markup:

wp.domReady( function() {
			wp.editSite.initializeEditor( "site-editor",

[cb3rnard]

@strarsis Sorry I didn't realise I was out of Sage's Github ! I am in deed using Sage 10, based on @dsturm setup (which is based on yours, which I also used recently) for FSE features. I had the same issue with a similar configuration. Maybe I should move this subject elsewhere...

Styles are added, but not prefixed. url(...) is not correctly interpreted.
I can also see the injected styles from wp.editSite.initializeEditor() containing my app style.

[strarsis]

@cb3rnard: Can you post the CSS that is not correctly processed (as with url(...))?

[cb3rnard]

Off course. Here is below a small extract of the inline <style> tag in the iframe, computed from my compiled app.css. As you can see on 'container' class, it is not prefixed.

The font-face url is a relative path, but the files are not downloaded. I don't have any backgrounds url(...) on that site but I had already had the same issue with it.

*,
:after,
:before {
--tw-border-spacing-x: 0;
--tw-border-spacing-y: 0;
--tw-translate-x: 0;
--tw-translate-y: 0;
--tw-rotate: 0;
--tw-skew-x: 0;
--tw-skew-y: 0;
--tw-scale-x: 1;
--tw-scale-y: 1;
--tw-pan-x: ;
--tw-pan-y: ;
/* ... */
}

.container {
width: 100%;
}

/* ... */

@font-face {
font-display: swap;
font-family: Futura;
font-style: normal;
font-weight: 700;
src: url(/app/themes/charivari/public/fonts/Futura_Std_Bold.73fa7e.woff2) format("woff2"),;
}

@font-face {
font-display: swap;
font-family: Bariol;
font-style: normal;
font-weight: 400;
src: url(/app/themes/charivari/public/fonts/Bariol_Regular.9459c8.woff2) format("woff2"),;
}

.siteFooter {
padding: 6rem 4rem 2rem;
}

[strarsis]

@cb3rnard: So with recent WordPress core the Gutenberg editor uses iframe-based style isolation and the CSS is not post-processed anymore (see #46212 (comment)).

Can you request the @font-face files referenced by the font srcs, /app/themes/charivari/public/fonts/Futura_Std_Bold.73fa7e.woff2 or /app/themes/charivari/public/fonts/Bariol_Regular.9459c8.woff2?
Does it work when you simply put those URLs into the browser, with the site domain prepended?

[cb3rnard]

It does work from the url, on the front, or in the post edit page when the visual editor is in desktop mode (= no iframe).
I see on #46212 that CSS is no longer scoped, but does that mean that the relative url should work?

[strarsis]

I see on #46212 that CSS is no longer scoped, but does that mean that the relative url should work?

That is actually an issue I encountered myself recently: host-relative URLs (as in your case) apparently do not work.
You could make those URLs absolute, do the font files and other resources load then?

[cb3rnard]

I checked to be sure, absolute url load correctly in the editor iframe. Do you think this is a sage related issue ? Doesn't seem to be a lot of posts mentioning that, although that's both quite annoying.

[strarsis]

cb3rnard: Not necessarily a Sage-related issue. The workaround for this issue is using absolute URLs in the theme (as in block templates). Less than ideal, but it should work well on production.

[cb3rnard]

Yes, that's a s*** workaround... I can't really imagine using absolute urls, that would be a mess to synchronise between local, development and production environments.
Could a targeted redirection rule work within an iframe ? That way the base url could be extracted from the settings and a rewrite rule inserted in htaccess. The only url(...) are pointing to the theme public directory so the base uri is known.

[cb3rnard]

So, this issue has already been documented and shoud be fixed by #55152. I tried thinking about a fix using , but that's apparently not the best solution. Hope that will be validated and merged in the next release.