Hi – I think that’s a different problem to what I was discussing – however why are you worrying about creating a file in the theme directory. If you hook into template_redirect, or page_template you can pull in the template from anywhere you like – including your plugin code if you wanted to … Hope that helps.

http://stackoverflow.com/questions/4647604/wp-use-file-in-plugin-directory-as-custom-page-template/4975004#4975004

I put my comment hera because I think that the peter’s comment and the Lee’s reply can drive to a standard and good solution (at least for the “average” use).

I agree with Peter that plugins that declare custom post type could use template_redirect to privide their own tamplate (if the user/theme doesn’t provide one in the theme directory), it’s the “WP way to handle this” and for me could be acceptable.
But, and here comes the Lee’s ponit, could be useful only if we could provide not the whole page structure, but a smaller part, the “custom post content format only”, so to speak.
This way we could have the efficiency and granular finetuning of single-{custo-post}.php (if user/theme provide it) and a general “average” solution (provided by the plugin) that have some chance to look accaptable in many themes

Stefano

Less, as I’m thinking through the problem again it seems more and more like the solution is what Scott Kingsley Clark suggested and that is to allow themes to register their files and layout properties, i.e. what kind of sidebars and widget areas they provide, etc. and update the widget logic so it’s no longer site-wide but instead recognizes the complexity of a theme with many different potential layouts and the fact that a plugin may want to insert items into those layouts (actually it seems that your want your plugin user to assign settings to specify where in the theme your Director, Actor, Running Time and Review information would go, but at least with theme layout registration your plugin could know what is available.)

Plugins already register the fact that their posts are of a different type. The problem is that there’s no way for the plugin to register “To display this item use this layout” – without also having to understand the layout of the site’s overall theme.

So Lee, would this not address your concerns?

Not directly – although you’ve inadvertently covered the solution, in that the theme would invoke the plugin to render “fragments” of the display. What I’m after is that the per-post-type entries in the theme hierarchy should just represent page fragments – not the entire page. The articles @nacin linked to earlier cover the rationale, and the type of solution that would work perfectly.

http://darylkoop.com/2010/04/06/modular-themes-why/

And Peter, is registration of theme files and layout something you would disagree with?

Lee, is that what you are looking for?

It’s much more complicated than what I’m looking for 🙂 Your proposed solution needs mine to work – but adds a layer of (IMHO unnecessary) complexity on top.

Hi Peter,

As I previous stated on this thread I still don’t have a strong opinion of what will address Lee’s concerns but one thing you wrote stands out:

“Ideally, the popular themes would ship with support for the popular plugins allowing the kind of deep integration you desire out of the box.”

Ignoring the tiny handful of popular plugins where it just makes complete sense to provide support that statement just feels like it is going in the wrong direction. Let me rewrite that statement using an analogy to might bring the point home:

“Ideally, the popular homebuilders would build their homes with electrical outlet support for the popular appliances allowing the ability for you to use an appliance without hiring an electrician as you desire.”

My rewrite presumes there is no standard for electrical outlets which of course there is and since their is we all see that statement above as addressing the issue from the wrong direction. My point is I think you are placing the responsibility for solving the problem on the wrong shoulders.

It seems to me that it would result in far more plugins being compatible with far more themes if we could codify a standard way for plugins to support a theme because the theme calls functions that are in future core that provide the support. That would be the WordPress plugin and theme equivalent of the standardized electrical plug and outlet.

Less, as I’m thinking through the problem again it seems more and more like the solution is what Scott Kingsley Clark suggested and that is to allow themes to register their files and layout properties, i.e. what kind of sidebars and widget areas they provide, etc. and update the widget logic so it’s no longer site-wide but instead recognizes the complexity of a theme with many different potential layouts and the fact that a plugin may want to insert items into those layouts (actually it seems that your want your plugin user to assign settings to specify where in the theme your Director, Actor, Running Time and Review information would go, but at least with theme layout registration your plugin could know what is available.)

So Lee, would this not address your concerns?

And Peter, is registration of theme files and layout something you would disagree with?

Lee, is that what you are looking for?

The problem is not necessarily the lack of support in core for plugins to get deep and dirty into theming but actually the lack of support in popular themes for popular plugins.

Ideally, the popular themes would ship with support for the popular plugins allowing the kind of deep integration you desire out of the box.

The rest of the time I think the end-user is better served with having to do some work to customise the theme (based on examples you provide) that for you to expect to be able to insert something into the template hierarchy and it to just work.

If template_redirect isn’t enough because you don’t know how the theme is structured then chucking extra templates from your plugin into the hierarchy isn’t going to work either.

The alternative is to do what BuddyPress does and ship with an example parent theme which makes use of the plugin which the end-user can then customise.

All the support for doing that is already in core.

Even if we allowed for modular themes in core, it’s not going to make it any easier on you for a long time

Even more reason to start now, and embed the culture before we *really*, *really* need it 🙂

Keep in mind right now it can be a challenge even to expect themes to have wp_head and wp_footer

Presumably this would be an easy-ish thing to check at the Theme repository, and to present info showing the user what functionality support they could expect from the theme, e.g.

() Support for plugins
() Support for post thumbnails
() Support for custom post types

This should be a fairly easy set of checks (Does it call wp_head & wp_footer, Does it call any of the _post_thumbnail functions, Does it call get_item_content [Or whatever the new function would be]).

This obviously wouldn’t help for hand-commissioned themes, or commercial themes – but I think the commercial houses would get it right anyway if it was best practice, and at least we’d have a case to say that the user’s theme didn’t support it. Most likely in the short term we’d have to support some other way (filter the_content), but it would move us in the right direction.

And if the theme did, it could also just as easily support some hooks, template parts, or template tags that enable you to do exactly what you want now.

Absolutely, but every theme has their hooks and filters called differently, so we can’t support them all 🙂

I can definitely related to “not feeling heard at times.” Here’s my latest example on post-to-post relationships where the core team’s position seemed to be “it’s an edge case” (and I’m hoping you’d disagree with that assessment as I do):

http://core.trac.wordpress.org/ticket/14513

I like the conversation here, and I’ve been following it for two days. I love the innovation in the space and I think we need more of it. I’m just not convinced we’ve reached the point where it makes sense for core to act on that yet.

Even if we allowed for modular themes in core, it’s not going to make it any easier on you for a long time, because there’s limited guarantee that the theme supports it. Keep in mind right now it can be a challenge even to expect themes to have wp_head and wp_footer. And if the theme did, it could also just as easily support some hooks, template parts, or template tags that enable you to do exactly what you want now.

I think you know me better than to think I was taking this personally. 🙂