[wp-trac] [WordPress Trac] #42573: Templates not working properly

[WordPress Trac]

#42573: Templates not working properly
--------------------------+--------------------
 Reporter:  precies       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  4.9.1
Component:  Themes        |     Version:  4.9
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------

Comment (by majick):

 I see the advantages of applying file list caching here, but breaking
 things for end users and developers through the unintended consequences is
 something that can be avoided without much fuss... My suggestions:

 1. Identify what events could clear the file list cache for a theme when
 in the admin side? Maybe something simple like clearing the theme-specific
 file list in the function `get_page_templates` so at least it doesn't
 affect the standard UI selection etc.? eg.
 {{{#!php
 function get_page_template( $post = null, $post_type = 'page' ) {
     $theme = wp_get_theme();
     $theme->clear_cache( 'post_templates' );
     delete_transient( sanitize_key( 'files_' . $theme->cache_hash . '-' .
 $theme->get( 'Version' ) ) );
     return array_flip( $theme->get_page_templates( $post, $post_type ) );
 }
 }}}
 I'm not sure why this transient key structure? Seems to have come from the
 plugin file list side? But it's a bit of a mismatch to the rest of the
 theme class transient keys, otherwise it could be more simply cleared
 using WP Theme `clear_cache` method - which in any case is the other place
 where the theme file list could (and probably should) be cleared.

 2. Add a filter to disable file caching for a particular theme, this way
 theme developers could set the filter in an mu-plugin or something locally
 and not have to worry about the theme file list cache while they are
 developing. eg. in WP Theme method `get_files` instead of `$all_files =
 get_transient( $transient_key );` just:

 {{{#!php
 $all_files = apply_filters( 'theme_file_list_cache', get_transient(
 $transient_key ), $this );
 }}}

 That could be used like this for example:

 {{{#!php
 add_filter('theme_file_list_cache', function($filelist, $theme) {
     if ($theme->get_stylesheet() == 'my-theme') {return false;}
     return $filelist;
 }), 10, 2 );
 }}}

 Also as a sidenote going from just a few subdirectory levels to 100 levels
 seems like going from one extreme to the other... Sure it's well beyond
 time that it increased, but it seems it's this extreme swing that then
 required the caching for performance, which then caused this problem. 10
 would have been a safe maximum depth, with a filter for anyone really
 wanting more if needed in a particular plugin / theme.

 On a related note, only using a depth of 1 for searching page templates in
 the WP Theme method get_post_templates method while the levels are now
 cached 100 deep seems a bit bizarre. Doesn't it precludes template
 directory structures as simple as /content/post/ ? Any reason not to
 simply bump this value up to 2 or 3?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42573#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform