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 插件附带了一整套特定于评论的块。评论查询循环和评论模板应该与它们的帖子对应物类似地工作。该集合包括几个与元数据相关的块，用于评论作者、日期、回复链接和编辑链接。有一些新的分页，即将推出的头像块也将在评论模板中工作。
我打开了我的活动主题的单个帖子模板并删除了旧的帖子评论块。然后，我插入了一个新的评论查询循环：
default Comment查询循环块输出。
我很惊讶没有固执己见的风格 - 一个受欢迎的惊喜。但是，由于默认输出包括主题或用户可能使用的大部分可能的块，我希望看到它们包含在与布局相关的块之一中，例如列或行，以提供一些简单的结构。
快速移动了几块，得到了我喜欢的布局。我确实得到了可怕的“Aww Snap！”消息一次，由于编辑器崩溃而丢失了我所有的工作。我无法重现这个问题，但从那以后我每分钟都紧张地按下保存按钮。
自定义评论查询循环块的编辑器和前端视图。
除了随机的编辑器崩溃外，一切都很顺利。但是，那时我只介绍了基础知识。顺便说一句，我想知道新块是否会提供主题作者和用户都可以在实际项目中使用的工具。
我遇到的第一个问题是前端输出中缺少评论 ID。这对于用户的浏览器在通过表单提交评论后跳回到他们的评论是必要的。我还怀疑这对于在单击回复链接时评论回复 javascript 起作用是必要的。
前端输出不显示来自 comment_class() 函数的注释类。这使得主题作者目前无法根据深度、类型、状态等数据直接定位评论。这是对核心 WordPress 中之前评论列表解决方案的倒退。
似乎也没有“评论标题”块，它会在列表上方输出类似“X 对帖子标题的回应”之类的内容。
这些问题中的大多数在核心中应该是微不足道的。它们是我认为的功能审查列表的基线要求。但是，有一个问题可能需要多个发布周期才能充实。
目前的设计工具中没有嵌套的概念。每个对父评论的回复都会在左侧有一个小的实心凸起。除此之外，所有嵌套关卡的设计都与其父关卡相同，每个关卡都在自己的小盒子里。某些设计目前无法通过界面实现，例如为单个线程提供背景颜色。
下面这些简单的东西是设计工具无法做到的：
这只是一个普通的评论列表设计。不要指望在没有自定义 CSS 的情况下做任何更酷的事情。
没有围绕层次结构构建的工具。 WordPress 块系统不能很好地处理类似的情况。例如，尝试用导航块做任何复杂的事情，看看它的缺点。然而，这比嵌套的评论列表更复杂。
这不是方块系统本身的问题。设计工具还没有跟上，在易于使用的界面中呈现如此复杂的东西并不是在公园散步。
从 Gutenberg 12.9 开始，从主题设计的角度来看，评论查询循环块感觉像是回归。它不像当前方法那样灵活，也不像多年前那样灵活，当时评论是通过简单的 foreach 循环、一些 HTML 和一些模板标签输出的。
尽管它可能具有限制性，但它仍然为想要修改其评论列表设计的最终用户提供了支持。这是一个受欢迎的增强功能，我很高兴 core 在未来的版本中如何构建它。
出处
