[wp-trac] [WordPress Trac] #13265: Filter results of get_page_templates()

WordPress Trac noreply at wordpress.org
Sat Mar 1 20:10:25 UTC 2014


#13265: Filter results of get_page_templates()
-------------------------+-------------------------
 Reporter:  nathanrice   |       Owner:  nathanrice
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  3.9
Component:  Themes       |     Version:  3.0
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  template
-------------------------+-------------------------

Comment (by MikeSchinkel):

 Replying to [comment:50 nacin]:
 > Something feels wrong about it. Page templates are fairly rigid, are
 only available for pages, and are intrinsic to the theme. For nearly all
 use cases, a plugin can't just call get_header() and get_footer() and pray
 the markup will work. It makes sense that a child theme or a parent theme
 needs to register them, at least in their current form. That's more of an
 indictment of themes, yes, but my point is templates in plugins just don't
 work well.

 Ok, thanks for taking the effort to clarify and I do indeed see the
 concern.  OTOH let me give you a use-case where adding page templates
 could be beneficial and yet would not violate your concerns?

 Consider a soft drink company with many brands that has a large WordPress
 website for a company-wide campaign where they allow a representative from
 each of their brands to publish pages on this shared website. Of course
 each brand has it's own design standards and each brand hires their own
 agency to build out their brand's WordPress page templates. The IT group
 for this company has set up the server so that each brand can update their
 brand's folder but only their folder (after an exhaustive code review, of
 course.) The brand folders are located like so:

 - `/wp-content/themes/soft-drinks-r-us/brands/{brand}/`

 Thus either the theme or ideally a must-use plugin would need to be able
 to add the pages templates for the brand associated with the current
 logged-in user. In the case of a plugin it would just be providing the
 logic about where to find the page templates found in the theme but even
 if done in the theme's functions files it would still need to be able to
 add files using the new `'page_templates'` filter.

 One way to support this use-case yet still disallow plugins adding their
 own templates would be to simply disallow any new absolute paths but do
 allow any new relative paths.

 However...

 > So should we encourage what is a certain level of "slop"?

 While the usage you describe would definitely be slop I could envision
 valid use-cases for having a plugin add a page template of it's own such
 as when the plugin needs to control the formatting. Image a promotional
 coupon plugin that allowed the user to publish a coupon with a URL path of
 `/christmas-2014-promo/` or similar. Maybe the plugin developer wants the
 coupon to be formatted to look like an award certificate; in that case the
 plugin would rightly need to be in complete control of the formatting, and
 such a plugin would be a lightweight way for a motivated DIYer to add
 specialty coupons to their website.

 Another use-case could be for a poorly-funded government agency that has a
 [[http://federal-government.apievangelist.com/2013/12/20/federal-agencies-
 miss-the-mark-on-open-data-mandate--again/ mandate to provide an API for
 their data]. A plugin could provide one of their non-technical staffers a
 page template that would format the values they typed into meta fields to
 be output as a JSON file, maybe at an URL path of `/api/crime-
 stats/2013/`.

 Of course I'm stretching these use-cases a bit to provide examples that
 people might want to achieve, but limiting them means they definitely will
 not be any happy accidents for use-cases that require adding page
 templates. And it's really hard to know what good things people might
 dream up.

 Conversely I'd ask if the potential downside of allowing it is likely to
 result in significant negative behavior. First off it's something people
 will have to learn how to do, it's not a case of them doing by accident.
 And most people building plugins want people to use their plugin but if
 they create a bad UX then fewer people will use it so it would seem to
 have a built-in disincentive to use badly. And disallowing it removes the
 potential for positive serendipity so why not allow and just document in
 the hook that it's a bad idea to use it to add page templates that expect
 their layout to work in an existing theme?

 But even so, please at least allow adding page templates with relative
 paths, i.e. within deeper subdirectories.

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


More information about the wp-trac mailing list