locate_template() fails when called in API context

[paulschreiber]

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

For example:

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

becomes:

include( '' );

which fails.

Suggestion:
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;

[ocean90]

Duplicate of #14310.

Related: #18298, #20027

[SergeyBiryukov]

Related: #13239

[johnbillion]

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 WordPress.com?

[paulschreiber]

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:

[dd32]

This is a very WordPress.com 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 public-api.wordpress.com 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 WordPress.com 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.