[wp-trac] [WordPress Trac] #22355: Template stack - Beyond parent/child theme relationships

[WordPress Trac]

#22355: Template stack - Beyond parent/child theme relationships
-----------------------------+------------------
 Reporter:  johnjamesjacoby  |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  4.1
Component:  Themes           |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by johnjamesjacoby):

 Replying to [comment:46 rmccue]:
 > Added a simpler patch that handles this without adding a multitude of
 extra functions. It also adds a `theme_url` function as per #18302, since
 it makes a lot of sense to introduce that at the same time.
 >
 > IMO, there no reason we should store this in a global. Doing it there
 creates a lot of extra code over the simplicity of just filtering an
 array.

 If all we want is the ability to short-circuit the template loading
 process with a filter, there are easier ways to do that than this. The
 extra functions are important for encouraging plugin and theme libraries
 to announce to the application that they are introducing a new template
 directory location, to allow other libraries to interact with it
 accordingly.

 ----

 Example: both BuddyPress & bbPress are active, and both introduce their
 own default template locations. A new theme is activated that wants to
 unhook the default BuddyPress & bbPress default template locations, and
 completely own the output experience. If BuddyPress & bbPress are forced
 to register their locations as callbacks, they are much easier to
 manipulate. Without registering them, plugin and theme authors will need
 to guess at what each template location is for, and guess at how to
 interact with it.

 Example: both BuddyPress & bbPress are active, again both introducing
 default template locations. I write a plugin that includes a brand new set
 of template parts for handling what BuddyPress Member Profiles look like,
 with an emphasis on forum topics. In my plugin, I should be able to
 announce a new template location ahead of BuddyPress & bbPress, so my
 template parts are located first.

 In theory, each template and part could be registered (to avoid a whole
 mess of `file_exists()` checks) but that's a lot of additional work for
 not much gain.

 ----

 We should try to shy away from function names like
 `get_template_directories()`. The theme/template/stylesheet nomenclature
 is already messy, and it starts to collide with existing function names
 like `register_theme_directory()`, `search_theme_directories()`, etc...

 The revised approach in the most recent patches is better than what's in
 core today, but provides less structure than I originally proposed. I
 think the `_stack` naming conventions proposed in my original patch are
 more clear, and more accurately represent the complex relationships that
 plugins have with themes than yet-another-filter at the end of the
 template funnel.

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