[wp-trac] [WordPress Trac] #20509: Theme idea - generic.php
WordPress Trac
wp-trac at lists.automattic.com
Wed Apr 25 14:04:38 UTC 2012
#20509: Theme idea - generic.php
--------------------------------------+------------------------------
Reporter: johnjamesjacoby | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Themes | Version:
Severity: normal | Resolution:
Keywords: needs-patch dev-feedback |
--------------------------------------+------------------------------
Comment (by johnbillion):
Replying to [comment:27 scribu]:
> Speaking of which, `register_generic_plugin_file()` seems kind of wrong.
The whole point is that the plugin can't know what a `generic.php`
template should look like.
I think you're getting confused here. Currently, a plugin such as
BuddyPress can contain its own template file for rendering output.
Usually, this is going to be a file containing `get_header()` and
`get_footer()` and some content in between.
This doesn't always work with themes that need to markup in the individual
template files around the content area (as you said, "The whole point is
that the plugin can't know what a `generic.php` template should look
like."), so the idea is that a theme can include a template file called
`generic.php` which, most of the time, is going to be pretty similar to
`page.php` or `index.php`, but it'll have a call to
`do_action('generic_content')` in place of the loop.
This `generic.php` file will be at the top of the template hierarchy for
generic requests, but plugins will be able to register their bundled
generic template file as a fallback for themes which don't have a
`generic.php` template file. This means that newer themes which include a
`generic.php` template get more control over the layout of a generic
request, and older themes without the template file will fall back to the
current system where plugins load their own template file.
> BuddyPress could still do something like this:
>
> {{{
> add_filter( 'template_include', function ( $path )
> {
> if ( is_generic_request() && 'index.php' == basename( $path ) )
> {
> // Fall back to plugin.php if there's no generic.php
> return plugin_dir_path( __FILE__ ) . '/plugin.php';
> }
>
> return $path;
> }
> }}}
Correct, but that code should be in core instead of in each plugin, and
the plugin should just be able to register its `generic.php` file to be
used in this situation.
> {{{
> // From Plugin
> add_action( 'generic_content', function() {
> load_template( plugin_dir_path( __FILE__ ) . '/my-template.php' );
> } );
> }}}
>
> In the second case, `generic.php` encloses `my-template.php`, making my-
template.php a template part, rather than a whole template.
It's entirely down to the plugin what it does inside the `generic_content`
hook. It can include other tempalte parts or output stuff directly. That's
not what this ticket is addressing.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20509#comment:33>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list