使用 WordPress “创建一次，随处发布”
已发表: 2022-03-10COPE 是一种减少将我们的内容发布到不同媒体（如网站、电子邮件、应用程序等）所需的工作量的策略。 它首先由 NPR 首创，它通过为可用于所有不同媒体的内容建立单一事实来源来实现其目标。
拥有适用于任何地方的内容并非易事，因为每种媒体都有自己的要求。 例如，虽然 HTML 对打印 Web 内容有效，但这种语言对 iOS/Android 应用程序无效。 类似地，我们可以为 web 的 HTML 添加类，但这些必须转换为电子邮件的样式。
解决这个难题的方法是形式与内容分离：内容的呈现和意义必须解耦，只有意义作为唯一的真相来源。 然后可以将演示文稿添加到另一层（特定于所选媒体）。
例如，给定以下 HTML 代码， <p>是一个 HTML 标记，主要适用于 Web，属性class="align-center"是表示（将元素放在“中心”对于基于屏幕的媒体，但不适用于基于音频的媒体，例如 Amazon Alexa）：
<p class="align-center">Hello world!</p>因此，这段内容不能作为单一的事实来源，必须将其转换为一种将意思与表示分开的格式，例如以下一段 JSON 代码：
{ content: "Hello world!", placement: "center", type: "paragraph" }这段代码可以用作内容的单一真实来源，因为我们可以从中重新创建用于网络的 HTML 代码，并为其他媒体获取适当的格式。
为什么选择 WordPress
由于以下几个原因，WordPress 是实施 COPE 策略的理想选择：
- 它用途广泛。
WordPress 数据库模型没有定义一个固定的、死板的内容模型； 相反，它是为多功能性而创建的，可以通过使用元字段来创建各种内容模型，这允许为四种不同的实体存储额外的数据：帖子和自定义帖子类型、用户、评论和分类（标签和类别）。 - 它很强大。
WordPress 作为 CMS（内容管理系统）大放异彩，其插件生态系统可以轻松添加新功能。 - 它很普遍。
据估计，有 1/3 的网站在 WordPress 上运行。 然后，在网络上工作的相当数量的人知道并且能够使用，即 WordPress。 不仅是开发人员，还有博主、销售人员、营销人员等等。 然后，许多不同的利益相关者，无论他们的技术背景如何，都将能够产生作为单一事实来源的内容。 - 它是无头的。
无头是一种将内容与表示层分离的能力，它是实现 COPE 的基本特征（以便能够将数据馈送到不同的媒体）。
自从从 4.7 版开始将 WP REST API 合并到核心中，并且自 5.0 版中推出 Gutenberg（为此必须实现大量 REST API 端点）以来更为显着，WordPress 可以被视为无头 CMS，因为大多数 WordPress 内容构建在任何堆栈上的任何应用程序都可以通过 REST API 访问。
此外，最近创建的 WPGraphQL 集成了 WordPress 和 GraphQL，可以使用这个日益流行的 API 将 WordPress 中的内容馈送到任何应用程序中。 最后，我自己的项目 PoP 最近添加了一个用于 WordPress 的 API 实现，它允许将 WordPress 数据导出为 REST、GraphQL 或 PoP 原生格式。 - 它有Gutenberg ，这是一个基于块的编辑器，它极大地帮助了 COPE 的实现，因为它基于块的概念（如下面的部分所述）。
表示信息的 Blob 与块
Blob 是一个单一的信息单元，它们一起存储在数据库中。 例如，在依赖 blob 存储信息的 CMS 上编写下面的博客文章会将博客文章内容存储在单个数据库条目中 - 包含相同的内容：
<p>Look at this wonderful tango:</p> <figure> <iframe width="951" height="535" src="https://www.youtube.com/embed/sxm3Xyutc1s" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <figcaption>An exquisite tango performance</figcaption> </figure>可以理解，这篇博文中的重要信息（例如段落中的内容，以及 Youtube 视频的 URL、尺寸和属性）并不容易获得：如果我们想要检索其中的任何一个就其本身而言，我们需要解析 HTML 代码以提取它们——这远非理想的解决方案。
块的作用不同。 通过将信息表示为块列表，我们可以以更具语义和可访问性的方式存储内容。 每个块传达它自己的内容和它自己的属性，这些属性可以取决于它的类型（例如，它可能是一个段落还是一个视频？）。
例如，上面的 HTML 代码可以表示为这样的块列表：
{ [ type: "paragraph", content: "Look at this wonderful tango:" ], [ type: "embed", provider: "Youtube", url: "https://www.youtube.com/embed/sxm3Xyutc1s", width: 951, height: 535, frameborder: 0, allowfullscreen: true, allow: "accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture", caption: "An exquisite tango performance" ] } 通过这种表示信息的方式，我们可以轻松地单独使用任何一条数据，并使其适应必须显示的特定介质。 例如，如果我们想从博客文章中提取所有视频以显示在汽车娱乐系统上，我们可以简单地迭代所有信息块，选择type="embed"和provider="Youtube"的那些，然后提取来自他们的网址。 同样，如果我们想在 Apple Watch 上显示视频，我们不需要关心视频的尺寸，因此我们可以直接忽略属性width和height 。
古腾堡如何实现块
在 WordPress 5.0 版之前，WordPress 使用 blob 将帖子内容存储在数据库中。 从 5.0 版本开始，WordPress 附带 Gutenberg，一个基于块的编辑器，启用了处理上述内容的增强方式，这代表了 COPE 实施的突破。 不幸的是，Gutenberg 并不是针对这个特定的用例设计的，它的信息表示与刚刚描述的块不同，导致我们需要处理一些不便。
我们先来看看上面介绍的博文是如何通过古腾堡保存的：
<!-- wp:paragraph --> <p>Look at this wonderful tango:</p> <!-- /wp:paragraph --> <!-- wp:core-embed/youtube {"url":"https://www.youtube.com/embed/sxm3Xyutc1s","type":"rich","providerNameSlug":"embed-handler","className":"wp-embed-aspect-16-9 wp-has-aspect-ratio"} --> <figure class="wp-block-embed-youtube wp-block-embed is-type-rich is-provider-embed-handler wp-embed-aspect-16-9 wp-has-aspect-ratio"> <div class="wp-block-embed__wrapper"> https://www.youtube.com/embed/sxm3Xyutc1s </div> <figcaption>An exquisite tango performance</figcaption> </figure> <!-- /wp:core-embed/youtube -->从这段代码中，我们可以做出以下观察：
块一起保存在同一个数据库条目中
上面的代码中有两个块：
<!-- wp:paragraph --> <p>Look at this wonderful tango:</p> <!-- /wp:paragraph --> <!-- wp:core-embed/youtube {"url":"https://www.youtube.com/embed/sxm3Xyutc1s","type":"rich","providerNameSlug":"embed-handler","className":"wp-embed-aspect-16-9 wp-has-aspect-ratio"} --> <figure class="wp-block-embed-youtube wp-block-embed is-type-rich is-provider-embed-handler wp-embed-aspect-16-9 wp-has-aspect-ratio"> <div class="wp-block-embed__wrapper"> https://www.youtube.com/embed/sxm3Xyutc1s </div> <figcaption>An exquisite tango performance</figcaption> </figure> <!-- /wp:core-embed/youtube --> 除了全局（也称为“可重用”）块，它们在数据库中有自己的条目并且可以通过它们的 ID 直接引用，所有块都一起保存在表wp_posts中的博客文章条目中。
因此，要检索特定块的信息，我们首先需要解析内容并将所有块相互隔离。 方便的是，WordPress 提供了函数parse_blocks($content)来做到这一点。 此函数接收包含博客文章内容（HTML 格式）的字符串，并返回一个 JSON 对象，其中包含所有包含块的数据。
块类型和属性通过 HTML 注释传达
每个块由一个起始标签<!-- wp:{block-type} {block-attributes-encoded-as-JSON} -->和一个结束标签<!-- /wp:{block-type} -->分隔<!-- /wp:{block-type} --> which（作为 HTML 注释）确保该信息在网站上显示时不可见。 但是，我们不能直接在其他媒体上显示博客文章，因为 HTML 评论可能是可见的，显示为乱码内容。 不过这没什么大不了的，因为通过函数parse_blocks($content)解析内容后，HTML 注释被删除，我们可以直接将块数据作为 JSON 对象进行操作。
块包含 HTML
段落块的内容是"<p>Look at this wonderful tango:</p>" ，而不是"Look at this wonderful tango:" 。 因此，它包含对其他媒体无用的 HTML 代码（标签<p>和</p> ），因此必须删除，例如通过 PHP 函数strip_tags($content) 。
在剥离标签时，我们可以保留那些明确传达语义信息的 HTML 标签，例如标签<strong>和<em> （而不是它们的对应物<b>和<i> ，它们仅适用于基于屏幕的媒体），并且删除所有其他标签。 这是因为语义标签也很有可能被其他媒体正确解释（例如，Amazon Alexa 可以识别标签<strong>和<em> ，并在阅读一段文本时相应地改变其语音和语调）。 为此，我们使用包含允许标签的第二个参数调用strip_tags函数，并将其放置在包装函数中以方便起见：
function strip_html_tags($content) { return strip_tags($content, '<strong><em>'); }视频的标题保存在 HTML 中，而不是作为属性
从 Youtube 视频块中可以看出，标题"An exquisite tango performance"存储在 HTML 代码中（由标签<figcaption />括起来），但不在 JSON 编码的属性对象中。 因此，要提取标题，我们需要解析块内容，例如通过正则表达式：
function extract_caption($content) { $matches = []; preg_match('/<figcaption>(.*?)<\/figcaption>/', $content, $matches); if ($caption = $matches[1]) { return strip_html_tags($caption); } return null; }这是我们必须克服的障碍，以便从 Gutenberg 块中提取所有元数据。 这发生在几个区块上； 由于并非所有元数据都保存为属性，因此我们必须首先确定哪些是这些元数据，然后解析 HTML 内容以逐块和逐块地提取它们。
关于 COPE，这代表浪费了获得真正最佳解决方案的机会。 可以说替代选项也不理想，因为它会复制信息，将其存储在 HTML 中和作为属性，这违反了 DRY（ D on't R epeat Y ourself）原则。 但是，这种违规行为确实已经发生：例如，属性className包含值"wp-embed-aspect-16-9 wp-has-aspect-ratio" ，该值也打印在内容中，位于 HTML 属性class下。
实施 COPE
注意：我已经发布了这个功能，包括下面描述的所有代码，作为 WordPress 插件块元数据。 欢迎您安装并使用它，这样您就可以体验 COPE 的强大功能。 源代码可在此 GitHub 存储库中找到。
现在我们知道了块的内部表示是什么样的，让我们继续通过 Gutenberg 实现 COPE。 该程序将涉及以下步骤：
- 因为函数
parse_blocks($content)返回一个带有嵌套层级的 JSON 对象，我们必须首先简化这个结构。 - 我们迭代所有块，并为每个块识别它们的元数据片段并提取它们，在此过程中将它们转换为与媒体无关的格式。 将哪些属性添加到响应中可能因块类型而异。
- 我们最终通过 API (REST/GraphQL/PoP) 提供数据。
让我们一一实现这些步骤。
1. 简化 JSON 对象的结构
从函数parse_blocks($content)返回的 JSON 对象具有嵌套架构，其中普通块的数据出现在第一级，但缺少引用的可重用块的数据（仅添加引用块的数据），嵌套块（在其他块中添加）和分组块（几个块可以组合在一起）的数据出现在 1 个或多个子级别下。 这种架构使得处理帖子内容中所有块的块数据变得困难，因为一方面缺少一些数据，另一方面我们不知道先验数据位于多少级别。 此外，每对块都有一个块分隔符，不包含任何内容，可以安全地忽略。
例如，从包含简单块、全局块、包含简单块的嵌套块和一组简单块的帖子中获得的响应按顺序如下：
[ // Simple block { "blockName": "core/image", "attrs": { "id": 70, "sizeSlug": "large" }, "innerBlocks": [], "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/sandwich-1024x614.jpg\" alt=\"\" class=\"wp-image-70\"/><figcaption>This is a normal block</figcaption></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/sandwich-1024x614.jpg\" alt=\"\" class=\"wp-image-70\"/><figcaption>This is a normal block</figcaption></figure>\n" ] }, // Empty block divider { "blockName": null, "attrs": [], "innerBlocks": [], "innerHTML": "\n\n", "innerContent": [ "\n\n" ] }, // Reference to reusable block { "blockName": "core/block", "attrs": { "ref": 218 }, "innerBlocks": [], "innerHTML": "", "innerContent": [] }, // Empty block divider { "blockName": null, "attrs": [], "innerBlocks": [], "innerHTML": "\n\n", "innerContent": [ "\n\n" ] }, // Nested block { "blockName": "core/columns", "attrs": [], // Contained nested blocks "innerBlocks": [ { "blockName": "core/column", "attrs": [], // Contained nested blocks "innerBlocks": [ { "blockName": "core/image", "attrs": { "id": 69, "sizeSlug": "large" }, "innerBlocks": [], "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/espresso-1024x614.jpg\" alt=\"\" class=\"wp-image-69\"/></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/espresso-1024x614.jpg\" alt=\"\" class=\"wp-image-69\"/></figure>\n" ] } ], "innerHTML": "\n<div class=\"wp-block-column\"></div>\n", "innerContent": [ "\n<div class=\"wp-block-column\">", null, "</div>\n" ] }, { "blockName": "core/column", "attrs": [], // Contained nested blocks "innerBlocks": [ { "blockName": "core/paragraph", "attrs": [], "innerBlocks": [], "innerHTML": "\n<p>This is how I wake up every morning</p>\n", "innerContent": [ "\n<p>This is how I wake up every morning</p>\n" ] } ], "innerHTML": "\n<div class=\"wp-block-column\"></div>\n", "innerContent": [ "\n<div class=\"wp-block-column\">", null, "</div>\n" ] } ], "innerHTML": "\n<div class=\"wp-block-columns\">\n\n</div>\n", "innerContent": [ "\n<div class=\"wp-block-columns\">", null, "\n\n", null, "</div>\n" ] }, // Empty block divider { "blockName": null, "attrs": [], "innerBlocks": [], "innerHTML": "\n\n", "innerContent": [ "\n\n" ] }, // Block group { "blockName": "core/group", "attrs": [], // Contained grouped blocks "innerBlocks": [ { "blockName": "core/image", "attrs": { "id": 71, "sizeSlug": "large" }, "innerBlocks": [], "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/coffee-1024x614.jpg\" alt=\"\" class=\"wp-image-71\"/><figcaption>First element of the group</figcaption></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/coffee-1024x614.jpg\" alt=\"\" class=\"wp-image-71\"/><figcaption>First element of the group</figcaption></figure>\n" ] }, { "blockName": "core/paragraph", "attrs": [], "innerBlocks": [], "innerHTML": "\n<p>Second element of the group</p>\n", "innerContent": [ "\n<p>Second element of the group</p>\n" ] } ], "innerHTML": "\n<div class=\"wp-block-group\"><div class=\"wp-block-group__inner-container\">\n\n</div></div>\n", "innerContent": [ "\n<div class=\"wp-block-group\"><div class=\"wp-block-group__inner-container\">", null, "\n\n", null, "</div></div>\n" ] } ]更好的解决方案是将所有数据都放在第一层，这样遍历所有块数据的逻辑就大大简化了。 因此，我们必须为这些可重用/嵌套/分组的块获取数据，并将其添加到第一级。 从上面的 JSON 代码中可以看出：
- 空分隔块具有值为
NULL的属性"blockName" - 对可重用块的引用通过
$block["attrs"]["ref"]定义 - 嵌套块和组块在
$block["innerBlocks"]下定义它们包含的块
因此，以下 PHP 代码删除了空的分隔块，识别可重用/嵌套/分组的块并将它们的数据添加到第一级，并从所有子级中删除所有数据：
/** * Export all (Gutenberg) blocks' data from a WordPress post */ function get_block_data($content, $remove_divider_block = true) { // Parse the blocks, and convert them into a single-level array $ret = []; $blocks = parse_blocks($content); recursively_add_blocks($ret, $blocks); // Maybe remove blocks without name if ($remove_divider_block) { $ret = remove_blocks_without_name($ret); } // Remove 'innerBlocks' property if it exists (since that code was copied to the first level, it is currently duplicated) foreach ($ret as &$block) { unset($block['innerBlocks']); } return $ret; } /** * Remove the blocks without name, such as the empty block divider */ function remove_blocks_without_name($blocks) { return array_values(array_filter( $blocks, function($block) { return $block['blockName']; } )); } /** * Add block data (including global and nested blocks) into the first level of the array */ function recursively_add_blocks(&$ret, $blocks) { foreach ($blocks as $block) { // Global block: add the referenced block instead of this one if ($block['attrs']['ref']) { $ret = array_merge( $ret, recursively_render_block_core_block($block['attrs']) ); } // Normal block: add it directly else { $ret[] = $block; } // If it contains nested or grouped blocks, add them too if ($block['innerBlocks']) { recursively_add_blocks($ret, $block['innerBlocks']); } } } /** * Function based on `render_block_core_block` */ function recursively_render_block_core_block($attributes) { if (empty($attributes['ref'])) { return []; } $reusable_block = get_post($attributes['ref']); if (!$reusable_block || 'wp_block' !== $reusable_block->post_type) { return []; } if ('publish' !== $reusable_block->post_status || ! empty($reusable_block->post_password)) { return []; } return get_block_data($reusable_block->post_content); } 调用函数get_block_data($content)传递帖子内容（ $post->post_content ）作为参数，我们现在获得以下响应：
[[ { "blockName": "core/image", "attrs": { "id": 70, "sizeSlug": "large" }, "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/sandwich-1024x614.jpg\" alt=\"\" class=\"wp-image-70\"/><figcaption>This is a normal block</figcaption></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/sandwich-1024x614.jpg\" alt=\"\" class=\"wp-image-70\"/><figcaption>This is a normal block</figcaption></figure>\n" ] }, { "blockName": "core/paragraph", "attrs": [], "innerHTML": "\n<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>\n", "innerContent": [ "\n<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>\n" ] }, { "blockName": "core/columns", "attrs": [], "innerHTML": "\n<div class=\"wp-block-columns\">\n\n</div>\n", "innerContent": [ "\n<div class=\"wp-block-columns\">", null, "\n\n", null, "</div>\n" ] }, { "blockName": "core/column", "attrs": [], "innerHTML": "\n<div class=\"wp-block-column\"></div>\n", "innerContent": [ "\n<div class=\"wp-block-column\">", null, "</div>\n" ] }, { "blockName": "core/image", "attrs": { "id": 69, "sizeSlug": "large" }, "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/espresso-1024x614.jpg\" alt=\"\" class=\"wp-image-69\"/></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/espresso-1024x614.jpg\" alt=\"\" class=\"wp-image-69\"/></figure>\n" ] }, { "blockName": "core/column", "attrs": [], "innerHTML": "\n<div class=\"wp-block-column\"></div>\n", "innerContent": [ "\n<div class=\"wp-block-column\">", null, "</div>\n" ] }, { "blockName": "core/paragraph", "attrs": [], "innerHTML": "\n<p>This is how I wake up every morning</p>\n", "innerContent": [ "\n<p>This is how I wake up every morning</p>\n" ] }, { "blockName": "core/group", "attrs": [], "innerHTML": "\n<div class=\"wp-block-group\"><div class=\"wp-block-group__inner-container\">\n\n</div></div>\n", "innerContent": [ "\n<div class=\"wp-block-group\"><div class=\"wp-block-group__inner-container\">", null, "\n\n", null, "</div></div>\n" ] }, { "blockName": "core/image", "attrs": { "id": 71, "sizeSlug": "large" }, "innerHTML": "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/coffee-1024x614.jpg\" alt=\"\" class=\"wp-image-71\"/><figcaption>First element of the group</figcaption></figure>\n", "innerContent": [ "\n<figure class=\"wp-block-image size-large\"><img src=\"https://localhost/wp-content/uploads/2017/12/coffee-1024x614.jpg\" alt=\"\" class=\"wp-image-71\"/><figcaption>First element of the group</figcaption></figure>\n" ] }, { "blockName": "core/paragraph", "attrs": [], "innerHTML": "\n<p>Second element of the group</p>\n", "innerContent": [ "\n<p>Second element of the group</p>\n" ] } ] 尽管不是绝对必要，但创建一个 REST API 端点以输出我们的新函数get_block_data($content)的结果非常有帮助，这将使我们能够轻松了解特定帖子中包含哪些块，以及它们是如何结构化的。 下面的代码在/wp-json/block-metadata/v1/data/{POST_ID}下添加了这样的端点：
/** * Define REST endpoint to visualize a post's block data */ add_action('rest_api_init', function () { register_rest_route('block-metadata/v1', 'data/(?P \d+)', [ 'methods' => 'GET', 'callback' => 'get_post_blocks' ]); }); function get_post_blocks($request) { $post = get_post($request['post_id']); if (!$post) { return new WP_Error('empty_post', 'There is no post with this ID', array('status' => 404)); } $block_data = get_block_data($post->post_content); $response = new WP_REST_Response($block_data); $response->set_status(200); return $response; }/** * Define REST endpoint to visualize a post's block data */ add_action('rest_api_init', function () { register_rest_route('block-metadata/v1', 'data/(?P \d+)', [ 'methods' => 'GET', 'callback' => 'get_post_blocks' ]); }); function get_post_blocks($request) { $post = get_post($request['post_id']); if (!$post) { return new WP_Error('empty_post', 'There is no post with this ID', array('status' => 404)); } $block_data = get_block_data($post->post_content); $response = new WP_REST_Response($block_data); $response->set_status(200); return $response; }
要查看它的实际效果，请查看导出此帖子数据的链接。
2. 将所有块元数据提取为媒介不可知的格式
在这个阶段，我们有包含不适合 COPE 的 HTML 代码的块数据。 因此，我们必须去除每个块的非语义 HTML 标签，以将其转换为与媒介无关的格式。
我们可以决定哪些是必须在块类型的基础上提取的属性（例如，提取"paragraph"块的文本对齐属性、 "youtube embed"块的视频 URL 属性等） .
正如我们之前看到的，并非所有属性实际上都保存为块属性，而是保存在块的内部内容中，因此，对于这些情况，我们需要使用正则表达式解析 HTML 内容，以便提取这些元数据。
在检查了通过 WordPress 核心发布的所有块之后，我决定不为以下块提取元数据：
"core/columns""core/column""core/cover" | 这些仅适用于基于屏幕的媒体，并且（作为嵌套块）很难处理。 |
"core/html" | 这仅对网络有意义。 |
"core/table""core/button""core/media-text" | 我不知道如何以与媒体无关的方式来表示他们的数据，或者它是否有意义。 |
这给我留下了以下块，我将继续提取它们的元数据：
-
'core/paragraph' -
'core/image' -
'core-embed/youtube'（作为所有'core-embed'块的代表） -
'core/heading' -
'core/gallery' -
'core/list' -
'core/audio' -
'core/file' -
'core/video' -
'core/code' -
'core/preformatted' -
'core/quote'和'core/pullquote' -
'core/verse'
为了提取元数据，我们创建函数get_block_metadata($block_data)接收一个数组，其中包含每个块的块数据（即我们之前实现的函数get_block_data的输出），并且取决于块类型（在属性"blockName"下提供） )，决定需要哪些属性以及如何提取它们：
/** * Process all (Gutenberg) blocks' metadata into a medium-agnostic format from a WordPress post */ function get_block_metadata($block_data) { $ret = []; foreach ($block_data as $block) { $blockMeta = null; switch ($block['blockName']) { case ...: $blockMeta = ... break; case ...: $blockMeta = ... break; ... } if ($blockMeta) { $ret[] = [ 'blockName' => $block['blockName'], 'meta' => $blockMeta, ]; } } return $ret; }让我们一一提取每种块类型的元数据：
“core/paragraph”
只需从内容中删除 HTML 标记，然后删除尾随断线。
case 'core/paragraph': $blockMeta = [ 'content' => trim(strip_html_tags($block['innerHTML'])), ]; break; 'core/image'
该块具有引用上传媒体文件的 ID，或者，如果没有，则必须从<img src="...">下提取图像源。 几个属性（caption、linkDestination、link、alignment）是可选的。
case 'core/image': $blockMeta = []; // If inserting the image from the Media Manager, it has an ID if ($block['attrs']['id'] && $img = wp_get_attachment_image_src($block['attrs']['id'], $block['attrs']['sizeSlug'])) { $blockMeta['img'] = [ 'src' => $img[0], 'width' => $img[1], 'height' => $img[2], ]; } elseif ($src = extract_image_src($block['innerHTML'])) { $blockMeta['src'] = $src; } if ($caption = extract_caption($block['innerHTML'])) { $blockMeta['caption'] = $caption; } if ($linkDestination = $block['attrs']['linkDestination']) { $blockMeta['linkDestination'] = $linkDestination; if ($link = extract_link($block['innerHTML'])) { $blockMeta['link'] = $link; } } if ($align = $block['attrs']['align']) { $blockMeta['align'] = $align; } break; 创建函数extract_image_src 、 extract_caption和extract_link是有意义的，因为它们的正则表达式将一次又一次地用于多个块。 请注意，Gutenberg 中的标题可以包含链接（ <a href="..."> ），但是，当调用strip_html_tags时，这些链接会从标题中删除。
尽管很遗憾，但我发现这种做法是不可避免的，因为我们不能保证在非网络平台上工作的链接。 因此，尽管内容由于可以用于不同的媒体而获得普遍性，但它也失去了特异性，因此与为特定平台创建和定制的内容相比，其质量较差。
function extract_caption($innerHTML) { $matches = []; preg_match('/<figcaption>(.*?)<\/figcaption>/', $innerHTML, $matches); if ($caption = $matches[1]) { return strip_html_tags($caption); } return null; } function extract_link($innerHTML) { $matches = []; preg_match('/<a href="(.*?)">(.*?)<\/a>>', $innerHTML, $matches); if ($link = $matches[1]) { return $link; } return null; } function extract_image_src($innerHTML) { $matches = []; preg_match('/<img src="(.*?)"/', $innerHTML, $matches); if ($src = $matches[1]) { return $src; } return null; } 'core-embed/youtube'
只需从块属性中检索视频 URL，并从 HTML 内容中提取其标题（如果存在）。
case 'core-embed/youtube': $blockMeta = [ 'url' => $block['attrs']['url'], ]; if ($caption = extract_caption($block['innerHTML'])) { $blockMeta['caption'] = $caption; } break; 'core/heading'
标题大小（h1、h2、...、h6）和标题文本都不是属性，因此必须从 HTML 内容中获取。 请注意， size属性不是返回标头的 HTML 标记，而是简单的等效表示，它更不可知，并且对非 Web 平台更有意义。
case 'core/heading': $matches = []; preg_match('/<h[1-6])>(.*?)<\/h([1-6])>/', $block['innerHTML'], $matches); $sizes = [ null, 'xxl', 'xl', 'l', 'm', 'sm', 'xs', ]; $blockMeta = [ 'size' => $sizes[$matches[1]], 'heading' => $matches[2], ]; break; 'core/gallery'
不幸的是，对于图片库，我无法从每个图像中提取标题，因为这些不是属性，并且通过简单的正则表达式提取它们可能会失败：如果第一个和第三个元素有标题，但没有第二个，那么我不知道哪个标题对应于哪个图像（而且我没有花时间创建一个复杂的正则表达式）。 同样，在下面的逻辑中，我总是检索"full"图像大小，但是，不一定是这种情况，我不知道如何推断出更合适的大小。
case 'core/gallery': $imgs = []; foreach ($block['attrs']['ids'] as $img_id) { $img = wp_get_attachment_image_src($img_id, 'full'); $imgs[] = [ 'src' => $img[0], 'width' => $img[1], 'height' => $img[2], ]; } $blockMeta = [ 'imgs' => $imgs, ]; break; 'core/list'
只需将<li>元素转换为项目数组。
case 'core/list': $matches = []; preg_match_all('/<li>(.*?)<\/li>/', $block['innerHTML'], $matches); if ($items = $matches[1]) { $blockMeta = [ 'items' => array_map('strip_html_tags', $items), ]; } break; 'core/audio'
获取对应上传的媒体文件的URL。
case 'core/audio': $blockMeta = [ 'src' => wp_get_attachment_url($block['attrs']['id']), ]; break; 'core/file'
虽然文件的 URL 是一个属性，但它的文本必须从内部内容中提取。
case 'core/file': $href = $block['attrs']['href']; $matches = []; preg_match('/<a href="'.str_replace('/', '\/', $href).'">(.*?)<\/a>/', $block['innerHTML'], $matches); $blockMeta = [ 'href' => $href, 'text' => strip_html_tags($matches[1]), ]; break; 'core/video'
获取视频 URL 和所有属性以通过正则表达式配置视频的播放方式。 如果 Gutenberg 改变了这些属性在代码中的打印顺序，那么这个正则表达式将停止工作，这证明了不直接通过块属性添加元数据的问题之一。
case 'core/video': $matches = []; preg_match('/ 'core/code'
Simply extract the code from within <code /> .
case 'core/code': $matches = []; preg_match('/<code>(.*?)<\/code>/is', $block['innerHTML'], $matches); $blockMeta = [ 'code' => $matches[1], ]; break; 'core/preformatted'
Similar to <code /> , but we must watch out that Gutenberg hardcodes a class too.
case 'core/preformatted': $matches = []; preg_match('/<pre class="wp-block-preformatted">(.*?)<\/pre>/is', $block['innerHTML'], $matches); $blockMeta = [ 'text' => strip_html_tags($matches[1]), ]; break; 'core/quote' and 'core/pullquote'
We must convert all inner <p /> tags to their equivalent generic "\n" character.
case 'core/quote': case 'core/pullquote': $matches = []; $regexes = [ 'core/quote' => '/<blockquote class=\"wp-block-quote\">(.*?)<\/blockquote>/', 'core/pullquote' => '/<figure class=\"wp-block-pullquote\"><blockquote>(.*?)<\/blockquote><\/figure>/', ]; preg_match($regexes[$block['blockName']], $block['innerHTML'], $matches); if ($quoteHTML = $matches[1]) { preg_match_all('/<p>(.*?)<\/p>/', $quoteHTML, $matches); $blockMeta = [ 'quote' => strip_html_tags(implode('\n', $matches[1])), ]; preg_match('/<cite>(.*?)<\/cite>/', $quoteHTML, $matches); if ($cite = $matches[1]) { $blockMeta['cite'] = strip_html_tags($cite); } } break; 'core/verse'
Similar situation to <pre /> .
case 'core/verse': $matches = []; preg_match('/<pre class="wp-block-verse">(.*?)<\/pre>/is', $block['innerHTML'], $matches); $blockMeta = [ 'text' => strip_html_tags($matches[1]), ]; break;3. Exporting Data Through An API
Now that we have extracted all block metadata, we need to make it available to our different mediums, through an API. WordPress has access to the following APIs:
- REST, through the WP REST API (integrated in WordPress core)
- GraphQL, through WPGraphQL
- PoP, through its implementation for WordPress
Let's see how to export the data through each of them.
休息
The following code creates endpoint /wp-json/block-metadata/v1/metadata/{POST_ID} which exports all block metadata for a specific post:
/** * Define REST endpoints to export the blocks' metadata for a specific post */ add_action('rest_api_init', function () { register_rest_route('block-metadata/v1', 'metadata/(?P \d+)', [ 'methods' => 'GET', 'callback' => 'get_post_block_meta' ]); }); function get_post_block_meta($request) { $post = get_post($request['post_id']); if (!$post) { return new WP_Error('empty_post', 'There is no post with this ID', array('status' => 404)); } $block_data = get_block_data($post->post_content); $block_metadata = get_block_metadata($block_data); $response = new WP_REST_Response($block_metadata); $response->set_status(200); return $response; }/** * Define REST endpoints to export the blocks' metadata for a specific post */ add_action('rest_api_init', function () { register_rest_route('block-metadata/v1', 'metadata/(?P \d+)', [ 'methods' => 'GET', 'callback' => 'get_post_block_meta' ]); }); function get_post_block_meta($request) { $post = get_post($request['post_id']); if (!$post) { return new WP_Error('empty_post', 'There is no post with this ID', array('status' => 404)); } $block_data = get_block_data($post->post_content); $block_metadata = get_block_metadata($block_data); $response = new WP_REST_Response($block_metadata); $response->set_status(200); return $response; }
To see it working, this link (corresponding to this blog post) displays the metadata for blocks of all the types analyzed earlier on.
GraphQL (Through WPGraphQL)
GraphQL works by setting-up schemas and types which define the structure of the content, from which arises this API's power to fetch exactly the required data and nothing else. Setting-up schemas works very well when the structure of the object has a unique representation.
In our case, however, the metadata returned by a new field "block_metadata" (which calls our newly-created function get_block_metadata ) depends on the specific block type, so the structure of the response can vary wildly; GraphQL provides a solution to this issue through a Union type, allowing to return one among a set of different types. However, its implementation for all different variations of the metadata structure has proved to be a lot of work, and I quit along the way .
As an alternative (not ideal) solution, I decided to provide the response by simply encoding the JSON object through a new field "jsonencoded_block_metadata" :
/** * Define WPGraphQL field "jsonencoded_block_metadata" */ add_action('graphql_register_types', function() { register_graphql_field( 'Post', 'jsonencoded_block_metadata', [ 'type' => 'String', 'description' => __('Post blocks encoded as JSON', 'wp-graphql'), 'resolve' => function($post) { $post = get_post($post->ID); $block_data = get_block_data($post->post_content); $block_metadata = get_block_metadata($block_data); return json_encode($block_metadata); } ] ); });流行音乐
Note: This functionality is available on its own GitHub repo.
The final API is called PoP, which is a little-known project I've been working on for several years now. I have recently converted it into a full-fledged API, with the capacity to produce a response compatible with both REST and GraphQL, and which even benefits from the advantages from these 2 APIs, at the same time: no under/over-fetching of data, like in GraphQL, while being cacheable on the server-side and not susceptible to DoS attacks, like REST. It offers a mix between the two of them: REST-like endpoints with GraphQL-like queries.
The block metadata is made available through the API through the following code:
class PostFieldValueResolver extends AbstractDBDataFieldValueResolver { public static function getClassesToAttachTo(): array { return array(\PoP\Posts\FieldResolver::class); } public function resolveValue(FieldResolverInterface $fieldResolver, $resultItem, string $fieldName, array $fieldArgs = []) { $post = $resultItem; switch ($fieldName) { case 'block-metadata': $block_data = \Leoloso\BlockMetadata\Data::get_block_data($post->post_content); $block_metadata = \Leoloso\BlockMetadata\Metadata::get_block_metadata($block_data); // Filter by blockName if ($blockName = $fieldArgs['blockname']) { $block_metadata = array_filter( $block_metadata, function($block) use($blockName) { return $block['blockName'] == $blockName; } ); } return $block_metadata; } return parent::resolveValue($fieldResolver, $resultItem, $fieldName, $fieldArgs); } }To see it in action, this link displays the block metadata (+ ID, title and URL of the post, and the ID and name of its author, a la GraphQL) for a list of posts.
此外，与 GraphQL 参数类似，我们的查询可以通过字段参数进行自定义，从而仅获取对特定平台有意义的数据。 例如，如果我们希望提取添加到所有帖子中的所有 Youtube 视频，我们可以添加修饰符(blockname:core-embed/youtube)到端点 URL 中的字段block-metadata ，就像在这个链接中一样。 或者，如果我们想从特定帖子中提取所有图像，我们可以添加修饰符(blockname:core/image) ，就像在这个其他链接|id|title 中一样。
结论
COPE（“一次创建，随处发布”）策略通过创建单一来源，帮助我们减少创建必须在不同媒体（网络、电子邮件、应用程序、家庭助理、虚拟现实等）上运行的多个应用程序所需的工作量我们内容的真实性。 关于 WordPress，尽管它一直作为内容管理系统大放异彩，但实施 COPE 策略在历史上被证明是一个挑战。
然而，最近的一些发展使得为 WordPress 实施这种策略变得越来越可行。 一方面，自从集成到 WP REST API 的核心中，尤其是自 Gutenberg 推出以来，大多数 WordPress 内容都可以通过 API 访问，使其成为真正的无头系统。 另一方面，Gutenberg（它是新的默认内容编辑器）是基于块的，使得博客文章中的所有元数据都可以很容易地被 API 访问。
因此，为 WordPress 实施 COPE 很简单。 在本文中，我们已经了解了如何做到这一点，并且所有相关代码都已通过多个存储库提供。 尽管该解决方案不是最佳的（因为它涉及大量解析 HTML 代码），但它仍然运行良好，因此可以大大减少将我们的应用程序发布到多个平台所需的工作量。 对此表示敬意！