WordPress 6.0 将尝试通过块系统处理评论列表。 这是一个落后于其他功能的领域，这些功能在之前的版本中已经完成了大部分工作。
上周，JuanMa Garrido 呼吁志愿者测试新区块 通过制作 WordPress 测试博客。 要求贡献者在评论中留下反馈或通过 Gutenberg GitHub 存储库创建新问题。
随着时间的推移，帖子评论列表发生了一些变化。 在 WordPress 2.7 之前，主题作者使用 PHP foreach 调用直接在其主题的 comments.php 模板中循环评论对象数组。 这是一个简单的基本 HTML 系统和散布在各处的一些模板标签。 在引入嵌套回复之前，它运行良好。 开发人员和用户都在疯狂争夺更新主题以使用新的 wp_list_comments() 函数。
快进到块模板和站点编辑器的时代。 再一次，评论发生了变化，但这只是表面上的。 Post Comments 块只是现有实现的包装器。 任何块主题作者都不得不使用自定义 PHP 过滤器来修改评论列表的输出，并且用户大多完全不走运，完全没有几个设计控件。
WordPress 6.0 几乎会给我们带来完整的循环。 评论输出通过块系统返回到模板。 不再需要 PHP 过滤器来移动布局。 用户可以通过站点编辑器进行修改。
诚然，在今天之前，我并没有花太多时间处理与评论相关的块。 在大多数情况下，我完全避开了它们，因为我正在等待预计将与 WordPress 6.0 一起登陆的一组块。
最新版本的 Gutenberg 插件附带了一整套特定于评论的块。 评论查询循环和评论模板应该与他们的帖子对应物类似地工作。 该集合包括评论作者、日期、回复链接和编辑链接的几个元数据相关块。 有一些新的分页，即将到来的头像块也将在评论模板中工作。
我打开了我的活动主题的单个帖子模板并删除了旧的帖子评论块。 然后，我插入了新的评论查询循环：
我很惊讶没有固执己见的风格——这是一个受欢迎的惊喜。 但是，由于默认输出包含了主题或用户可能使用的大部分可能的块，我希望看到它们包含在与布局相关的块之一中，例如 Columns 或 Row，提供一些简单的结构。
很快就移动了几块并获得了我喜欢的布局。 我确实得到了可怕的“Aww Snap！” 一次消息，由于编辑器崩溃而丢失了我所有的工作。 我无法复制这个问题，但从那时起，我每隔一分钟就会紧张地点击保存按钮。
除了一个随机的编辑器崩溃之外，一切都很顺利。 但是，那时我只涉及基础知识。 有了这些，我想知道新块是否会提供主题作者和用户等可以在实际项目中使用的工具。
我遇到的第一个问题是前端输出中缺少评论 ID。 这对于用户的浏览器在通过表单提交评论后跳转回他们的评论是必要的。 我还怀疑这是在单击回复链接时评论回复 JavaScript 工作所必需的。
前端输出不显示来自 comment_class() 函数的评论类。 这让主题作者目前无法根据深度、类型、状态等数据直接定位评论。 这是核心 WordPress 中先前评论列表解决方案的回归。
似乎也没有“评论标题”块，它会在列表上方输出“X 对帖子标题的响应”之类的内容。
大多数这些问题在核心中应该是微不足道的。 它们是我认为功能性评论列表的基线要求。 但是，有一个问题可能需要多个发布周期才能充实。
当前的设计工具中没有嵌套的概念。 对父评论的每条回复都会在左侧有一个小的填充凸起。 除此之外，所有嵌套级别都接受与其父级相同的设计处理，每个级别都在自己的小盒子中。 某些设计目前无法通过界面实现，例如为单个线程提供背景颜色。
通过设计工具无法完成以下简单的事情：
这只是一个普通的评论列表设计。 不要期望在没有自定义 CSS 的情况下做任何更高级的事情。
没有围绕层次结构构建的工具。 WordPress 块系统并没有很好地处理类似的场景。 例如，只需尝试使用导航块进行任何复杂的操作，即可查看其缺点。 但是，这比嵌套的注释列表要复杂得多。
这不是块系统本身的问题。 设计工具还没有赶上，在一个易于使用的界面中呈现如此复杂的东西并不是在公园里漫步。
从 Gutenberg 12.9 开始，从主题设计的角度来看，评论查询循环块感觉像是一种回归。 它不像当前的方法那样灵活，也不像多年前通过简单的 foreach 循环、一些 HTML 和一些模板标签输出注释时那样灵活。
虽然它可能受到限制，但它仍然赋予想要修改其评论列表设计的最终用户权力。 这是一个受欢迎的增强功能，我很高兴在未来的版本中 core 如何构建它。