倡萌此前在的文章中提到过针对古腾堡块的区块模板和全站编辑趋势：基于块的主题开发，将引入块模板文件，而且是html格式的文件。
今天看到了wptavern的一篇文章《基于块的主题以及HTML模板中的动态数据问题》，觉得这个话题可能对于WordPress主题开发者来说，还是比较有引导意义的，简单翻译这里过来分享一下。
古腾堡（Gutenberg）项目及其最终的全站点编辑功能正在遇到一个重大问题，需要解决。未来基于块的主题目前正朝着由纯HTML文件组成的模板系统发展。尽管这对于主题的大部分输出都是有效的，但麻烦在于弄清楚项目将如何处理动态值。
大多数讨论都集中在处理URL上，URL可能是最常见的用例。当前，主题模板具有各种动态内容。随着我们继续进行全站点编辑，大部分内容将被替换为块。但是，并非所有动态数据都具有等效块。
一个很好的例子是主题作者当前无法将主页URL添加到导航块中。一些基于块的实验性主题使用的是简单的/字符，它指向许多WordPress安装中的错误位置。
尽早解决此问题对于在当今世界中主题开发的进展很重要。但是，需要精心设计这样的解决方案，以使主题社区不会因模板实施不佳而陷入十年或更长时间的泥潭。
目前的建议
Gutenberg存储库当前有一张开放的工单，用于讨论如何处理模板中的动态值。目前，有四个关于如何解决该问题的建议。
即时字符串替换
一种解决方案是使用PHP解析每个HTML文件，并动态替换表示动态数据的字符串。这将需要在每次页面加载时解析所有主题模板。缺点是它将减慢页面加载速度。我们将需要进行实际的单元测试，以查看此方法在加载时间上产生了多少峰值。
假设类似Mustache的语法，模板将具有诸如以下图像输出之类的值：
<img src="{{ theme_image_example }}" />采用这种解决方案的另一个好处是，WordPress默认可以自动转义这些动态值。这将给主题安全带来福音，这是主题审查团队面临的最大问题之一。
一次性字符串替换
第二种解决方案建议使用相同的方法，但是在主题激活后仅对HTML文件进行一次解析，然后用适当的值替换动态值。该方法的最大好处是解析不会影响前端加载速度。
此方法有问题，因为它在初始解析后并未考虑模板的更改。当值通过用户输入更改时，它也不处理方案。例如，用户可以决定更改其博客文章页面的位置。因此，已解析为静态的URL将指向错误的位置。
模板转化为JSON
第三种解决方案提出了将主题文件转换为JSON的想法。从JSON文件中解析和提取数据比从HTML文件中解析和提取数据要容易得多。但是，主题设计器不会编写JSON来生成模板输出。HTML存在是有原因的。
该解决方案将给新的主题作者带来极大的障碍，以至于那些刚刚学习了基本CSS和HTML的人都无法进入WordPress主题开发。这个想法与模板设计的想法太不一致，因此不应认真考虑。
通过PHP返回块的模板
第四个也是最后一个建议是将PHP文件与返回块模板的函数一起使用。这种方法非常简单，对于熟悉PHP的现有主题作者来说，很容易采用。
模板如下所示：
function my_theme_front_page() {
return '<!-- wp:cover {"url":"' . get_template_directory_uri() .'/block-background-image.png","id":273,"dimRatio":0,"minHeight":647,"align":"wide"} -->';
}这个想法比HTML更加关注PHP。对于Gutenberg开发团队来说，这将是最容易实现的解决方案。但是，就像JSON方法一样，它将为新的WordPress主题作者增加入门难度。这将意味着确保引号和双引号字符不会混淆。该方法容易出现错误，并且与现代模板无关。
模板应始终以HTML优先
模板应始终以HTML优先。即使在我们当前的主题系统中，主题作者也可以通过仅了解HTML和CSS来构建美观、安全且功能丰富的主题。PHP是次要的，尤其是在模板方面。我们的模板系统依赖于了解HTML并插入一些模板标签 ——这是WordPress提供的PHP函数——用于在HTML标签之间插入。这种简单性在某种程度上，使得WordPress主题开发对于愿意花一点时间的人来说如此容易学习的原因。
基于块的主题有可能降低障碍，甚至低于我们当前的模板系统。但是，作为JSON或PHP函数的模板则与此相反。任何使我们远离Web基本构件HTML的解决方案都不应放在讨论桌上。
现在可能是采用适当的PHP模板引擎的时候了。有很多例子。Twig、Blade、Smarty等已经存在了多年。这些也以新语法的形式存在一些输入障碍，但这应该比学习将模板标签插入当前系统更容易一些。
至少，我们将需要找出一种在本质上是静态HTML文件中处理动态数据的解决方案。
