Gutenberging

Gutenberg, the new editor for WordPress, has been released for more than a year. Now, the controversy surrounding it seems to have subsided. With plenty of time to improve its user experience and ease of use, people see its potential more clearly. We can't look back.

Authors like Haris Zulfiqar expressed optimism about it, while Nick Hamze believed blocks were the direction of the next-generation editor.

While I think it still has some shortcomings (e.g. why can't you add a list in a block reference? Why can't you add classes for a link? Why can't you browse the block selector with the arrow keys?), I generally like it very much. And it's not just conceptual likes. I listed CSS-Tricks migration to Gutenberg as one of my 2020 goals and started implementing it immediately in January.

Have tasted the sweetness for the first time

Since we have converted the press release creation experience to a new editor, we have accumulated some experience using Gutenberg. Our press release is a custom article type on CSS-Tricks, posted on public URLs, has a custom RSS feed, and is crawled and read by MailChimp.

We can easily enable Gutenberg for our press releases through the Gutenberg Ramp plugin. This works very well for custom post types and posts with a single id, but I want to enable Gutenberg only for new content . Finally I modified the plugin. If you think this is a good idea, check out my pull request.

This is important to me because we have tens of thousands of old articles created with old editors, and even though Gutenberg doesn't corrupt them when they are opened for editing, it doesn't offer an editing experience for these articles as well as a "classic" editor (for example, we have special buttons for special code blocks, etc.).

Handle old content

It would be great if Gutenberg could convert an old post into a suitable block when it opens, but it seems like a dream right now. This means it has to parse HTML, identify which blocks look like blocks, identify which block is the most appropriate, including our most important custom blocks, and do this accurately in a way that doesn't go wrong.

Currently, old content still uses the old editor. There is even an easy way to enable Gutenberg for a single article from the editor. (I could hardcode the values ​​into use of Gutenberg Ramp, but this is a bit tedious.)

I'm a little worried that the old editor will get worse. For example, one of the main reasons I started working on this is that on this site, the old editor will randomly scroll to the bottom of the page. I have no idea why, but it makes me feel very painful to create. It's just a trivial bug that makes me want to experience it with an editor that is actively developing.

But even if the old editors really get bad, enabling Gutenberg for everything isn't that bad. All old content will be in a large "classic" block and everything will be fine.

Anyway – it works well!

Enabling Gutenberg for a new article is a big challenge in itself, but we have enabled it and we are using it to create all new content. I'm just speaking on my own here, but I love it so much . It's a huge upgrade for content creation and I'm a little obsessed with it. The team is also very happy.

Create custom blocks

Check out our fancy text block:

You might be thinking, oh, cool, a chance to create custom blocks. In fact, we even introduced methods for learning and making Gutenberg blocks in a large series. But this raises a very relevant question: when not to build blocks . The only unique thing about this block is that it has a special class name that our CSS uses to style the block. That's all. Adding class names is a built-in feature for each block, so there is no need for custom blocks here.

In fact, we can go a step further and create a text block with this exact class as a "reusable block" so that we don't even have to remember or enter the class name. After I created a text block with this class, I selected "Convert to reusable block" from the kebab menu and now it will be permanently saved as a reusable block.

We have now used it for a few other things like our "Article Series" block (one with special ones)<div> -with-a-class wrapper<code><ul></ul> and<ol></ol> ) and footnote blocks and so on. But we do need some custom blocks too, for this I used create-guten-block to create a special plugin¹ to create them. I think one block that is very important to us is the code block. There is already a native block for code blocks. It basically puts the code in one

<code>标签中，并且来自Gutenberg的内容默认情况下已经转义。</code> Our fancy code blocks allow us to select its language, highlight certain lines, and provide custom tags. This is all possible in our old editor via HTML attributes, so this block just provides a nice UI on top of all of this.



<p>The block is very specific to CSS-Tricks, so it doesn't make much sense to open source it. But the other block I created is open source, that is, CodePen embed blocks. I've written about it on the CodePen blog.</p>



<p>It allows you to paste a CodePen URL, which will be converted to a CodePen embed. oEmbed already does this by default, but with this plugin you can control everything like height, theme and default tabs.</p>



<p>It's great to actually see embedded Pens while creating!</p>



<h3 id="Unsolved-Challenges">Unsolved Challenges</h3>



<p>The biggest challenge right now is processing images. In the old editor we integrated a very, very fancy Cloudinary setup. Images are automatically uploaded to Cloudinary, breakpoints are determined programmatically, multiple sizes are created, responsive image syntax is created, and ultimately in HTML is the perfect responsive image syntax with Cloudinary-hosted images. This allows us to take advantage of CDN and deliver images in the best format.</p>



<p>This does not happen in articles created with Gutenberg. ?</p>



<p>I need to find or develop a new system that handles images well anywhere on the website and ideally use a more easily maintained non-customized system. I might use Cloudinary to solve this problem, I might try other services, I might have WordPress handle it directly, powered by Jetpack Site Accelerator. Not sure yet. There is always something to do.</p>



<ol><li>I see WordPress itself also participates in the block scaffolding game. Their "create-wordpress-block" concept has entered the Gutenberg repository itself, and you can start it with `npm init @wordpress/block [options] [slug]`.</li></ol>

The above is the detailed content of Gutenberging. For more information, please follow other related articles on the PHP Chinese website!