Double reply! So intense!<div><br></div><div><div class="gmail_quote">On Sat, Jul 23, 2011 at 5:57 PM, Daniel Fenn <span dir="ltr"><<a href="mailto:danielx386@gmail.com">danielx386@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div>Otto, are you saying that my breadcrum code that I put in is a doing it wrong all because I just given people no choice in what plugin they use?</div></blockquote><div><br></div><div>No, not at all. Breadcrumbs, for the most part, fall on the display side of things. You're displaying them on the site, in the front end. They're integrated into the page in a fairly major way. Navigation on the page is part of the display. I think that's perfectly suitable for a theme.</div>
<div><br></div><div>The fact that there are also plugins to implement it for themes that lack them, or for giving more advanced type features, doesn't mean it shouldn't be in a theme.</div><div><br></div></div><br>
<div class="gmail_quote">On Sat, Jul 23, 2011 at 7:37 PM, Darren Slatten <span dir="ltr"><<a href="mailto:darrenslatten@gmail.com">darrenslatten@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm actually kind of surprised at this suggestion. Doesn't this imply that Theme developers would have to research the plugin repo and determine which plugins' "toes" their Theme needs to avoid stepping on? This doesn't seem practical. Personally, when I see Themes checking for Plugins by name...it seems kind of hack-ish to me. I'm wondering if there's any way we could use a "feature sniffing" approach instead? Or possibly some type of "order of operations" convention.<br>
</blockquote><div><br></div><div>Generally when features have gotten rather popular, they get integrated into core. Tags, for example. Or custom headers and custom backgrounds. The comments_form function. Core implementations of these tend to be basic or generic, but with lots of hooks or callbacks. Then themes and or plugins can improve upon them and customize their personal implementation.</div>
<div><br></div><div>Obviously, for features that haven't made it into core, there's naturally some competition and conflicts. That's one reason core hasn't added them, in fact. Until there's a sort of defacto standard for things, it's unlikely to get core support... unless the core devs really, really want it to be standardized. Post formats could have been implemented by anybody at any time. Heck, it's easy. You could do it with less than a screenful of code. Nobody did. So a standard was imposed.</div>
<div><br></div><div>You obviously don't *have* to support a plugin, especially not an unpopular one. But if there is one that you want to add support for, maybe it's best to support that plugin specifically and tell your users "hey, my theme has built in support for this awesome plugin that I use on all my sites, maybe you should try it out!" or something.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It seems like a related issue here is the hook priority system. Maybe the current number system is too arbitrary; maybe we should segment the number line into specific uses or something.</blockquote>
<div><br></div><div>Might be worth making a page on the wiki to propose a standard for this sort of thing. Having just a community built guideline for some hook priorities would certainly not be a bad idea.<br><br></div>
<div>
-Otto</div></div></div>