Data Validation: Always escape late / escape HTML Code

I share your frustration. Not because I believe they are wrong (per se), but because late escaping makes for a really awful developer experience and hard to read code.

There is currently a shared agreement among most professional-level WordPress developers that late escaping is the gold standard for output security:

As to how to solve your particular problem, I’m not 100% sure what THE marketplace will say but one approach they might accept would be to write your own template tags for each of the places where you are outputting HTML you don’t want to run through wp_kses_post() and store them in template-tags.php in your theme and point them to that file during code review your template tags.

Here is what one function might look like ti all the correct output escaping required:

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

Another approach might be to write all the HTML you want to use repeatedly as partial templates. What follows is a function called the_partial() to load your partial templates that you could include in your theme’s functions.php file:

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 );

}

And then this is how you might call your partial template from within your theme template file:

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

That said I have always hated late-escaping because it puts the burden on the programmer and not on the computer; wasn’t the latter supposed to make us more productive? 🙂 Plus late-escaping if very anti-D.R.Y.

Because late escaping bothered me so much I worked on a better solution, and have been using in client apps for a couple years now. The solution is to use objects for post types, taxonomy terms, user roles with Module and View objects where the View objects automatically escape Module methods based on naming conventions. I’ve recently released an open-source library WPLib that packages this better solution for others to use.

We are still in beta pending 1.0 release but the library is successfully in-use at numerous client sites; would love to get your take on the concept.

Here is a guide we have written for code-reviewing a WPLib-based sites as well as a guide for understanding a WPLib-based apps; that should give you enough to hopefully understand it without requiring you to try to grok the library from scratch.

BTW, the template suggestion I gave is pretty much baked into WPLib and is a best practice because we never want site-specific HTML to be buried into a function or class method where the themer has to know PHP to find and understand it.

Hope this helps?