[wp-trac] [WordPress Trac] #16264: Add function get_pages_by_template()

[WordPress Trac]

#16264: Add function get_pages_by_template()
---------------------------------+----------------------
 Reporter:  mikeschinkel         |       Owner:
     Type:  feature request      |      Status:  closed
 Priority:  normal               |   Milestone:
Component:  Posts, Post Types    |     Version:  3.1
 Severity:  normal               |  Resolution:  wontfix
 Keywords:  needs-refresh close  |     Focuses:
---------------------------------+----------------------

Comment (by MikeSchinkel):

 Replying to [comment:18 johnbillion]:
 > It's fine to keep narrow use case functions such as this within themes
 or plugins.

 I did not get a chance to respond before you closed it.

 Replying to [comment:17 swissspidy]:
 > Though I don't really see a reason to have this function when it's so
 easy to get the information anyway using `WP_Query`.

 Once again I will ask do we really not want to encapsulation the ''how''
 to get this information into the WordPress API vs. requiring someone who
 wants to do this to hardcode `'_wp_page_template'` and a meta query?  Not
 having them hardcode this would make the implementations easier to change
 later if needed.

 As to ''"I don't see people doing this"'' let me ask, do you see people
 writing code that hardcodes logic to specific slugs, or worse, to specific
 post IDs?   I've seen lots of site code and also lots of articles online
 showing people how to do that.

 - https://wordpress.org/support/topic/showing-one-pages-content-on-
 another-page
 - http://diythemes.com/thesis/rtfm/how-to-hide-remove-hello-bar/
 - http://spicemailer.com/wordpress/add-widget-pages-posts-wordpress/
 - http://stackoverflow.com/a/5318869/102699

 For example, someone writes a `WP_Query` call that hardcodes the page ID
 for a pricing page into a check for whether to modify a query based in
 `'pre_get_posts'`.  With this function they could instead hardcode the
 page template filename and modify the query when that matched.

 Tying to page templates instead of slugs and post IDS is a more for robust
 solution.  And I would expect the reason most people who tie to slugs and
 post IDs do so because it does not occur to them that there is another
 way. If this function where built-in and and blogs posts about it existed,
 it might occur to them to do it more robustly.

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