gutenberging

Gutenberg，WordPress的新编辑器，发布已逾一年。如今，围绕它的争议似乎已平息。充足的时间让其用户体验和易用性得到提升，人们也更清晰地看到了它的潜力。我们无法回头。

像Haris Zulfiqar这样的作者表示看好它，而Nick Hamze则认为区块是下一代编辑器的方向。

虽然我认为它仍然存在一些不足（例如，为什么不能在块引用中添加列表？为什么不能为链接添加类？为什么不能用方向键浏览块选择器？），但我总体上非常喜欢它。而且不仅仅是概念上的喜欢。我将CSS-Tricks迁移到Gutenberg列为2020年的目标之一，并在1月份立即着手实施。

已初尝甜头

由于我们已将新闻稿创作体验转换为新编辑器，因此我们已经积累了一些Gutenberg的使用经验。我们的新闻稿是CSS-Tricks上的自定义文章类型，发布在公共URL上，拥有自定义RSS feed，并由MailChimp抓取和读取该RSS feed。

我们可以通过Gutenberg Ramp插件轻松为新闻稿启用Gutenberg。这对于自定义文章类型和具有单个ID的文章非常有效，但我希望仅为新内容启用Gutenberg。最终我修改了该插件。如果您认为这是一个好主意，可以查看我的pull request。

这对我来说很重要，因为我们有数万篇使用旧编辑器创建的旧文章，即使Gutenberg不会在打开它们进行编辑时损坏它们，但它为这些文章提供的编辑体验也不如“经典”编辑器（例如，我们有用于特殊代码块等的特殊按钮）。

处理旧内容

如果Gutenberg能够在打开旧文章时将其转换为合适的区块，那就太好了，但这目前看来像是一个梦想。这意味着它必须解析HTML，识别哪些块看起来像区块，识别哪个区块最合适，包括我们最重要的自定义区块，并且以一种不会出错的方式准确地做到这一点。

目前，旧内容仍然使用旧编辑器。甚至没有一种简单的方法可以从编辑器中为单个文章启用Gutenberg。（我可以将值硬编码到Gutenberg Ramp的使用中，但这有点繁琐。）

我有点担心旧编辑器会严重恶化。例如，我开始着手这项工作的一个主要原因是，在这个网站上，旧编辑器会随机滚动到页面底部。我完全不明白为什么，但这让我觉得创作非常痛苦。只是一个微不足道的小bug，却让我想要使用正在积极开发的编辑器体验。

但即使旧编辑器真的变得很糟糕，为所有内容启用Gutenberg也不是那么糟糕。所有旧内容都将位于一个大型“经典”块中，一切都会正常。

总之——它运行良好！

为新文章启用Gutenberg本身就是一个不小的挑战，但我们已经启用它了，并且我们正在使用它创建所有新内容。我在这里只是代表我自己发言，但我太喜欢它了。它对内容创作来说是一个巨大的升级，我有点痴迷于它。团队也很高兴。

创建自定义块

看看我们这个花哨的文本块：

你可能会想，哦，酷，一个创建自定义块的机会。事实上，我们甚至在一个大型系列中介绍了学习和制作Gutenberg块的方法。但这提出了一个非常相关的问题：何时不构建块。这个块唯一独特之处在于它有一个特殊的类名，我们的CSS使用它来为该块设置样式。仅此而已。添加类名是每个块的内置功能，因此这里不需要自定义块。

事实上，我们可以更进一步，创建一个具有此确切类的文本块作为“可重复使用的块”，这样我们甚至不必记住或输入该类名。在我创建了一个具有此类的文本块后，我从kebab菜单中选择“转换为可重复使用的块”，现在它将永久保存为可重复使用的块。

我们现在已经将其用于其他一些事情，例如我们的“文章系列”块（一个带有特殊<div>-with-a-class包装器的<code><ul></ul>和<ol></ol>）和脚注块等等。但我们确实也需要一些自定义块，为此我使用了create-guten-block来创建一个特殊的插件¹来创建它们。我认为对我们来说非常重要的一个块是代码块。已经有一个用于代码块的原生块。它基本上将代码放在一个

<code>标签中，并且来自Gutenberg的内容默认情况下已经转义。



<p>我们花哨的代码块允许我们选择它的语言，突出显示某些行，并提供自定义标签。这在我们旧的编辑器中通过HTML属性都是可能的，因此这个块只是在所有这些之上提供了一个不错的UI。</p>



<p>该块非常特定于CSS-Tricks，因此开源它并没有多大意义。但我创建的另一个块是开源的，那就是CodePen嵌入块。我在CodePen博客上写过关于它的事情。</p>



<p>它允许你粘贴一个CodePen URL，它会转换成一个CodePen嵌入。oEmbed默认情况下已经这样做了，但是使用这个插件，你可以控制所有内容，例如高度、主题和默认选项卡。</p>



<p>在创作时实际看到嵌入的Pens非常棒！</p>



<h3 id="未解决的挑战">未解决的挑战</h3>



<p>目前最大的挑战是处理图像。在旧的编辑器中，我们集成了一个非常非常花哨的Cloudinary设置。图像会自动上传到Cloudinary，断点会以编程方式确定，会创建多个尺寸，会创建响应式图像语法，最终出现在HTML中的是具有Cloudinary托管图像的完美的响应式图像语法。这使我们能够利用CDN并以最佳格式提供图像。</p>



<p>使用Gutenberg创建的文章中没有发生这种情况。?</p>



<p>我需要找到或开发一个新的系统，该系统可以在网站的任何地方很好地处理图像，并且理想情况下使用更易于维护的非定制系统。我可能会使用Cloudinary来解决这个问题，我可能会尝试其他服务，我可能会让WordPress直接处理它，由Jetpack Site Accelerator支持。还不确定。总是有事情要做。</p>



<ol><li>我看到WordPress本身也参与了块脚手架游戏。他们的“create-wordpress-block”概念已经进入Gutenberg存储库本身，你可以用`npm init @wordpress/block [options] [slug]`启动它。</li></ol></code>