[wp-trac] [WordPress Trac] #16128: WordPress Template System Override

[WordPress Trac]

#16128: WordPress Template System Override
-----------------------------------------+-------------------------
 Reporter:  pearsonified                 |       Owner:  (none)
     Type:  feature request              |      Status:  closed
 Priority:  normal                       |   Milestone:
Component:  Themes                       |     Version:  3.1
 Severity:  normal                       |  Resolution:  worksforme
 Keywords:  has-patch 2nd-opinion close  |     Focuses:
-----------------------------------------+-------------------------

Comment (by dhurlburtusa):

 I see how a template developer ''could'' use `template_redirect` to use
 their own template resolution algorithm and then exit/die but they are
 going to have issues with WP core and plugins because of different action
 priorities.

 Also, using an action named `template_redirect` implies an HTTP redirect
 -- not a way to handle certain requests and exit. Using it for other
 reasons is really a misuse of the action hook.

 Also, the "short-circuiting" code that follows the `template_redirect`
 action would likely need to be duplicated in the theme developer's
 `template_redirect` action.

 {{{
 if ( 'HEAD' === $_SERVER['REQUEST_METHOD'] && apply_filters(
 'exit_on_http_head', true ) ) {
         exit();
 }

 // Process feeds and trackbacks even if not using themes.
 if ( is_robots() ) :
         do_action( 'do_robots' );
         return;
 elseif ( is_feed() ) :
         do_feed();
         return;
 elseif ( is_trackback() ) :
         include( ABSPATH . 'wp-trackback.php' );
         return;
 endif;
 }}}

 As a theme developer, it would be nice to not have to keep these short-
 circuits in sync with WP core.

 If you are just trying to choose a different algorithm for resolving a
 page template, then having that ability where the current template
 hierarchy algorithm is done (after the "short-circuiting"/redirect code)
 would be ideal.

 Several very popular plugins I have examined use `template_redirect` for
 short-circuiting the request for whatever their reason. None of them have
 been doing it to choose a different page template algorithm.

 For example, WordFence uses it to short-circuit (not a redirect but an
 exit) with a priority of 1000.
 Yoast uses it for several reasons:
 - Do a redirect for site-maps using priority 0.
 - Do a redirect to an attachment using priority 1.
 - Do a redirect for `replytocom` using priority 1.
 - To add a response header using priority 10.
 - And for another reason not important to this discussion.
 WordPress core uses it for several reasons:
 - Old slug redirect using priority 10.
 - Perform a canonical redirect using priority 10.
 - A redirect in multi-site, MU, using priority 10
 - Redirect to admin URL or login URL when non-canonical URL used using
 priority 1000.

 So, what priority does a theme developer choose to ensure WP core and the
 installed plugins get a chance to handle their redirects when appropriate?
 Would it be safe to choose `PHP_INT_MAX`? Maybe.

 What is being done with the `template_redirect` action sounds very similar
 to middleware in Express apps (this is a Node.js thing for those that
 don't know) or `ServletFilter`s in J2EE (a Java server thing for those
 that don't know).

 **Some Food for Thought**

 Basically a chain of actions/tasks is set up. The first link in the chain
 gets an opportunity to tweak or completely handle the request. If it
 doesn't complete the request, then there is a mechanism that allows the
 next link to run.

 So, basically `template-loader.php`, is a list of actions with resolving a
 theme page template to include as the last action in the chain (assuming
 `wp_using_themes()` is true).

 The suggestion/patch in #48175 allows one to either use the current
 template hierarchy algorithm or replace it with their own. It provides a
 function that encapsulates the template hierarchy algorithm, which could
 still be used in the custom template resolution algorithm depending on the
 request.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/16128#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform