[theme-reviewers] Removing core features

[Chip Bennett]

The sole responsibility of a Theme is to present user content. Widget
placement? That's front-end. Navigation menu? That's front-end. And menus
are persistent from Theme to Theme. That's why Themes must declare a
theme_location for each navigation menu, so that the user can display the
*user-generated nav menu content*.

I disagree completely that Themes have "evolved" away from being the
presentation layer. Themes *can* do far more than that, but *shouldn't*.
Because Plugins and Themes use the same API to implement much of their
work, the possibility exists for a considerable amount of crossover between
what a Theme can do and what a Plugin can do. But just because a Theme or
Plugin *can* do something, doesn't mean that it *should*.

I continue to answer enough end-user support questions for which the answer
is "your Theme is interfering with your Plugin" (or otherwise
_doing_it_wrong()) to stand firm in my belief that facilitating the
blurring of the line between presentation and functionality would in any
way help end users.


On Wed, May 22, 2013 at 9:12 AM, Bryan Hadaway <bhadaway at gmail.com> wrote:

> @Chip - I've never personally agreed with this logic actually, as it
> contradicts itself.
>
> There are lots of things that break when switching themes (naturally),
> menus and widgets are the best and most obvious argument. Users are just as
> oblivious to that, but it's allowed. There's no consistency requirements
> here. For example, one theme could have specialized footer menus and
> widgets. When a user switches to a different theme those are "lost" or
> "unhooked", unregistered.
>
> This isn't any more dramatic than RSS feed behavior changing. In fact, I
> could argue that people are more bewildered by menus/widgets changing than
> they would meta/RSS related tweaks.
>
> So, we're talking function vs visual. Well, a theme hasn't been just
> visual for a long time, there's all sorts of functions going on and special
> things you can add that aren't basic or default and guideline approved that
> can dramatically differ one theme from another.
>
> Themes have evolved past being themes a long time ago, especially with
> premium themes. I think many users/customers have come to expect that a
> theme is really a full website experience with all sorts of bells and
> whistles and features and that WordPress is just the underbelly CMS to
> those means.
>
> This rule definitely feels dated. I think it's more convenient for the
> end-user to have an all-in-one experience, not have to do too many add-on
> configurations.
>
> In the end, there's hardly any difference for the end-user between
> guideline-meeting themes and specialty themes. I think they're just as
> unwitting either way, which makes the rule moot. In the end, a user's
> understanding of a theme is only as good as the effort put in by its author
> to educate users on the themes purpose and features.
>
> In fact, it would only be irresponsible to lead users to the expectation
> that all themes (function wise) are alike, because that's not the case at
> all. They should learn that themes are uniques and they should do their
> research before choosing or switching to a new theme. I think the new
> built-in theme preview helps a lot,
>
> I think this rule sounds good on paper, but doesn't live up to the
> real-world use and expectations of WordPress themes and their respective
> users in 2013.
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130522/396facdf/attachment.html>