Gutenberg Compatibility?

[munirkamal]

Issue description:

I have got a theme built heavily with the kirki, I am looking to make it compatible with Gutenberg now. The first thing obviously is to render/enqueue all the styles generated via the customizer to the editor view. I was looking for the documentation and found this latest pull request got merged to be available with the next version 4.2 of Gutenberg.
WordPress/gutenberg#10956

Wondering if you @aristath is already working on something for Kirki to auto opt-in for this functionality? To make the life easier for the themes using kirki for the customizer? Any news?

Looking forward to your response.

TIA,
Munir

[mapsteps]

I'm looking for a way to add the Google Fonts generated by kirki to the block editor assets as well.

[munirkamal]

@mapsteps Yeah I am hoping that if kirki handles all the generated styles/CSS loaded and applied in the editor window that would be a lifesaver for all who uses kirki. @aristath what do you think?

[aristath]

I like the idea and I'd love to do it... I'm just a bit pressed on time this period so I can't make this a priority.
If someone wants to submit some code that will do this I'll probably merge it. If not, then anything you know about loading styles in Gutenberg etc will save us some time and make things easier for me when I do find some time to implement this.

[munirkamal]

@aristath

Thank you for the response, and good to hear that you will eventually do this. :)

I tried a little and was able to enqueue customizer generated css file to the editor simply by hooking it to the action "enqueue_block_editor_assets".

Now that loads the kirki generated CSS in the editor, however having two issues.

1) The Google Fonts do not load/work in the editor.
Not sure much about this and need help, how can we enqueue /load google font in the Gutenberg editor? I have a hint that it should be hooked to "enqueue_block_editor_assets" action, but how?

2) The enqueued CSS interfere/applies to WP admin and Gutenberg interface elements.

To resolve styling conflict we simply need to target editor specific selectors for the elements, now if that could be handled automatically by kirki that will make it awesome.

Here is the only theme support instructions available for Gutenberg officially.
https://wordpress.org/gutenberg/handbook/extensibility/theme-support/

Hope this helps?

Could you please provide a solution for loading google fonts meanwhile you work on this full compatibility?

TIA,
Munir

[timelsass]

@munirkamal

1. The Google Fonts do not load/work in the editor.

Could you please provide a solution for loading google fonts meanwhile you work on this full compatibility?

I added PR #2017 which does provide an example of how you can use the module async loader to ensure the webfonts are added. You can reference that code here:
781d6b7#diff-6fa3fb571951d8c352a6faa05a9dddddR241

2. The enqueued CSS interfere/applies to WP admin and Gutenberg interface elements.

Yes, that's correct, as you're adding a styles directly into the editor without using add_editor_style(), which undergo a transform to help theme styles avoid conflicts by namespacing. PR #2017 also addresses this issue and explains it a bit more in depth. Hopefully this resolves the issues you are having, and I would appreciate any testing/feedback you can do on the PR!

Here is the only theme support instructions available for Gutenberg officially.
https://wordpress.org/gutenberg/handbook/extensibility/theme-support/

Yeah, I wish this was all explained in documentation somewhere, because I also took the same path as you. Seems a bit ridiculous that setting the "standard way of creating content moving forward" means that developers are left with having to dive in deep to the code to get any useful things done. The documentation barely scratches the surface of what can be done/extended. There's also a lot of things that you can't do (well at least not very easily without reinventing the wheel) that are needed for more complex themes and plugins. Hopefully this will change soon.

For reference - WordPress/gutenberg#9008 was useful to get familiar with how add_editor_style support was being implemented.

[aristath]

I found a couple of free hours so I was able to take a look at this.
I added support for Gutenberg on #2018
BUT it won't just work for existing themes/fields etc.
The main concern I had was the fact that frontend styles should NOT be applied indiscriminately to the dashboard. Changing the body font-size for example will change it for the whole dashboard.
Gutenberg styles should be targeted and specific.

This is what we used to write:

'output' => array(
	array(
		'element'  => 'body',
		'property' => 'font-size',
	),
),

In Gutenberg the font-size for the main body would be in the .edit-post-visual-editor.editor-styles-wrapper element, so you'll have to add it separately:

'output' => array(
	array(
		'element'  => 'body',
		'property' => 'font-size',
	),
	array(
		'element'  => '.edit-post-visual-editor.editor-styles-wrapper',
		'property' => 'font-size',
		'context'  => array( 'editor' ),
	),
),

As you can see, there's a new context argument and it's an array.
If you want the styles to be added only on the dashboard, you'd write array( 'editor' ).
If you want the styles to be added both in the dashboard and the frontend, you'd write array( 'editor', 'front' ).
If the context argument is left empty then it defaults to array( 'front' ) and nothing gets added to the dashboard for that specific output.

This is now in the develop branch so feel free to test it and if you find any issues let me know.

I know that ideally we'd want to avoid writing the same output arguments again for the dashboard and in a perfect world we wouldn't have conflicts with the default dashboard styles.
This solution however is a lot more versatile. Not everything needs to be enqueued, usually we'll just want the typography options, some colors, site-widths etc.

[timelsass]

@aristath can you check out #2017? It leverages the automatic transformation/namespacing of CSS being imported to use in gutenberg so it won't impact the interface elements of the editor. This removes the need to specify editor specific styles for each control to just allowing themes to optin on a per config basis.

This is the documentation for adding editor styles for themes in order to support gutenberg: https://wordpress.org/gutenberg/handbook/extensibility/theme-support/#editor-styles

I think it's better to rely on the namespacing provided for styles in core as the wrapper or classes are prone to be changed as gutenberg grows. I could also see use cases where a custom editor may have a different wrap scheme, in which case the styles are no longer accurate.

I do like the context output option for allowing themes to conditionally add styles per control basis for the editor as needed, maybe a combination of these two things could be worked in? I know in a lot of theme testing I've done, it's been easier to use the solution in #2017 as everything is automatically handled for me for all styles I output without conflict. To do it via the context argument would introduce hours of extra work in fixing them all.

[munirkamal]

@timelsass That is exactly how I imagined it to work. Your solution seems great to me. And yes @aristath having a context output will be a nice option as well.

FYI, Gutenberg / WordPress release is now rescheduled to 27th Nov. So I am hoping this kirki Gutenberg compatibility if possible to be released earlier so the Themes using Kirki can be updated timely with the Gutenberg support.

This will definitely be a great update for Kirki framework.

Thank you for all your hard work on this opensource project @aristath

[aristath]

@timelsass that looks great to me... I just made a couple of minor changes to the PR (nothing major, just minor details) and merged it.

So now we have 2 ways to add Gutenberg support: automatic using 'gutenberg_support' => true in the config, or manual using the context argument in output fields.
I can't of anything better than that... developers will have a choice. 👍

[munirkamal]

@aristath That is amazing. I will give it a try with my theme and report any issues or suggestions. Thank you @timelsass for this.

[munirkamal]

@aristath

Just started testing the develop branch. I am getting this error.

 Parse error: syntax error, unexpected '::' in E:\xampp\htdocs\wordpress\prac1\wp-content\themes\start\inc\customizer\kirki\modules\gutenberg\class-kirki-modules-gutenberg.php on line 195

TIA

[aristath]

@munirkamal can you check now? I just pushed something that should fix this.
I'm assuming this is specific to your PHP version, thanks for checking!

[braginteractive]

@timelsass does the theme need to opt-in with add_theme_support('editor-styles'); for your automatic support to work?

[seothemes]

@braginteractive Only if output is disabled, otherwise Kirki adds it - https://github.com/aristath/kirki/blob/ec63944decfbf128ead44e7f8653779bbfcbf718/modules/gutenberg/class-kirki-modules-gutenberg.php#L146

[seothemes]

Can't seem to get this working. Keep getting this error:

Resource interpreted as Stylesheet but transferred with MIME type text/html: "https://site.test/?action=kirki-styles&ver=3.0.36".

Update: Adding the following fixes the above issue:

add_filter( 'kirki_output_inline_styles', '__return_false' );

However this loads all of the styles in the admin, and they are also being applied to elements outside of the editor.

Update: Adding the following workaround seems to work:

add_filter( 'kirki_gutenberg_' . $config_id . '_dynamic_css', function () {
	return file_get_contents( WP_CONTENT_DIR . '/uploads/kirki-css/styles.css' );
} );