[theme-reviewers] Theme Options and Functions
kikizas at gmail.com
Wed Oct 20 22:33:15 UTC 2010
On Wed, Oct 20, 2010 at 8:24 PM, Chip Bennett <chip at chipbennett.net> wrote:
> On Wed, Oct 20, 2010 at 12:08 PM, Demetris Kikizas <kikizas at gmail.com>
>> On Wed, Oct 20, 2010 at 7:44 PM, Jon Cave <jon at lionsgoroar.co.uk> wrote:
>> > On Wed, Oct 20, 2010 at 5:38 PM, Demetris Kikizas <kikizas at gmail.com>
>> > wrote:
>> >> For example, why serialization of options should be even a
>> >> recommendation?
>> > It's not, that was just suggested in Chip's first email and, from what
>> > I can see, it was decided not to be included in the recommendations.
>> > Only prefixing functions/options was agreed upon.
>> It may not become a recommendation, but it shows the way of thinking
>> that brought us to this point.
>> This way of thinking is perverse.
> Or, it is merely the Review Team bringing up a potential issue, and
> discussing whether it is worth addressing, and if so, how it should be
Making browsing of database tables difficult for someone who activates
dozens of new themes per week is not an indication of a potential
issue. Not the way I understand what an issue is in a WordPress
I am not saying this because I am not sympathetic. On the contrary:
I look at themes and plugins myself all the time. I have all plugins
and themes from WordPress Extend on my desktop and on my laptom (local
checkouts). Sometimes I activate 100 or 150 plugins at once to see
how latest trunk behaves, and if there are any obvious breakages. So,
I understand what you say. But that’s an edge case. Few people use WP
>> Instead of looking for solutions to practical problems, it comes up
>> with solutions for problems that do not exist.
>> Recommendations and requirements for themes should only be there if
>> they solve practical problems.
> Given that you have yet to review any Themes, how would you know what
> "practical problems" exist?
> You see, one of the "practical problems" with which we as a diverse Review
> Team must deal is the fairness and objectiveness of our reviews. If one of
> us finds that we are making similar comments on several Themes, regarding
> issues that are either not addressed in the Guidelines, or else are not
> addressed clearly enough, we bring such issues up to the Team as a whole, to
> determine how we can ensure that we are all handling such issues fairly and
> But since you've not contributed any Theme reviews, you wouldn't really have
> any idea of the kinds of issues that we see come up frequently in submitted
So, you are saying that only members of this review team know about
the issues commonly found in WP themes?
Are you serious?
>> For example:
>> Never hardcode the URI of your theme’s stylesheet. It is not allowed
>> for this or that reason.
>> wp_head() is strictly required for this and that reason.
> Both of which are examples for which valid reasons exist for their inclusion
> in the Guidelines.
>> The way I see it, a requirement should only be added when we are
>> confronted with a real, practical problem and, after we explore all
>> possible solutions, we conclude that the only way to solve the problem
>> is by a formal, strict requirement.
> So, what are the specific "strict requirements" with which you disagree,
> and why?
If you people are willing to listen, I am willing to comment in detail
on every requirement and recommendation currently listed on the Codex
But I think others, better qualified than me, tried before and failed.
Like Otto in this thread:
I agree with everything Otto says there.
My general objection, in short, is to what I see as a maximalistic
approach to setting requirements. You can’t take everything you would
wish your dream theme to have and turn it into a strict requirement.
Requirements should be there to ensure that themes work with core,
work with plugins, and do not harm users. Nothing more.
http://op111.net/80 ‹ A proposal for making WordPress themes and
plugins easier to translate
More information about the theme-reviewers