<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body wsmode="reply" text="#000000" bgcolor="#FFFFFF">
Jasper, I don't think that you can compare theme dev and plugin dev
- a plugin can alter one tiny part of a theme or WP functionality,
whereas a theme must comply with a wide range of functional and
aesthetic restrictions.<br>
<br>
That being said, the guidelines do tend to descend in to an almost
legalese style of wording that can verge on the opaque for newer
reviewers, not to mention there are items in there tagged 'draft' -
something I've just noticed and which apparently take away their
'required' status.<br>
<br>
When it comes down to it the guidelines are there to shepherd
non-admins in filtering out the majority of the overtly crap themes
that are way off base, so that the admins can do their final review.
The guidelines are not meant to be all-powerful, and theme authors
can go to the list if they feel they've been dudded by their
reviewer.<br>
<br>
So - there probably needs to be a higher emphasis placed on the
ephemeral nature of said guidelines, and a greater underlining of
the function of the list.<br>
<br>
IMHO :)<br>
<br>
Paul Appleyard<br>
<br>
<div class="moz-cite-prefix">On 26/06/2013 7:31 PM, Jasper Kips
wrote:<br>
</div>
<blockquote
cite="mid:435AF781-AFCC-4392-9D59-62FF793A34AB@planetkips.nl"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Speaking as a developer, I wholeheartedly agree with Philip.
Developers should be given as much leeway as feasible.
<div><br>
</div>
<div>Having said that, there are some points I would like to point
out as an administrator of websites.</div>
<div>I expect themes to have one major functionality; to display
the content in a pleasing and correct way. Most certainly I do
not expect themes to incorporate functionality that will break
the displaying of content, when switching to another theme. Case
in point, I do not expect a theme to use its own shortcodes,
switching themes then becomes a nightmare, instead of a breeze.</div>
<div>Even when it is opt-in, for the owner (not necessarily the
administrator) of a site it should be easy to change themes,
without having to worry about extra things. Themes that allow
inserting of scripts, have built-in widgets, just fall short of
that standard. Remember, users will use functionalitiy if it is
there.</div>
<div><br>
</div>
<div>Just to be clear, by breaking I mean that the main content,
that what is returned by the_content, is not shown as intended,
hence the no no on my administrator side, of shortcodes.</div>
<div><br>
</div>
<div>Furthermore, I expect a certain level of quality of the theme
code. Developers are human, and they do make mistakes. The main
engine, PHP, changes, removes, adds, changes the way functions
work. Etcetera. All these things require that troubleshooting
should be as easy as possible. This is not only in the interest
of the user, but also of the theme developer. I remove themes
themes which I can't easily troubleshoot. Another missed
opportunity for the developer. </div>
<div>The lack of requirements on theme documentation is disturbing
in my view.</div>
<div><br>
</div>
<div>I do not think the current methodology is wrong, actually it
is quite good, and in ways better than the methodology used for
plugin reviewing, and in ways better than most QA processes I
encounter in my job. I regularly encounter problems with
plugins, but seldom with themes, that should actually say
something about the quality of themes in the WordPress
repository.</div>
<div><br>
</div>
<div>The problem lies in the implementation. Reviewers are human,
and have their own ideas by certain standards. Following the
discussion, I bet there are themes that reviewed by reviewer A,
and pass, while if they would have been reviewed by reviewer B
they would fail. This is no problem in itself, but it reveals
some underlying problems in the implementation of the
guidelines. And, more acute, the way the guidelines are
explained. To say something in a theme is plugin territory, and
thereby rejecting the theme, is plain stupid. One should, at the
very least, explain WHY it is plugin territory. And why, given
that the guidelines put emphasis on the display functionality,
but don't exclude other functionalities, it is a good reason not
use theme specific functionality that is considered plugin
territory.</div>
<div><br>
</div>
<div>There is a great risk that the guidelines will be seen in a
legalistic way. This is, in my opinion, somewhat overshooting
the idea of the guidelines. Note that the reviewers, and most of
the theme developers, are volunteers, doing it besides their
regular job. They should be encouraged, not decouraged, by the
review process, the guidelines and the way their theme, or
review, is appreciated. </div>
<div><br>
</div>
<div>So, long story short, Philip has a good point, but I feel the
process should be looked at, not the methodology.</div>
<div>Just my penny.<br>
<div>
Sincerely,
<div><br>
</div>
<div>Jasper Kips<br>
<br>
</div>
</div>
<br>
<div>
<div>Op 26 jun. 2013, om 07:43 heeft Emil Uzelac <<a
moz-do-not-send="true" href="mailto:emil@uzelac.me">emil@uzelac.me</a>>
het volgende geschreven:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">here* is the thing, not hear, sorry my phone
is acting weird! </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jun 26, 2013 at 12:41 AM,
Emil Uzelac <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:emil@uzelac.me"
target="_blank">emil@uzelac.me</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">So hear is the thing. With the
blessings of others, I am thinking that
<div>Themes should not be "crucified" the way we're
doing this now. As</div>
<div>I was previously expressing, not all things are
the "plugin territory".</div>
<div><br>
</div>
<div>My personal methodology is, if nothing breaks,
or interferes with the</div>
<div>core and it's useful to users, let it be, as
simple as that.</div>
<div><br>
</div>
<div>Restricting and eliminating rather harmful
stuff, will project very</div>
<div>negatively to Theme authors.</div>
<div><br>
</div>
<div>I don't want to step on anyone's toe here and
this is what I believe</div>
<div>is right, or at least it should be :)</div>
<span class="HOEnZb"><font color="#888888">
<div>
<br>
</div>
<div>Emil </div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jun 26, 2013 at
12:35 AM, Philip M. Hofer (Frumph) <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:philip@frumph.net"
target="_blank">philip@frumph.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">i.e. don't even
give it a second glance, that's a feature of
the theme<br>
<br>
<br>
<br>
-----Original Message----- From: Philip M.
Hofer (Frumph)<br>
Sent: Tuesday, June 25, 2013 10:35 PM
<div><br>
To: <a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
Subject: Re: [theme-reviewers] Formal
Request for Change of Methodology.<br>
<br>
There's no question about it, as long as
it passes the theme unit test with<br>
default settings it would pass right?<br>
<br>
<br>
<br>
-----Original Message----- From: Daniel<br>
Sent: Tuesday, June 25, 2013 10:31 PM<br>
To: <a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
Subject: Re: [theme-reviewers] Formal
Request for Change of Methodology.<br>
<br>
What about themes like my one where you
can remove the header and<br>
footer because your using a bridge like
wp-united? Where do those sort<br>
of things come into play?<br>
<br>
<br>
<br>
<br>
On Wed, Jun 26, 2013 at 3:29 PM, Philip M.
Hofer (Frumph)<br>
<<a moz-do-not-send="true"
href="mailto:philip@frumph.net"
target="_blank">philip@frumph.net</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
These are features of a theme, the
shortcodes and more are 'features' of
the<br>
theme.<br>
<br>
If they use the theme and use those
shortcodes, then that is the theme that<br>
is using it, to require shortcodes to be
cross compatible and in a plugin is<br>
simply ridiculous.<br>
<br>
The end user, while picking a theme will
choose a theme that has features<br>
that they want. When they choose
another theme that doesn't have those<br>
previous themes features they miss out,
it's not a question of requiring a<br>
compatibility.<br>
<br>
This also goes with themes that have
specialty programming in the way of<br>
custom post types and the like. - again
the data is not lost, it's still<br>
there, just switching to a different
theme will not grant access to it.<br>
<br>
The age of feature rich themes and
innovation should be promoted not<br>
stifled.<br>
<br>
<br>
-----Original Message----- From: Harish<br>
Sent: Tuesday, June 25, 2013 10:24 PM<br>
To: <a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
Subject: Re: [theme-reviewers] Formal
Request for Change of Methodology.<br>
<br>
<br>
Good suggestions by Philip (Frumph)
however I have to disagree with:<br>
<br>
" the idea that a theme must adhere and
be cross compatible with other<br>
themes in features is a nuance that is
unnecessary to worry about."<br>
<br>
Themes do not have to be cross
compatible with other themes, but they
should<br>
not be the cause of the end user losing
data when changing their themes.<br>
<br>
2 of the most common issues are
shortcodes and custom meta boxes where
the<br>
key has "_" in front to hide it from
the custom meta fields section.<br>
<br>
If theme developers are worried of
making things easier for the end user,<br>
most of these things should not have
been in the theme in the first place.<br>
<br>
<br>
<br>
Regards,<br>
Harish<br>
<br>
<br>
-----Original Message-----<br>
From: theme-reviewers [mailto:<a
moz-do-not-send="true"
href="mailto:theme-reviewers-bounces@lists.wordpress.org"
target="_blank">theme-reviewers-bounces@lists.wordpress.org</a>]<br>
On Behalf Of Philip M. Hofer (Frumph)<br>
Sent: Wed 26 June 13 10:41 AM<br>
To: <a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
Subject: [theme-reviewers] Formal
Request for Change of Methodology.<br>
<br>
1) Remove all requirements and
recommendations, change it all to 'best<br>
practices', do not remove anything in
the codex just yet.<br>
<br>
2) Theme review process.<br>
* Theme reviewers tag a theme for
review. / It already passed the upload<br>
checker<br>
* Check theme with the other
plugin(s)[1] available for development,
check<br>
it for notices, warnings, fatals and
deprecation messages, Pass/Fail<br>
* Check theme with theme unit test.
Pass/Fail<br>
* Review the tags, website links, theme
name. Pass/Fail<br>
<br>
It's done, it's reviewed, it's over, if
it passed all of those, flag it as<br>
passing review and live.<br>
<br>
3) Anything else missing on the above
list that is a MUST should be added to<br>
the list but only if it's a MUST, and
can't go live no exception.<br>
<br>
[1] Make the plugins work for the theme
review team; add common security<br>
problems, etc.<br>
<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
This is it, this is all that is needed.
Everything else is icing on the<br>
cake for best practices.<br>
<br>
<br>
Themes are the 'meat and potatoes' of
WordPress, the idea that a theme must<br>
adhere and be cross compatible with
other themes in features is a nuance<br>
that is unnecessary to worry about.
Plugins are made to enhance themes;<br>
if a plugin doesn't work with a theme
the community WILL contact the author;<br>
<br>
they always do. As long as the theme
is up to date with core coding which<br>
all of the tools at our disposal make
you aware of - of which even the<br>
messages from core will also state
things it is unnecessary to do anything<br>
otherwise.<br>
<br>
// not sure about<br>
Not sure what Nacin wrote in entirety on
the Make site, but having the<br>
themes that are live and pass the upload
process and immediately go live<br>
again would be a boon; that basically
makes it like the theme developer has<br>
svn access, without having svn access.<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</blockquote>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a>
<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org"
target="_blank">theme-reviewers@lists.wordpress.org</a><br>
<a moz-do-not-send="true"
href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers"
target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a moz-do-not-send="true"
href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
theme-reviewers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a>
<a class="moz-txt-link-freetext" href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a>
</pre>
</blockquote>
<br>
</body>
</html>