为什么我们不使用WordPress的Gutenberg…

WordPress的古腾堡(Gutenberg)编辑器的加入带来了很多非常好的东西-CMS的总体方向是基恩可以同意的。 用blocks而不是一个古老的所见即所得领域来撰写文章是一种新鲜的空气,也是期待已久的补充。 我们认为,界面的设计是对以前版本过时和过时的UI的重大改进。 但是,我们不能使用它,真是太可惜了。

为什么我们要使用它

Keen一直在使用Advanced Custom Fields的Flexible Content字段类型为我们的客户构建健壮的,完全可定制的Web界面。 这与Gutenberg Blocks的工作原理非常非常相似,这种方法有很多好处。 营销人员不仅可以构建帖子,还可以构建整个站点 (大型菜单,复杂的页脚,页面等),所有这些都可以使用专门为手边站点设计和定制的布局构建工具。 这为内容编辑者提供了完美的自定义级别 -一切都是经过品牌,故意和控制的,但还没有达到Visual Composer或类似水平。 这些工具太开放了,提供了太多的灵活性,结果在前端出现了令人不安的内容组合。

实际上,我们通过在无头的角色中使用WP来使这种灵活的内容方法更进一步了-完全废弃WP的PHP模板渲染,该渲染已随着时间的推移而绝对旋转,而是编写了负责任的,可维护的ReactJS接口,使用其REST API消耗了WP的内容。

请在此处查看我们的样板:

keen-studio / react-wp-rest
将WP Rest API与服务器渲染的React应用程序配对的样板– keen-studio / react-wp-rest github.com

这带来了一些非常整洁的好处。 我们可以构建使用其ACF布局组件一对一映射的React组件。 让我们以Slider为例-它可能有一个标题,一个描述,一个为几种不同的布局提供样式的样式选项,然后是幻灯片本身。 可以对幻灯片进行自定义填充,也可以用任何给定帖子类型的最新帖子预填充这些幻灯片。 在WP中,我们可以使内容作者能够选择他们想要在何处使用此滑块以及如何使用它。

然后,React可以使用这些数据,并将其用于显示一个漂亮而整洁的Slider组件,其中填充了WP的道具。

和古腾堡积木一样,对吗?

今天不行。

那怎么办?

目前,由古腾堡(Gutenberg)编辑器编写和保存的内容已作为呈现的HTML内容存储在数据库中。 我理解WP为什么这样做,因为帖子的content由任意数量的块组成,并且需要某种标准化的方式来混搭文章的内容 -更不用说最终的语义内容的格式最终看起来像。 这是经典WP编辑器始终将内容保存到数据库中的方式。

当您从使用Gutenberg构建的WP REST API中检索帖子时,其内容可能如下所示:

  

这是古腾堡(Gutenberg)的测试帖子。 这是放置在弹出的第一个小块中的示例内容。

”
此处是带有字幕

WP通常使用古腾堡(Gutenberg)特定的HTML注释层次结构来解析这些混乱的数据,但是当准备并通过REST API发送帖子时,所有注释都被剥离,并且我们获得了HTML块。

我希望我永远不必破解通过注释的组合将内容HTML字符串解析为相应块的PHP。 对我来说,这是一种奇怪的处理方式,而且我从不喜欢将注释用于程序设计目的。 我想象在前端进行逆向工程,以便能够通过操纵HTML注释来将React组件与存储在块中的数据配合使用,而我宁愿付出代价。

ACF到REST API插件,我们已经习惯并实际上已经拥有的是一个不错的JSON小型数组,已经准备好在React-y时代大放异彩:

有了这些数据,我们可以mapblocks数组,通过acf_fc_layout键动态选择要抓取的组件,并用期望的道具填充选定的组件。 美丽。

但是,如果您现在想与Gutenberg一起使用React前端,则必须

dangerouslySetInnerHTML 设置InnerHTML的全部内容 —根本无法使用React组件。

考虑到当今的网络生态系统需要媒体丰富的帖子和高度动态,引人入胜的内容,因此帖子的内容是基于组件的基础架构提供最大价值的地方。 没有这个,就没有太多理由甚至将React引入前端,因为它只是为了网站的页眉和页脚,而以增加很多复杂性为代价,这太可惜了。

所有希望都不会丢失,因为WP团队正在积极评估添加一个选项,以将类似结构的数据用于其REST API。 看这里:

PHP API概述·问题#8352·WordPress /古腾堡
该问题概述了尚待引入或扩展的新PHP API。 要记住的重要方面…… github.com

对REST API的简单添加将使Keen成为Gutenberg的追随者。 现在,我们开始梦想并在2006年技术展中闲逛。

敏锐的建议方法

我们不希望WP仅将附加的,重复的内容集(由块键构成)添加到API响应中。 API响应需要保持尽可能的小,这在理想情况下意味着没有重复的内容。

如果为我们提供了一个查询参数,如_embed参数-可能类似于_with_blocks或类似的东西,它将替换 content: rendered发送的默认HTML content: rendered使用格式正确的JSON结构content: rendered ,那将是惊人的。

有一个插件可以将这种格式化的块JSON添加到API响应中,但是它非常庞大:

royboy789 / gutenberg-object-plugin
将古腾堡数据另存为对象/数组,并允许您通过REST API访问它– royboy789 / gutenberg-object-plugin github.com

它添加了一个全新的数据库表,在content:rendered复制了响应内容,并且…是另一个插件。 这应该内置到核心中,并且绝对不应该增加这种复杂性。 没有给royboy769royboy769 ,因为我认为我们可以喝杯啤酒和相处,而且我认为他的脑袋显然在正确的位置,但这是WP的责任。

无论如何,您怎么看? 有什么聪明的主意吗?

PS — Keen将使用我们在本文中提到的代码和方法来启动几个单独的站点,我们对能够实现的功能感到非常满意。 我们将深入讨论这些项目的构建过程,并将发布文章以详细介绍在接下来的几个月中获得的技巧,窍门和经验教训。 敬请期待。

同时,也许我们会在2006年的网络空间见您🙂