Getting more out of Gutenberg without going FSE

written by: Jeff McNear

Full site editing is an exciting prospect which holds open the promise of template configuration without code and an editing interface that puts all components in one place rather than the traditional abstraction related to widgets, menus and the customizer. Most existing sites aren’t ready to go 100% block based anytime soon, nor should their site owners feel compelled to do so. WordPress has a backwards compatibility premise this will remain true as the Gutenberg project continues to advance.

Here are several functions to consider adding to your “classic” themes that will help you take better advantage of Gutenberg functionality without taking the full FSE plunge:

Allowing the theme to display the “opinionated” block styling on the front end – while each block does have its’ own inherent styling – without this function a classic theme would show less CSS “styling” definition

add_theme_support( 'wp-block-styles' );

By default the line-height controls for typography elements is disabled, this will enable it

add_theme_support( 'custom-line-height' ); 

Embed codes have responsive behaviors, bu they need to be turned on by using this function

add_theme_support( 'responsive-embeds' ); 

This function will add a padding control to the appropriate blocks

add_theme_support( 'custom-spacing' );

Gutenberg has an image option that exceeds the boundaries of the container, but it needs to be allowed – note: you will probably need to write some additional CSS to make this work

add_theme_support( 'align-wide' ); 

This additional step needs to be taken in order for the theme’s editor’s styles to show in Gutenberg

add_theme_support( 'editor-styles' );
add_editor_style( 'assets/css/editor-style.css' ); // path the editor's stylesheet

Setting a custom color pallette

add_theme_support( 'editor-color-palette', array(
		'name'  => __( 'LogoGreen', 'preservation' ),
		'slug'  => 'preservation-logogreen',
		'color'	=> '#67b346',
		'name'  => __( 'Khaki', 'preservation' ),
		'slug'  => 'preservation-khaki',
		'color' => '#bfbc54',
		'name'  => __( 'Turquoise', 'preservation' ),
		'slug'  => 'preservation-turquoise',
		'color' => '#71a5bf',
		'name'  => __( 'Blue','preservation' ),
		'slug'  => 'preservation-blue',
		'color' => '#0000ff',
		'name'  => __( 'Light Purple','preservation' ),
		'slug'  => 'preservation-lightpurple',
		'color' => '#8b67bf',
		'name'  => __( 'Dark Purple','preservation' ),
		'slug'  => 'preservation-darkpurple',
		'color' => '#574473',
	) );

add_action( 'after_setup_theme', 'ea_setup' );

for the colors to work, they need to be included in your stylesheet like this:

.has-preservation-logogreen-color { color: #67b346; }
.has-preservation-logogreen-background-color { background-color: #67b346; }

.has-preservation-khaki-color { color: #bfbc54; }
.has-preservation-khaki-background-color { background-color: #bfbc54; }

.has-preservation-turquoise-color { color: #71a5bf; }
.has-preservation-turquoise-background-color { background-color: #71a5bf; }

.has-preservation-blue-color { color: #0000ff; }
.has-preservation-blue-background-color { background-color: #0000ff; }

.has-preservation-darkpurple-color { color: #574473; }
.has-preservation-darkpurple-background-color { background-color: #574473; }

.has-preservation-lightpurple-blue-color { color: #8b67bf; }
.has-preservation-lightpurple-background-color { background-color: #8b67bf; }

Setting a custom gradient palette I found a bit trickier since I couldn’t get the CSS to work as it did for the colors – but there is a workaround. First the function:

                	'name'     => esc_attr__( 'Vivid cyan blue to vivid purple', 'preservation' ),
          	'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'vivid-cyan-blue-to-vivid-purple'
         	'name'     => esc_attr__( 'Khaki to blue', 'preservation' ),
          	'gradient' => 'linear-gradient(135deg,rgba(191,188,84,1) 0%,rgb(0,0,255) 100%)',
            'slug'     => 'midnight'

            'name'     => esc_attr__( 'Vivid green cyan to vivid cyan blue', 'preservation' ),
            'gradient' => 'linear-gradient(135deg,rgba(0,208,132,1) 0%,rgba(6,147,227,1) 100%)',
            'slug'     =>  'vivid-green-cyan-to-vivid-cyan-blue',
            'name'     => esc_attr__( 'Light green cyan to vivid green cyan', 'preservation' ),
            'gradient' => 'linear-gradient(135deg,rgb(122,220,180) 0%,rgb(0,208,130) 100%)',
            'slug'     => 'light-green-cyan-to-vivid-green-cyan',
            'name'     => esc_attr__( 'Luminous vivid amber to luminous vivid orange', 'preservation' ),
            'gradient' => 'linear-gradient(135deg,rgba(252,185,0,1) 0%,rgba(255,105,0,1) 100%)',
            'slug'     => 'luminous-vivid-amber-to-luminous-vivid-orange',
            'name'     => esc_attr__( 'Luminous vivid orange to vivid red', 'preservation' ),
            'gradient' => 'linear-gradient(135deg,rgba(255,105,0,1) 0%,rgb(207,46,46) 100%)',
            'slug'     => 'luminous-vivid-orange-to-vivid-red',

Gutenberg attaches a class to an element with a gradient background like this:


But when I went to define it in the stylesheet the definition wouldn’t take on either the front-end or in the editor display. However it appears the Gutenberg itself recognizes a group of terms that include (as taken from the default examples):

  • cool-to-warm-spectrum
  • blush-light-purple
  • blush-bordeaux
  • luminous-dusk
  • pale-ocean
  • electric-grass
  • midnight
  • vivid-cyan-blue-to-vivid-purple
  • vivid-green-cyan-to-vivid-cyan-blue
  • light-green-cyan-to-vivid-green-cyan
  • luminous-vivid-amber-to-luminous-vivid-orange
  • luminous-vivid-orange-to-vivid-red

When a custom gradient is defined in a theme.json file in a FSE theme there doesn’t seem to be a problem with unique slug names – but my experience is that when adding a custom gradient via PHP requires “highjacking” one of these pre-defined slug names will do the trick