[wp-trac] [WordPress Trac] #19063: Custom post_types and get_template_part

[WordPress Trac]

#19063: Custom post_types and get_template_part
-------------------------+------------------------------
 Reporter:  impleri      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Template     |     Version:
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by impleri):

 If `post_type` is false, the `if(!in_array($post_type, $default_types))`
 will return false, thereby ignoring the additional template possibilities
 (after all, the interest is for custom post_types -- which will have
 `post_type` set).

 For the array, this should be changed to retrieve the post_type for the
 actual post (easy enough) which cannot be an array (at least according to
 the DB design). Would using `get_post_type()` fix this? (posting new patch
 with this)

 I disagree on using something like `locate_template()` for a few reasons.
 First, it comes too late in the template loading process. Adjusting
 `get_template_part()` as I propose is essentially the same as adjusting
 `locate_template()` except in one crucial point, which is my second
 reason: it would add additional filtering and process time because
 `locate_template()` is called for every template piece. Using something
 like `get_template_part()` follows what I think are the goals in the
 template system: modularity. Using `locate_template()`, while it does this
 as well, it adds process time without benefit. Thirdly,
 `get_template_part()` appears to be the logical choice because that is
 where possible template names are decided. Pushing this to
 `locate_template()` would be obfuscating its function. The options as I
 see them are to use `get_template_part()` or to create a new function
 similar to `get_header()` (e.g. `get_main_content()` or something) though
 even then `get_template_part()` would need to be modified to allow for a
 base plugin-defined template (either by postponing `load_template()` until
 after a filter check -- like I have done -- or returning a template path
 to a `get_main_content()` function which then does `load_template()` after
 a filter check).

 Since this is meant to enable custom post_types to display properly, a URL
 like `http://mysite.com/records/my-own-musical-beast/` which is used by a
 music record/album custom post_type might not display anything because the
 content is a listing of songs generated from the DB. Currently, I would
 need to filter `the_content` in order to display this, filter on
 `template_include` or `single_template` to redirect to a template which
 will show the correct data. In the first case, I am hardcoding the
 template from my plugin (not good). In the latter two cases, I am
 overriding the actual template (e.g. what if a template puts the sidebar
 on the left but does not do so in the template's header.php like
 TwentyEleven does in footer.php?). By using `get_template_part()` or
 something similar, it is easier for my record file to show in a randomly-
 given theme without forcing a particular template layout. For example, I'm
 updating the extinct Now Reading plugins to use custom post_types. A book
 (e.g. http://beta.impleri.net/library/product/the-girl-with-the-dragon-
 tattoo/ ) needs to be able to have multiple authors, an image, a link to
 Amazon page, etc. These do not show up on the template pages because,
 obviously, they are custom data which need to be displayed. What I'm doing
 right now is using the `single_template` filter, checking if the custom
 `single-ml_product.php` file was found by `locate_template()` and, if not,
 redirecting to the `single-ml_product.php` template file in my plugin
 directory. This is not a good solution because I've had to copy the entire
 page layout from TwentyEleven (I'll attach this file as well) which may
 not work with other templates. I could have filtered `the_content` but
 then I am requiring a hardcoded style across which makes it more difficult
 to users to have template-specific designs. If I could have filtered
 through `get_template_part()`, users would only have to worry about minor
 tweaks for a template which they could put in their template folder
 without needing to recreate a loop page -- much like TwentyEleven has made
 it possible with its `content-single.php` file. Thus far, that seems to be
 simplest solution which is most extensible and most logical from what I
 can tell.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19063#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software