Preprocess get_page_templates() and store in a global

[Master Jake]

The get_page_templates() function is only defined in certain admin-only actions (as far as I can tell). I came across a situation recently where I needed this list on the client side during a page load. Sure I could copy the WordPress function or require_once the file it's in, but that's messy and I'm sure discouraged against for future-proof and backwards compatibility issues.

It would be nice if WordPress preprocessed the list of valid, registered page templates in an early action and then stored that list in a new global (something like $wp_page_templates maybe?).

Thoughts?

[scribu]

Globals are evil.

I can't think of any objections to making get_page_templates() available everywhere, aside from the general "bloat!" argument.

[nacin]

I can't think of any objections to making get_page_templates() available everywhere

I can. It's an expensive function. It calls get_themes(), which is expensive, then loads the contents of each file into memory to look for the Template Name header comment.

If you want it on the frontend, include ABSPATH . 'wp-admin/includes/admin.php', and do so only when you need it (cache the hell out of the results).

[scribu]

Just because executing a function is expensive doesn't mean defining it is expensive.

That said, I agree with the wontfix.

[Master Jake]

If it's so expensive to get a list of valid, registered page templates, perhaps it would be worthwhile to modify how WordPress actually discovers them (rather than grepping all the php files looking for a specific comment). Maybe a new function like register_page_template( $name, $path )?

Regardless, the actual function call to retrieve the list would only need to be executed once per page load and then cached. Even though globals are evil, as you said scribu, that are used quite frequently already and so it definitely wouldn't be breaking any protocol to add one more.

[scribu]

that are used quite frequently already and so it definitely wouldn't be breaking any protocol to add one more.

That's actually a counter argument: there are too many already; let's not add any more.

register_page_template() seems like a good idea, but its time has passed. We will never be able to get rid of // Template Name, so there would be no performance benefit.

[Master Jake]

What if the get_page_templates first checks to see if any templates have been registered with register_page_templates and uses that list? As a fallback, it could perform the old-school grepping. This method would allow newer themes since the addition of the new registering system to use get_page_templates with no drop in performance, and older themes would work as well (just with a much greater performance hit).

[scribu]

Well, I guess that would work with an add_theme_support( 'new-style-page-templates' );

[nacin]

Once of the nice things about the template hierarchy is that It Just Works. For most of what you want to do, you just need to follow the hierarchy and, in the case of page templates, drop in a small comment at the top.

I think this might have some legs when considered in the context of templates for other post types, see #18375 and others, but not when taken face value.