Support page templates located in a subdirectory of the theme

[westi]

#10959 hi-lighted that we displayed these page templates but they didn't work.

For 2.9 we stopped displaying them.

In the future we should support them

Test cases in WordPress tests: test_admin_includes_theme.php::test_page_templates_subdir()

[nathanrice]

I'll try to work up a patch for this. I don't think it wastes any execution overhead to include them, but just need to figure out a way to get the entire relative path included as the value, for instance, 'folder/file.php' or 'folder/folder/file.php' ...

[rzen]

I'm jumping on board with this patch. We'll see how it goes

[rzen]

It looks like whatever was breaking the page template selector was resolved through another patch, because simply removing the lines from get_page_template() that prevent including subdirectories allowed everything to work as expected.

To accommodate the 'folder/folder/template.php' hierarchy that nathan mentions above (and that I would also like to use) I've modified /wp-includes/theme.php to loop through a second level. The variable names could probably be better. I also went ahead and added a filter of 'available_page_templates', at the suggestion of the ever-brilliant filosofo, to the output of get_page_template() should theme devs want to specify their own array of templates at an even greater depth.

Let the record show that this was my first attempt ever at patching core files. Review the patch at your own risk.

[scribu]

Does this work with child themes as well? That was the reason why we disabled it before.

[rzen]

Ah, nope. It works for templates nested in their parent themes, but not templates nested in child themes themselves. I'm uploading a new patch to extend the same directory depth for child themes as well.

[rzen]

Extends nested page templates to child themes

[scribu]

There's a lot of duplicated code there. Consider putting it into a helper function.

[scribu]

Related: #13265

[rzen]

Creates helper function for recursively searching through entire theme directory

[rzen]

After 14 months, I finally worked up the courage to take scribu's advice and create a helper function. This function eliminates all the redundant code I introduced in 11216.2.diff as well as the repeated code from the original loops for collecting the template files.

With this patch, WordPress can support page templates in any level of subdirectory within a theme, both for parent and child themes, and not lose track of it's location.

I've personally tested it with page templates nested as deep as 2 directories for both a parent and child theme.

[SergeyBiryukov]

Version field indicates when the enhancement was initially suggested.

[rzen]

Ah, got it, I wondered about the redundancy between version and milestone. In that case, it is actually from 2.9.

Technically it's a bugfix, but I won't touch that dial. ...though, I'd really love to see this slink in to 3.3 because of it :)

[nacin]

Let's remove the code from theme.php rather than commenting it out. Also, $ignore should be = array() and we should array_merge() in .svn, .git, ., and .. -- there's never a reason for those to be searched.

At the same time, this is actually doing three loops through the directories, rather than two. Perhaps there's a better way to clear up the abstraction.

Definitely not 3.3 material, but could go into 3.4.

[nacin]

With WP_Theme, this is now an easy win.

[nacin]

In [20318]:

Support page templates located in a subdirectory of the theme. fixes #11216.

[toscho]

There are some methods with @access public in PHPDoc while their visibility is set to private: _name_sort(), _name_sort_i18n() and scandir().

I think @access is obsolete when a visibility keyword is used in the method declaration.

[scribu]

Agreed. @access should only be used for private functions, since we can't use namespaces yet.

[nacin]

Replying to toscho:

There are some methods with @access public in PHPDoc while their visibility is set to private: _name_sort(), _name_sort_i18n() and scandir().

I think @access is obsolete when a visibility keyword is used in the method declaration.

I think I am going to make scandir() private, but _name_sort() and _name_sort_i18n() are public only because they are used as a callback. Their usage is private. Hence @access private.

You're probably right about @access not being necessary when a visibility keyword is in play. However, @access private specifically hides it from phpdocumentor and I am wondering if it overrides a visibility keyword.

Happy to remove @access private, and make scandir() private. New ticket?

[nacin]

Sorry, I got confused for a second there. _name_sort() and _name_sort_i18n() are indeed private, and can be since they are used by sort_by_name(). Their docs are wrong.

[nacin]

In [20324]:

Correct docs for WP_Theme scandir(), _name_sort(), and _name_sort_i18n() methods. All of them are private. see #11216, #20103.

[nacin]

In [20327]:

Set WP_Theme::scandir()'s default depth to 0 (flat), as intended. Cache untranslated page template names. Properly merge in a parent theme's templates when dealing with cached values. Always look one level deep for WP_Theme->get_files() regardless of file type. see #20103. see #11216.