What’s New In Gutenberg

A new toolkit

The beauty of the Gutenberg project is it is not just an editor, but a coding component system. What at first appears to be an infringement on ‘artistic license’ for developers is alternatively liberation from the TinyMCE editor and its trappings.

Gutenberg serves as a standardization for the WordPress software that is long overdue. The new editor provides a toolkit. This toolkit empowers the individual WordPress user by increasing recognition of common features in the WordPress interface, standardizing how content is added, and unlocking site layout from the theme files.

These changes move the project towards its goal of democratizing publishing.

It’s blocks all the way down

Atomic Blocks

A collection of beautiful, customizable Gutenberg blocks for the new block editor.


CoBlocks is powerful but lightweight: it adds functionality to the WordPress editor without bloat. This is the plugin you’ve been waiting for, and it will make you rethink what WordPress is capable of.

Kadence Blocks

This plugin adds custom blocks to extend Gutenberg’s editing capabilities to better build custom layouts and make Gutenberg able to do more closely what popular page builders can do. 

Design Library

We are creating a design library for Gutenberg that will include all the possible layout variations for your next WordPress project.

Our plugin uses default Gutenberg block only. It will not pollute your WordPress installation with extra blocks or any custom code.

ACF Blocks

Manually creating custom blocks means digging through endless mounds of JavaScript. ACF Blocks, on the other hand, does all the hard work for you so you can sit back, relax and continue writing simple PHP and HTML.

WooCommerce Blocks

Designed to work with the new Blocks Editor introduced with WordPress 5.0, WooCommerce Blocks allow you to select and display products across your site

Jetpack Blocks

The WordPress Block Editor transforms your way of writing from a single document to a collection of meaningful elements (blocks), with explicit structure. Jetpack includes some blocks of its own, which can help you create your pages exactly the way you want them.

2019 Roadmap

Matt Mullenweg announced during the State of the Word that the focus for the Gutenberg project would revolve around nine projects this year. Let’s take a look:


Creating a block for navigation menus. #


Porting all existing widgets to blocks. #


Upgrading the widgets-editing areas in wp-admin/widgets.php and the Customizer to support blocks.


Providing a way for themes to visually register content areas, and exposing that in Gutenberg.


Merging the site health check plugin into Core, to assist with debugging and encouraging good software hygiene.


Providing a way for users to opt-in to automatic plugin and theme updates.


Providing a way for users to opt-in to automatic updates of major Core releases.


Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them.


Forming a Triage team to tackle our 6,500 open issues on Trac.

Where we are now

In ProgessComplete
Block in NavX
Widgets as BlocksX
Blocks in CustomizerX
Theme block regist.X
Site Health CheckX
Auto Theme UpdateX
Auto Core UpdateX
Block LibraryX

About 33% of the way there with about nine months to go.

Growing pains

With the rollout of the new editor, a couple issues were unearthed (if not predicted).


Many theme developers chose not to provide compatibility with the new editor, simply chosing to allow the theme to gracelessly fall into obscurity.


Compatibility for plugins depended on whether the plugin interacted with the editor. Popular plugins like ACF built out support for the new editor before its launch. The push for an increase in the minimum version of PHP is likely a bigger blocker for older plugins than the new editor.

Upgrading an old layout to the new editor

A couple things to keep in mind when moving to the new editor.

Do you use a site builder that uses shortcodes?

Many page builders are working on support for the new block editor. But some are still a bit defiant of having their niche taken away by core.

For instance, the Gridable plugin built into Pixelgrade themes does not work with the new editor and must be disabled if you choose to use the block editor.

Can your content be created as blocks?

In a recent project, I had to replace a grid plugin that wasn’t compatible with Gutenberg. My solution was to use a columns block by Kadence. I figured this block would have a bit more longevity than a bespoke grid plugin, as it is built for the new editor.

Same look, new parts.

The process was relatively painless, with a little bit of a learning curve. I created two columns, placed an image in one and a couple paragraph, list, headings, and button blocks in the other.

The list section is simply a nested two column layout within the parent column.

I made sure to give the parent column a CSS selector under the block editor’s Advanced tab, ensuring that I could easily style the block group later on.

The styles

/*** Venue Page ***/
.venue-panel-right, .venue-panel-left {
	margin: 3em 0;
.is-style-squared .wp-block-button__link {
	color: white;
/*** Venue Panels ***/
.venue-panel-right h4:after, .venue-panel-left h4:after {
	padding-bottom: 1.25em;
@media (min-width: 600px) {
	.venue-panel-right>.has-medium-gutter>[class*="wp-block-coblocks-"]:not(:last-child) {
		background-color: white;
		padding: 3em;
	.venue-panel-left>.has-medium-gutter>[class*="wp-block-coblocks-"]:not(:first-child) {
		background-color: white;
		padding: 3em;
.page-id-2058 .u-content-background {
	background-color: #EEF1F2;
.venue-image-left img, .venue-image-right img {
	height: 100%;
	width: 100%;
	min-height: 800px;
	max-height: 700px;
	object-fit: cover;

Are you using shortcodes in some capacity?

Shortcodes ought to be compatible with the new editor, but I have run into instances where many shortcodes may end up being wrapped incorrectly, resulting in a broken layout.

What plugin functionality can be replaced by the block editor?

Many TinyMCE plugins will not work with the block editor, or, will only be available in the Classic Block.

Are you using a column’s plugin? A grid plugin? Can these be replaced by the built in column block? Can you duplicate this functionality with a block plugin like Kadence blocks?

You may find that an incompatible plugin is essential to your site and doesn’t currently have a block editor counterpart. This may be a good enough reason to hold off.

Use a staging branch

Whether you test the changes on your local machine or use a staging service (often provided by your host at extra cost), you should make all of your compatibility testing from a non-production copy of your site.

Once you’re sure the new editor is for you, make a backup of your live site, make a second backup, then push the new changes to your live site.






A Twentyninteen Rebrand

As I began the new year, I decided it was finally time to dust off my FTP client and rethink my website.

Past iterations of my site were mostly just tinkering and devoid of any real substance. Yes, lessons were learned, but some things just need to be burnt to the ground and built from a new foundation.

Introducing….Twentynineteen – erm – child theme edition.

my homepage

Now, I’m no designer, but this is a pretty clean page. This didn’t take me too long to put together and mostly involved the following:

Not bad! Let’s look a little closer. I’ve divided the homepage into three sections.

homepage outlined

Section one

The top section is rather straight forward. I simply added my initials as the Site Title, my full name as the Site Description and then set the site description as its own block with some CSS:

    display: block; /* Sets the description on its own line */
    padding-left: .25em; /* Just to line up the left edge nicely */

All of which was done directly from the WordPress customizer. Nice.

I also hid the site navigation in favor of embedded links in the body of the site.

Section two

The content section uses the new Gutenberg editor along with a few custom blocks by Kadence Themes.

kadence blocks

What’s great about Gutenberg is that all sorts of block libraries are being developed. The benefit of a Javascript framework is that it creates a foundation that WordPress features can build off of, using one unified component system.

Another awesome benefit of the new Javascript framework is that is can be used outside of WordPress. The Drupal community adopted the Gutenberg editor for their open source project, and blocks built for Drupal can be used in WordPress!

Mixing and matching block libraries is simple and since blocks share a common component system and structure, every block should work seamlessly together.

Kadence has taken the rather lackluster columns block and extrapolated on it, providing rich UI controls and prebuilt column templates.

kadence in action
Pretty cool.

I used an H2 header for the quote, because I like how it stood out, though a quote block would likely be a bit more semantic with a bit of styling.

I then used a Kadence row block to create the fifty-fifty column layout.

Kadence does provide a few prebuilt layouts, which is a really nice feature. This cut my development time down quite a bit since it took some of the guess work out.

Section three

One of the options found in the Kadence row block is the divider setting. This option lets you embed a fancy svg image or bezier curve.


At first, I used one of the dividers because I liked how it looked like a mountain range. But as I tinkered with this, I realized that I would essentially need to leave an empty row at the bottom of every page in order to have these mountains appear in the footer consistently.

This is not a very elegant solution, especially since Gutenberg doesn’t support global blocks yet. This can be overcame with reusable blocks, but that still requires you to manually enter them.

The best solution (for now) was to modify the footer.php template file and embed the SVG into the template itself.

Removing layout from the editor and sticking it in the template files sort of defeats the purpose of Gutenberg. Granted, as more core elements of WordPress are brought into the Gutenberg framework, we should see less and less of this.

The first step is to go into the page editor and select the Code Editor from the editor settings in the upper right corner (beside Publish).

Next, copy the separator code, along with its SVG and path elements.

Make sure to select the correct wrapper div.

Now, using a child theme, you can paste the separator code just above the footer section.

Adding the SVG code

This effectively moves the separator out of the content body and into the footer, letting you display the SVG on every page.

The last bit is to modify the SVG’s CSS so that the section is relatively positioned, this allows you to set the SVG to the bottom edge of the content section, just along the top of the footer.

/* Footer Separator */
.kt-row-layout-bottom-sep {
    position: relative;
    height: 250px; /* Adjust the height of the SVG for more stoic mountains */

A note on widgets

Twentynineteen lets you add widgets to the footer, but doesn’t offer a sidebar widget area. In my case, this is alright.

In this particular build, I chose to add the Jetpack subscription widget to my footer, which only required a little bit of CSS tweaking to have it sit where I wanted.


I really liked building out this homepage with Gutenberg, especially when I started to add in custom block libraries. As the editor evolves over time, I believe it will serve as a robust alternative to TinyMCE.

Plenty of WordPress users ask, “why not just use one of the standard page builders like Divi or Elementor.”

That is an option. But Gutenberg aims to solve a more pernicious issue — developers designing user experience. Developers and designers are separate disciplines, usually for a good reason. Not to mention, every page builder is built in a unique and different way. This can be nice, since it gives you many options, but then you run into having too many options.

With Gutenberg, a component system is implemented that says “do this, don’t do that.” The importance of this is that it can create synergy across rich media features on the WordPress platform, something that was never possible before.

I found I wasn’t a huge fan of the large Twentynineteen headers, they just weren’t for me. But the beauty of WordPress is I could just simply remove them.

As I work with more and more websites, I am increasingly looking to cut out bloat and feature creep wherever possible. This approach creates a couple benefits:

  • Decreased page load times
  • Cleaner typography driven design
  • Better accessibility across devices and browsers
  • Less development overhead

I hope this overview inspires you to get under the hood of this year’s latest core theme and create something really special for your own blog.

Working with Pixelgrade and Gutenberg

I work everyday with users on WordPress.com. Implementing Gutenberg into such a large project is vastly different than implementing it alongside an individual website.

When working on personal projects, any issue can become a major issue pretty easily. I can see why some of the community isn’t too thrilled with the changeover.

I know that a lot of the angst over Gutenberg involved implementing the new editor into older themes and existing content. What would break? Will plugins or custom post types be supported?

I admit, I rolled my eyes at first. The new editor does have a lot going for it, such as a standardization of rich content, but could it really be that difficult to shim an older theme into the new editor?

The Project

Back in 2017, just before I began working for Automattic, I worked for my parent’s catering company. I wore many hats, from bartender to marketer, and even sought to redesign our WordPress website.

The project seemed simple enough:

  • Pick a quality theme geared for restaurants and food service
  • Pull over our content and format it for the new layout
  • Redirect domain and old permalinks to the new site

And it was! It took me a good amount of time over the course of a month or two to put together the material and make it into something great.

I chose to go with the theme Osteria by Pixelgrade, as I knew they built pretty great themes for WordPress.com.

Pretty spiffy.

Osteria uses a couple of custom plugins built by Pixelgrade for their themes. These plugins consisted of:

  • Customify – A Theme Customizer Booster
  • PixCodes – WordPress shortcodes plugin everywhere. Loaded with shortcodes, awesomeness and more.
  • Pixelgrade Care – We care about giving you the best experience with your Pixelgrade theme.
  • PixTypes – Custom post types and meta-boxes needed by your themes.

And of course, one plugin I learned to loathe:

  • Gridable – A simple and intuitive tool for organizing your content into columns and rows.

To be perfectly honest, a lot of these plugins provided great value.

Customify made the customizer experience wonderful and feature rich.

Pixelgrade Care is a great solution to manage your theme subscription and also provides a list of changes you can make on the theme.

PixTypes provided some interesting meta box options that let you customize the themes parallax headers to your liking.

But two plugins stood out as not particularly…good.

PixCodes is indeed feature rich, providing lots of great icons and the like, but in my mind the byline ‘Loaded with shortcodes, awesomeness and more’ puts a major exclamation point on the reason why Gutenberg was devised in the first place.

Gridable, well, is simply not good at all. I found it constantly buggy and very unintuitive.

But all of that being said, I do really like Osteria a lot! I think the style and emotion of the theme is spot on, and it wasn’t bulky or cumbersome to use.

Enter Gutenberg

As 2018 flew by, the site was delayed and yet to launch. I was eager to see what Pixelgrade would do with the new block editor, and thought “wow, all of these cool layouts in Osteria would work great as gutenblocks.”

But then as the launch of WordPress 5.0 approached, I came across this:

In terms of theme compatibility, our portfolio is split in two:
themes that used the regular editing experience without any custom fields; these themes have already been updated to be compatible with the Gutenberg editor and the transition should be painless.The themes in this category are Patch, Hive, Gema, Noto, Vasco, Julia, Felt, Jason, and Silk.

Hmm. Not a great start.

Themes that use custom editing experiences with multiple custom fields and meta boxes; these themes will be much harder to be made compatible and we will tackle them to the best of our abilities; some of them have such a custom workflow that the best option for them is to stick with the classic editor as too many things might break when switching.The themes in this category are Rosa, Osteria, Listable, Fargo, Noah, Timber, Mies, Pile, Heap, Border, Lens, and Bucket.

Crap. One downside to the fast rollout of the new editor is that a lot of studios simply did not have the resources nor time to make all of their themes compatible.

So I was faced with a decision, scrap Osteria or Gutenify it. I chose the latter.

Into the code…

The first thing I needed to take a look at was how would I remove Gridable. By disabling Gridable, I essentially would lose all of the layout on my Homepage, Events, Venues, and Proposals pages, basically four out of five main pages on the site.

But the good news was that this plugin was not required to layout the theme. I broke the new project into three steps:

  1. Find a block plugin to extend the default ‘columns block’.
  2. Replicate the column and row layout laid out by Gridable.
  3. Create new CSS classes and pull in theme styling to recreate the look of the old layout

I will admit, there was a fair amount of work to make this conversion, but as I got further into the project things began to feel good.

Ideally, using the core editor to generate content should help with the performance of the site. Less plugins, less resource demand. Also, Gutenberg does create pretty decent frontend code.

Taking this approach futureproofed my site.

Step One – A new plugin

Gridable was decidely not very useful. After working with Kadence Blocks on my new blog rebrand, I decided to try out CoBlocks to see how they compared.

CoBlocks is developed by Rich Tabor, and is a very intuitive block library. Many developers are creating ‘block suites’ that offer a lot of block functionality right out of the box.

For now, I’ve mostly stuck to the row block, as it provides a much more interactive column layout than the default column block.

Using CoBlocks I was able to replicate, and in most instances surpass, the functionality of Gridable without much trouble. I especially like that I can add CSS classes to every block right from the block sidebar.

Lastly, I found reusable blocks incredibly useful, as you’ll see below.

Venue Layout

One of the nicest layouts is in Osteria is the Functions section, which I used to show off the list of venues we frequent. This required creating two different reusable blocks: Venue Panel Left and Venue Panel Right

Top – Venue Panel Right | Bottom – Venue Panel Left

As you can see, the blue lines denote the CoBlocks rows and columns. I assigned the row a class, such as ‘venue-panel-right’ under Advanced, then assigned the image its own class for further CSS styling.

Once I had the two panel alignments fleshed out in blocks, I simply clicked on the row block and saved it as a reusable block.

Now I can reuse this layout for a limitless number of changing venue halls – great!

More to come….