我和你一样沮丧。这并不是因为我认为他们（本质上）是错的，而是因为后期转义会给开发人员带来非常糟糕的体验和难以阅读的代码。

目前，大多数专业级WordPress开发人员都同意，延迟逃逸是输出安全的黄金标准：

• 10up on Late Escaping

• WordPress Codex on Output Sanitization

• WordPress VIP on Always Escaping Late

  wp_kses_post() 并将其存储在template-tags.php 并在代码检查模板标记时将其指向该文件。

  下面是一个函数的外观，需要所有正确的输出转义：

  function the_portfolio_link( $post_id ) {
     return \'<a href="\' . esc_url( get_post_permalink( $post_id ) ) . "\'>" . 
        esc_html( get_the_title( $post_id ) ) . \'</a>\';
  }
  

  另一种方法可能是编写所有要重复使用的HTML作为部分模板。下面是一个名为the_partial() 加载可以包含在主题中的部分模板functions.php 文件：

  function the_partial( $template_file, $_partial_file, $args = array() ) {
      $_partial_file = dirname( $template_file ) . "/partials/{$_partial_file}.php";
      extract( $args, EXTR_SKIP );
      unset( $args );
      require ( $_partial_file );
  
  }
  

  然后，您可以从主题模板文件中调用部分模板：

  <?php the_partial( __FILE__, \'portfolio-link\', array( \'post_id\' => $post->ID ) ); ?>
  

  也就是说，我一直讨厌迟到逃跑，因为它给程序员而不是电脑带来了负担；后者不应该让我们更有效率吗？：-）如果非常反D.R.Y.的话，还要晚点逃跑。

  因为迟到逃逸让我非常困扰，我研究了一个更好的解决方案，并且已经在客户端应用程序中使用了几年了。解决方案是将对象用于post类型、分类术语、具有模块的用户角色和视图对象，其中视图对象根据命名约定自动转义模块方法。我最近发布了一个开源库WPLib 将此更好的解决方案打包供其他人使用。

  我们仍在beta版中等待1.0版本的发布，但该库已成功用于多个客户端站点；很想了解你对这个概念的看法。

  这里是a guide we have written for code-reviewing a WPLib-based sites 以及a guide for understanding a WPLib-based apps; 这应该可以让您有足够的希望理解它，而不需要您从头开始摸索库。

  顺便说一句，我给出的模板建议基本上是在WPLib中进行的，这是一种最佳实践，因为我们永远不希望特定于站点的HTML被嵌入到函数或类方法中，而在这些函数或类方法中，主题者必须知道PHP才能找到并理解它。

  希望这有帮助？