[wp-trac] [WordPress Trac] #20138: What happens to get_current_theme()?
WordPress Trac
wp-trac at lists.automattic.com
Wed Feb 29 05:08:04 UTC 2012
#20138: What happens to get_current_theme()?
--------------------------+------------------
Reporter: nacin | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 3.4
Component: Themes | Version:
Severity: normal | Resolution:
Keywords: |
--------------------------+------------------
Description changed by nacin:
Old description:
> After #20103, get_current_theme() is only useful for returning the theme
> name untranslated. It no longer serves as a key anywhere (like for
> get_themes()), and we previously phased it out in the theme mod
> functions.
>
> The question is, what to do with it?
>
> No theme in http://wpcom-themes.svn.automattic.com uses
> get_current_theme() in the footer (only on theme options pages), but that
> doesn't mean some other theme isn't doing exactly that. On one hand, if
> we eliminate the current_theme option, get_current_theme() will force
> style.css to be read, which normally does not happen on the frontend.
> But, if we keep the current_theme option, the name will not be
> translated.
>
> My current thought is this:
> 1. Deprecate get_current_theme(). Have it call
> wp_get_theme()->get('Name'), as it does now, but remove the current_theme
> option all together. No more caching the style.css read.
> 2. Introduce a new way to get a theme name.
>
> Point 2 is interesting. I think it could be solved with a fancy
> __toString() method on WP_Theme, which means that `echo wp_get_theme()`
> could actually echo `wp_get_theme()->display('Name')`. Or, another
> function.
>
> Both points leave a conundrum, though — whether style.css reads (a single
> style.css read, not every theme) are not the end of the world on the
> frontend.
>
> I had a cursory thought about forcing WP_Theme, wp_get_themes(), and
> wp_get_theme() to only be used in the admin, and force the
> includes/admin.php bootstrap to load for the very few situations where
> we'll need it (update checks, switch_theme(), the new customizer, and
> deprecated compat).
>
> I am going to do some profiling to see how bad the fread is. We already
> do plenty of file_exists checks as part of the template loader, so one or
> two more of those are not the end of the world.
New description:
After #20103, get_current_theme() is only useful for returning the theme
name untranslated. It no longer serves as a key anywhere (like for
get_themes()), and we previously phased it out in the theme mod functions.
The question is, what to do with it?
No theme in http://wpcom-themes.svn.automattic.com uses
get_current_theme() in the footer (only on theme options pages), but that
doesn't mean some other theme isn't doing exactly that. On one hand, if we
eliminate the current_theme option, get_current_theme() will force
style.css to be read, which normally does not happen on the frontend. But,
if we keep the current_theme option, the name will not be translated.
My current thought is this:
1. Deprecate get_current_theme(). Have it call
wp_get_theme()->get('Name'), as it does now, but remove the current_theme
option all together. No more caching the style.css read.
2. Introduce a new way to get a theme name.
Point 2 is interesting. I think it could be solved with a fancy
`__toString()` method on WP_Theme, which means that `echo wp_get_theme()`
could actually echo `wp_get_theme()->display('Name')`. Or, another
function.
Both points leave a conundrum, though — whether style.css reads (a single
style.css read, not every theme) are not the end of the world on the
frontend.
I had a cursory thought about forcing WP_Theme, wp_get_themes(), and
wp_get_theme() to only be used in the admin, and force the
includes/admin.php bootstrap to load for the very few situations where
we'll need it (update checks, switch_theme(), the new customizer, and
deprecated compat).
I am going to do some profiling to see how bad the fread is. We already do
plenty of file_exists checks as part of the template loader, so one or two
more of those are not the end of the world.
--
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20138#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list