deprecate TEMPLATEPATH and STYLESHEETPATH

[aaroncampbell]

As part of #15086 we wanted to add unit tests, but we came across a problem in ​#UT22. Basically locate_template() uses these constants instead of get_template_directory() and get_stylesheet_directory() which makes it impossible to use switch_theme(). It looks like the constants are only used in about 20 places through core, so I recommend we fix those places and deprecate the constants.

[scribu]

20 places isn't exactly few, but I agree that functions are better than constants, in this case.

[lloydbudd]

deprecate the constants

This would be very well received by the WordPress.com VIP team. We are regularly cleaning up TEMPLATEPATH and STYLESHEETPATH, replacing with the get_ functions in VIP partners themes' function to ensure features like mobile theme plugins and post-by-email work which don't go through initialization of those constants.

[aaroncampbell]

The patch removes all core uses of the constants. It's still used in twentyten and twentyeleven, so those should be fixed as well.

I'm not sure how we want to deprecate constants, so I just left them there. If we don't have any way in place to actually deprecate them, we should at LEAST add comments that say they're deprecated.

[scribu]

Yeah, it seems the practice is simply to add a @deprecated tag. Example: PLUGINDIR

[aaroncampbell]

18298.2.diff​ adds the @deprecated tag to the constants.

[cais]

Following along the lines of the @since documentation would there be a general benefit to having the version when the item is deprecated included as well?

For example, from this ticket's premise, @deprecated 3.3

[chipbennett]

Shouldn't these constants have version/replacement function information in the @deprecated phpDoc tag? (I ask mainly so that the various development tools, such as the Log Deprecated Notices Plugin and the Theme Check Plugin can be configured to pick up this information, to pass along to developers.

[aaroncampbell]

18298.3.diff​ adds php doc like this:

 * @deprecated 3.3
 * @deprecated Use get_stylesheet_directory()

[scribu]

@chip: Log Deprecated Notices plugin can't do anything about it, since there's no mechanism in PHP to find out when a particular constant is used. Same for global variables (which is why they're evil).

[chipbennett]

Replying to scribu:

@chip: Log Deprecated Notices plugin can't do anything about it, since there's no mechanism in PHP to find out when a particular constant is used. Same for global variables (which is why they're evil).

Why is that? Couldn't either Plugin read the phpDoc headers, and cross reference the @deprecated tag against the constant being used anywhere in the Theme files? (Isn't that what they do anyway, to provide the deprecation (since-version, alternative function)?

[aaroncampbell]

I think that what he's saying is that you'd have to build some sort of regex to look for the constant being used since there's no way to actually throw a deprecated notice since it's not a function. For example, how do you find:

$test = $prefix . TEMPLATEPATH . $suffix;

but not

$test = $prefix . 'TEMPLATEPATH' . $suffix;
$test = "$prefix TEMPLATEPATH $suffix";
$test = <<<TEST
    $prefix
    Bad: TEMPLATEPATH
    $suffix
TEST;

[chipbennett]

Replying to aaroncampbell:

I think that what he's saying is that you'd have to build some sort of regex to look for the constant being used since there's no way to actually throw a deprecated notice since it's not a function.

Pross is the WPTRT's resident RegEx ninja; if anybody can figure out a way to do it, he can. :) So, maybe it's something that can find its way into Theme Check. My interest in the question (which now exceeds the scope of the patch itself) is in providing as much information as possible to Theme Developers, and getting them pre-emptively to begin to adopt the use of get_template_directory_*() and get_stylesheet_directory_*().

[toscho]

Replying to aaroncampbell:

I think that what he's saying is that you'd have to build some sort of regex to look for the constant being used

Impossible. PHP is more complex than PCRE, so you’d have to use a tokenizer. Just think about constants in comments … ;)

[chipbennett]

Replying to toscho:

Replying to aaroncampbell:

I think that what he's saying is that you'd have to build some sort of regex to look for the constant being used

Impossible. PHP is more complex than PCRE, so you’d have to use a tokenizer. Just think about constants in comments … ;)

Which would be just fine for Theme Check. It ignores anything in PHP comments. Also, even if it finds false-positives, that's okay. Most such output is listed as INFO anyway: meant as a hint to the developer/reviewer to verify that its usage is proper.

In any case, this rabbit trail has strayed far from the intent of the ticket. I'll take it offline with Pross, and if he comes up with something viable for Theme Check, then I will take a look at the rest of the defined constants with @deprecated, to see if any could benefit from additional deprecation information, and submit a separate patch.

[omarabid]

Any updates on this. This ticket has over a year, and yet the Constants are still used instead of the function.

The file is question is: wp-includes/template.php

The Constants are used in the locate_template() function. This makes it impossible to change the location of my template files. For a special App. I'm building, I need to change these locations.

This is possible, but only if the functions were used instead of the Constant.

Is there a reason to keep the Constants instead? I have changed my WordPress Core code (which is bad), shall I submit my modification.

[CrazyJaco]

Also checking in for an update on this.

I have a similar need as omarabid.

It looks like its been 2 years since there was any sort of activity on this. Is this still on anyone's radar?

Thanks

[DrewAPicture]

I think we could take another look at this. Moving to 4.0 for consideration.

[wonderboymusic]

In 28563:

Replaces all uses of TEMPLATEPATH and STYLESHEETPATH in core with get_template_directory() and get_stylesheet_directory().

Add @deprecated annotations to TEMPLATEPATH and STYLESHEETPATH definitions.

Props obenland, aaroncampbell.
Fixes #18298.

[DrewAPicture]

In 28569:

Use three-digit x.x.x style version for @deprecated phpDoc tags.

See #18298.

[nacin]

I've always thought this was a bit silly, but didn't care enough to complain (and, of course, I like making things more testable). However, I've noticed we've now greatly increased what gets executed with the inclusion of functions.php and every theme template file. In the case of including functions.php, we're running each function twice (via is_child_theme(), too). These functions are definitely not as cheap as a constant — they inclusively run three filters and a get_option() call (five if multiple theme roots are in play).

I have not yet run any kind of profiling on this.

Eliminating TEMPLATEPATH and STYLESHEETPATH was designed to make things more testable, I get that. But that doesn't apply to wp-settings.php, for example. This also exposes the ability to tinker with locate_template() by filtering the theme directory itself, which seems pretty scary. And, the changes in locate_template() mean these functions are called in a loop, rather than outside of it, especially problematic because it could be called up to four times per iteration even though the values might be the same (in the case of no child theme).

I just want to make sure we know what we're getting into, and also optimize for the fact that we're now dealing with dynamic code so we need to be more mindful of how we're writing our control structures.

[nacin]

Suggest we revert [28563] for now.

[DrewAPicture]

Replying to nacin:

Suggest we revert [28563] for now.

+1. Good points all in comment:31. "I just want to make sure we know what we're getting into ...".

[wonderboymusic]

In 29044:

Revert [28563]. See #18298.

[nacin]

Happy to see this happen at some point, but it's not a priority and isn't a straight replacement due to the cost differences in these functions.

[chriscct7]

Re: comment:31 It'd be interesting to see the difference in real cost could be benchmarked for comparison

[dd32]

#37443 was marked as a duplicate.

[hkchakladar]

Are those constants deprecated? I can't see deprecated tag in WP-4.9.1

[sebastienserre]

Hello,

I think this ticket should be consider again as logs are full of

PHP Warning:  Use of undefined constant TEMPLATEPATH - assumed 'TEMPLATEPATH' (this will throw an Error in a future version of PHP) in /var/www/XXX/prod/wp-includes/theme.php on line 158
Warning: Use of undefined constant TEMPLATEPATH - assumed 'TEMPLATEPATH' (this will throw an Error in a future version of PHP) in /var/www/XXX/prod/wp-includes/theme.php on line 158
PHP Warning:  Use of undefined constant STYLESHEETPATH - assumed 'STYLESHEETPATH' (this will throw an Error in a future version of PHP) in /var/www/XXX/prod/wp-includes/theme.php on line 158
Warning: Use of undefined constant STYLESHEETPATH - assumed 'STYLESHEETPATH' (this will throw an Error in a future version of PHP) in /var/www/XXX/prod/wp-includes/theme.php on line 158

We should maybe just check if constant are defined ?

[SergeyBiryukov]

Replying to sebastienserre:

We should maybe just check if constant are defined ?

They are defined via wp_templating_constants() early in wp-settings.php, so it seems like the only way to get these warnings is to call is_child_theme() too early: directly on file inclusion or on one of the following actions:

• plugins_loaded
• sanitize_comment_cookies
• setup_theme

I suppose is_child_theme() could check if TEMPLATEPATH and STYLESHEETPATH are defined, and return false otherwise, but that might not be the expected result if a child theme is indeed in use, it's just that the check is performed too early. Perhaps a _doing_it_wrong() message would be a better option, similar to the one we have for conditional tags:

if ( ! isset( $wp_query ) ) {
	_doing_it_wrong( __FUNCTION__, __( 'Conditional query tags do not work before the query is run. Before then, they always return false.' ), '3.1.0' );
	return false;
}