It’s been over a year since the big WordPress launch of Gutenberg, the new editor. It seems to me most of the controversy around it has died down. There has been enough time that the UX and accessibility of it have improved, and people are seeing the potential a lot more clearly. There ain’t no turning back.

I’m running across articles like Haris Zulfiqar saying he’s betting on it and Nick Hamze saying that blocks are for the next generation.

While I think there are still rough edges (like why can’t I put a list in a blockquote? Why can’t I add a class to a link? Why can’t I arrow-key through the block chooser?), I’m a big fan overall. And not just conceptually anymore. I made it one of my 2020 goals to get CSS-Tricks onto Gutenberg, and so I hopped to that right away in January.

We already had one foot in the door

We had a smidge of experience Gutenberging since we had already converted the newsletter authoring experience over to the new editor. Our newsletters are a Custom Post Type here on CSS-Tricks, which are published here at public URLs, have a custom RSS feed, and sent out by MailChimp which fetches and reads that RSS feed.

We were able to just turn on Gutenberg for newsletters by way of the Gutenberg Ramp plugin. That works great for Custom Post Types and posts with individual IDs, but I wanted to turn on Gutenberg only for new content. I wound up monkey-patching the plugin. Here’s a pull request in case anyone over there thinks it’s a good idea.

This was important to me, as we have tens of thousands of old posts created with the old editor, and even though Gutenberg doesn’t mangle them if we open them up for editing, the editor experience it provides for them isn’t as good as the “classic” editor (e.g. we have special buttons for our special code blocks and stuff like that).

Dealing with older content

What would really be great is if Gutenberg would convert old posts into proper blocks upon opening, but that feels like a dream at this point. Like, it would have to parse the HTML, identify what chunks look like blocks, identify which block makes the most sense, including our custom blocks which are the most important, and be really correct about it in a non-fragile way.

For now, old content just uses the old editor. There isn’t even an easy way to flip on Gutenberg for an individual post from the editor. (I could hard-code values into the Gutenberg Ramp usage, but that’s a bit tedious.)

I worry a smidge that the old editor will really deteriorate. For example, one of the big reasons I got started with this is because, on this site, the old editor would just randomly scroll to the bottom of the page. I can’t for the life of me figure out why, but it makes authoring obnoxious for me. Just a little papercut bug that made me want to get on the editor experience that is being actively developed.

But even if the old editor really gets bad, just flipping on Gutenberg for everything isn’t that bad. All the old content will just be in a big “classic” block and will be fine.

So anyway — it’s working!

Turning on Gutenberg for new posts was its own little challenge, but it’s turned on for us and we’re creating all new content in it. I’m just speaking for myself here but OMG I love it so much. It’s such a massive upgrade for writing content that I’m a little obsessed with it. The team is happy as well.

Creating custom blocks

Check out this fancy text block we have:

You might think, oh cool, an opportunity for a custom block. Heck, we even covered learning and making Gutenberg blocks in a whole big series. But this brings up a pretty relevant situation: when not to build a block. The only thing unique about this block is that is has a special class name that our CSS uses to style that block. That’s it. Adding a class name is a built-in feature of every block, so a custom block here really isn’t necessary.

In fact, we can go a step further, and make a text block with this exact class a “reusable block” so we don’t even have to remember or type in that class name. After I’ve created a text block with this class, I select “Convert to Reusable Block” from the kebab menu and now it’s forever saved as a reusable block.

We’re already using it for a few other things now, like our “Article Series” block (an <h4> and <ol> with a special <div>-with-a-class wrapper) and footnote blocks and such.

But we do actually need some custom blocks as well, and for that I used create-guten-block to craft a special plugin¹ to create them. I see One that is mega important for us is code blocks. There is already a native block for code blocks. It essentially puts the code in a <pre> tag and the content from Gutenberg is already escaped by default.

Our fancy code block allows us to pick which language it is, highlight certain lines, and provide custom labels. This was all possible in our old editor via HTML attributes, so this block is just nice UI on top of all that.

That block is so specific to CSS-Tricks it doesn’t make much sense to open source it. But there is another block I created that is open source, and that’s the CodePen Embed Block. I wrote about it over on the CodePen blog.

It allows you to paste in a CodePen URL and it transforms into a CodePen Embed. oEmbed already does that by default, but with this plugin, you can control everything like the height, theme, and default tabs.

It’s pretty awesome to actually see the embedded Pens while authoring!

Unfaced challenges

The biggest challenge right now is handling images. In the old editor, we have integrated a very very fancy setup with Cloudinary. The images are automatically uploaded to Cloudinary, breakpoints are programmatically decided on, multiple sizes are created, a responsive images syntax is created, and what ends up in the HTML is a perfect responsive images syntax with the images hosted by Cloudinary. This has the provided us with the benefit of being on a CDN and serving the images in the best possible format as well.

None of that is happening on posts created with Gutenberg. 😭

I need to find or develop a new system that does a great job with images everywhere on the site and ideally with a less bespoke system that is easier to maintain. It’s possible I figure that out with Cloudinary, I might try some other service, I might let WordPress deal with it directly backed by the Jetpack Site Accelerator. Not sure yet. Always something to do.