[wp-trac] [WordPress Trac] #21062: Add a 'template_file' hook to load_template()

[WordPress Trac]

#21062: Add a 'template_file' hook to load_template()
--------------------------+--------------------------
 Reporter:  mikeschinkel  |       Owner:  johnbillion
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Themes        |     Version:  3.4
 Severity:  normal        |  Resolution:  wontfix
 Keywords:  has-patch     |     Focuses:  template
--------------------------+--------------------------

Comment (by MikeSchinkel):

 Replying to [comment:18 johnbillion]:
 >  * Mike opened this ticket because he wanted to view the included
 template files in Debug Bar.

 That was only one of several use-cases as I mentioned.

 A useful use-case is to allow plugins to provide default templates for
 features when the theme developer has not (yet) provided a template.

 Another would be to create wrappers for templates without having to modify
 the theme.  Wrappers could allow instrumentation in theme comments when
 `WP_DEBUG` is on so that themers that only really know HTML+CSS can be
 given instructions in view source for what variables and/or object
 properties are available, etc. I have found that very helpful in the past,
 but it's only possible for a theme where we control the full callstack to
 loading template parts.

 And there have been numerous times when I wanted more control over
 `get_template_part()` which this would provide, e.g. to be able to load a
 series of different templates based on meta field values in addition to
 just what was specified to `get_template_part()` in a parent theme.

 > All the cool kids use [https://wordpress.org/plugins/query-monitor/
 Query Monitor] these days

 Hmm. Haven't heard of that plugin.  Wonder who wrote it?  ;-p

 >  * Allowing a low level file inclusion to be filtered like this is
 asking for trouble. I share Nacin's wariness. I can imagine plugins
 reverting to using this filter in order to override all manner of things
 in themes and other plugins. It sounds like a potential nightmare.

 Given the purpose of plugins is to allow plugin developers to provide
 users with additional functionality that doesn't require the theme to be
 modified, not allow this hook seems contrary to the reason WordPress.org
 frowns on post types in themes.  By not supporting this then if certain
 type of functionality needs to be added it must be added via a theme and
 not a plugin which means that the end-user will loose the functionality
 when they switch themes, or worse the them will break.

 The downside of a plugin overriding something the user wants is the user
 stops using the plugin.  The downside of switching themes with a plugin
 that can't protect the user is a broken site.  It would seem to me that
 giving the plugin developer the control needed to ensure the site does not
 break would be better.

 Any chance of delineating a few of the types of things you fear here?

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