[theme-reviewers] Thesis WP Theme

[Otto]

Double reply! So intense!

On Sat, Jul 23, 2011 at 5:57 PM, Daniel Fenn <danielx386 at gmail.com> wrote:

> 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?
>

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.

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.


On Sat, Jul 23, 2011 at 7:37 PM, Darren Slatten <darrenslatten at gmail.com>wrote:
>
> 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.
>

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.

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.

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.


> 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.


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.

-Otto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110723/6214ba2f/attachment-0001.htm>