Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#37443 closed defect (bug) (duplicate)

locate_template() fails when called in API context

Reported by: paulschreiber's profile paulschreiber Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Themes Keywords: has-patch reporter-feedback
Focuses: template Cc:


On, locate_template() fails when called in the API context.

For example:

include( locate_template( 'template-parts/podcasts/promo.php' ) );


include( '' );

which fails.

Add filters to locate_template() to override STYLESHEETPATH and TEMPLATEPATH.

Change this:

if ( file_exists(STYLESHEETPATH . '/' . $template_name)) { 
  $located = STYLESHEETPATH . '/' . $template_name;

to this:

$stylesheet_path = apply_filters( 'stylesheet_path', STYLESHEETPATH ); 
if ( file_exists( $stylesheet_path . '/' . $template_name ) ) { 
  $located = $stylesheet_path . '/' . $template_name;

Attachments (1)

37443.patch (2.3 KB) - added by paulschreiber 8 years ago.

Download all attachments as: .zip

Change History (7)

8 years ago

#1 @paulschreiber
8 years ago

  • Keywords has-patch added

#2 @ocean90
8 years ago

  • Component changed from General to Themes
  • Focuses template added
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version trunk deleted

Duplicate of #14310.

Related: #18298, #20027

#4 @johnbillion
8 years ago

  • Keywords reporter-feedback added
  • Milestone set to Awaiting Review
  • Resolution duplicate deleted
  • Status changed from closed to reopened

While the proposed solution is a dupe of #14310, the reported issue is not.

@paulschreiber Can you explain why your example code fails to locate a template file please? Do you know where the problem lies? Does it only affect

#5 @paulschreiber
8 years ago

John, Here's what Derrick Tennant at Automattic told me in a WordPress VIP support ticket (55413):

This is because the function uses the constants STYLESHEETPATH and TEMPLATEPATH which were already defined (to a generic "public API" context) earlier than the VIP theme is loaded.

We had a similar problem with oEmbed content. In VIP ticket 38013, Nick Daugherty wrote:

In the context of the oEmbed api endpoint, the WP constants STYLESHEETPATH and STYLESHEETPATH will be set to a site other than FiveThirtyEight, as that's not the site loaded during an API call.
This means that the function locate_template() (and anything else that relies on those constants) does not work as expected. For FiveThrityEight, this means the 'burrito bracket' shortcode will not render correctly in the oEmbed context, as it does things like this:

#6 @dd32
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

This is a very specific bug due to the way they serve API requests, and for the most part isn't an issue for WordPress Core. (All constants are set based on instead of on the actual site being served in the API response)

However, removing the reliance upon constants and using functions which return filtered versions of the constants is a reasonable thing to do that will both help and future WordPress functionalities and developers alike.

That ultimately means this is a duplicate of #18298, at least as far as removing the usage of these constants in this spot goes.

Note: See TracTickets for help on using tickets.