Usually, for Gutenberg styles the normal frontend styles are added as editor styles..editor-styles-wrapper class selector.
Issue (with workaround/fix) for using the styles in Sage:
opened 07:32PM - 20 Dec 19 UTC
bug
9.x
* [x] I've read the [guidelines for Contributing to Roots Projects](https://gith… ub.com/roots/.github/blob/master/CONTRIBUTING.md)
* [x] This request isn't a duplicate of an existing issue
* [x] I've read the [docs](https://roots.io/documentation/) and followed them (if applicable)
* [x] This is not a personal support request that should be posted on the [Roots Discourse](https://discourse.roots.io/) community
## Description
Sage uses a filter hook that strips the filename from result of `add_editor_style(...)` (https://github.com/roots/sage/blob/fd2a94fa1b8fa5b4767b5f0f825ec364564d0efa/resources/functions.php#L82).
The global `$editor_styles` is used with `get_theme_file_path(...)` in the Gutenberg editor (`edit-form-blocks.php`). `get_theme_file_path(...)` searches for files in stylehsheet directory ('./resources' for sage9 theme), it doesn't work with an URL, like `asset_path(...)` returns.
```php
add_editor_style(asset_path('styles/main.css'));
````
will not work with Gutenberg editor.
But also passing the relative path `../dist/styles/main.css` instead of the URL `asset_path(...)` returns, doesn't work because that filter hook in sage will strip the file name `main.css` from it and the `is_file` check fails.
## Steps to reproduce
1. `add_editor_style( asset_path('styles/main.css') );` is already used in `setup.php`
2. Open Gutenberg editor, notice that the main.css styles are not loaded there
3. Debug `asset_path('styles/main.css')` result, notce that it returns an URL.
4. Debug `get_theme_file_path(...)` with what `asset_path('styles/main.css')` returns, notice that it doesn't work with URIs.
5. Debug `get_theme_file_path(...)` with a path relative to sage9 theme root (`./resources`), notice that the filename from result is missing.
**Expected behavior:**
That the example with `add_editor_style` also works with Gutenberg.
That the filter hook doesn't interfere with `get_theme_file_path(...)`.
**Actual behavior:**
Doesn't work with Gutenberg editor.
Inteferes with `get_theme_file_path(...)`.
## Versions
9.0.9
Sage 10 followed a different approach (in alpha) some commits ago where the editor.scss was enqueued as the only styles (as editor styles) and wrapped the frontend styles itself.
I still enqueue additional editor styles with editor-specific adjustments to the Gutenberg editor - the frontend DOM is usually much leaner and sometimes differs too much to the backend DOM where extra UI elements are added (e.g. extra wrappers, control handles, toolbars, etc.).
On the other hand I want to have the editor-specific styles at the same place where the usual frontend styles are - but the editor specific styles should be extracted, see this issue/feature request:
opened 04:30PM - 23 Nov 21 UTC
build
enhancement
* [x] I've read the [guidelines for Contributing to Roots Projects](https://gith… ub.com/roots/.github/blob/master/CONTRIBUTING.md)
* [x] This request isn't a duplicate of an existing request
* [x] This is not a personal support request that should be posted on the [Roots Discourse](https://discourse.roots.io/) community
## Summary
Frontend and editor/backend styles are often very close together for Gutenberg blocks. The ability to have these styles close together and extract the editor-specific styles into a separate editor stylesheet can be a huge productivity improvement.
## Motivation
Sometimes additional editor styles have to be added to the normal frontend styles, as the editor DOM and default styles occasionally differ.
It would be nice to have these styles all at one place. Print media queries can be already nicely nested into the existing styles and SASS will correctly extract them into one outer media query.
Now I want something similar with the editor styles.
```scss
.wp-block-group {
// frontend styles
@editor { // or some other selector
// editor-specific styles + nested selectors, etc
}
}
````
Now the styles for `@editor` should be extracted into the separate editor stylesheet.
## Additional context
`laravel-mix` already does this for `react` and `vue` styles, using [`css/mini-extract`](https://webpack.js.org/plugins/mini-css-extract-plugin/).
Lastly there can be some issues with Gutenberg FSE template loading:
roots:main ← strarsis:patch-1
opened 10:49AM - 20 Nov 21 UTC
@retlehs: Instead of solely returning the blade template path locate result,
a… ppend it to the array of existing files passed to the template hierarchy filter handler,
allowing Gutenberg Full Site Editing (FSE) to find and use block templates/template parts in the (Sage 10) theme.
This fix lets the Gutenberg Full Site Editing/FSE templates load in Gutenberg,
while still allowing classic (blade) templates to be used (as for WooCommerce that currently doesn't fully use Gutenberg yet).
### Useful resources
- Workaround that short-circuits the filter instead (as a fix in a Sage 10 theme): https://github.com/roots/sage/issues/2828#issuecomment-959872916
- Discussion about the reasons on why Gutenberg Full Site Editing/FSE can't find block templates/template parts without the fix:
https://discourse.roots.io/t/full-site-editing-fse-frontend-doesnt-load-template/21574/4?u=strarsis
- Related issue in the Sage 10 repository (that uses this `acorn` library in its PHP runtime): https://github.com/roots/sage/issues/2828#issuecomment-959872916
The behavior changed with different WordPress core and Gutenberg plugin releases.
Here is a Sage 10 FSE branch I started, it is not perfect though, there are still issues, newer Gutenberg releases also have subtle problems:
2 Likes