The project

Epalle.co.il, my project in the last 2 years, has evolved quite much in the time of its existence (since 05/2022). from patches of code and plugins gathered without a thought to a coherent, logical repo of a functioning e-store (at the most part).

the time has come to start using gutenberg (i.e. the block editor), the website used, and still is, using storefront by Automattic, which is a great theme as a base and in general, and a storefront-child theme that i write and maintain.

storefront is a classic theme and the use of it of blocks and the block editor is accidentally at best, i dont want to talk shit anout it, because its good at its purpose, so lets just say that if you want to build pages, such as landing page, homepage or even product page, using the block editor – you need a different theme,

Gutenberg adventures

my adventure with creating epalle.co.il led me and the site to a place where a switch of theme would break a lot more than i can handle, and a problematic setup that would probably wont allow me to do it in staging and push to production. but, i need to make the use of gutenberg in order to enable a higher-form-of-wordpress to be constructed.

i need to setup the best block editor experience, and minimize the breaking changes while doing this. i started exploring my possibilities, i said to my self, just try to build what you want, a new design hoempage, and every time something is not working properly or broke, write it down as a task, then fix those issues and complet the tasks, easy, some would say peasy. i think it was about 5 minutes before i understood that my entire infrastructure to make that is not ready.

trying to find a needle hole to start using gutenberg and expand from there, i realized theme.json is the key config file to start from and expand onward, not an easy task.
first, i needed to learn theme.json and the entire surroundings of it. the "API", the functions that handle it, what wordpress is doing with it and more.

The issue

one stubburn issue i encountered while studying theme.json essentials and more, was that the block editor does not get the theme styles i registerd in theme.json. that issue led me to a wild-goose chase (what a strange phrase), of many hours debugging and following the WP_THEME_JSON class handling my humble json file.

i just couldnt figure out why the hell my colors and layout settings dont get outputed in the block editor page, but did in the frontend page, this was so frustraiting i wrote my first post on the wordpress support forum. i read again and again the scattered docs about theme.json, and couldnt find a thing.

after a mess of search, i stumbled upon a post in make wordpress core titled: On layout and content width in WordPress 5.8. and in this post there was a paragraph about containers block:

For themes with the layout config enabled, container blocks (like group blocks) do not automatically inherit the layout config. Meaning the blocks added inside the containers will by default take all the available space and not have any wide/full alignments options unless the user defines the wide and content sizes for that particular container block or “inherits” the config from the default layout.

which led me to look around in the code of the block editor and understand that there was a peculiar conflict invloving wordpress core gutenberg, storefront, my code and maybe some other code from around that made this issue as it was.
in short, the css custom properties holding the content and wide layout sizes wasnt enqueued in the block editor (but it did in the frontend).

Coding a solution

to solve this i wrote a code that take those values from theme.json and inline enqueue them in the block editor, i could have used hard coded numbers and change them whenever i change theme.json, but i wanted durability

add_action( 'enqueue_block_editor_assets', function () {
	$theme_json                                 = wp_json_file_decode( get_stylesheet_directory() . '/theme.json', [ 'associative' => true ] );
	$fix_block_editor_not_showing_layout_styles = '';
	if ( isset( $theme_json['settings']['layout'] ) ) {
		$content_size = $theme_json['settings']['layout']['contentSize'];
		$wide_size    = $theme_json['settings']['layout']['wideSize'];

		$fix_block_editor_not_showing_layout_styles .= 'body {';
		$fix_block_editor_not_showing_layout_styles .= '--wp--style--global--content-size: ' . $content_size . ';';
		$fix_block_editor_not_showing_layout_styles .= '--wp--style--global--wide-size: ' . $wide_size . ';';
		$fix_block_editor_not_showing_layout_styles .= '}';
	}
	if ( ! empty( $fix_block_editor_not_showing_layout_styles ) ) {
		wp_register_style( 'epalle_fix_block_editor_not_showing_layout_styles', false );
		wp_add_inline_style( 'epalle_fix_block_editor_not_showing_layout_styles', $fix_block_editor_not_showing_layout_styles );
		wp_enqueue_style( 'epalle_fix_block_editor_not_showing_layout_styles' );
	}

} );

thoughts about starting with gutenberg

gutenberg is hard for developers that want to start developing for it, in my opinion.
its a huge project with a lot of functionality and different ways to enter to its features, and really scattered documnetation spreading over from personal blogs writing about it, to several wordpress official handbooks ending up in specific groups or people helping and guiding individual developer with individual difficult scenarios, worth mentionin is the awesome Ryan Welcher which was tremendous help for me and still is.

one reason i am writing this post is to help with the gutenberg project, i know i said the docs are not optimal, and i want to help improving them, to help myself and others with wordpress development on the next level. it is also why this blog post is in english and not hebrew as the rest of the site.

hope you enjoy this post and i will appreciate comments about it.