<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
My advice is to code for anything and everything. Here's a very
general overview of my personal checklist:<br>
<br>
* Make sure you design for all HTML elements, making sure they look
good in posts, comments, and text widgets.<br>
<br>
* Try out all WordPress options (options pages in the admin) to make
sure your theme works with them.<br>
<br>
* Test all the default widgets.<br>
<br>
* Test all default post types and all the various options related to
posts.<br>
<br>
* Test all default taxonomies and make sure their terms are shown
somewhere.<br>
<br>
* Test all default quick tags and shortcodes (along with the various
shortcode arguments).<br>
<br>
* Add styles for all the WordPress CSS classes.<br>
<br>
If you do these things, you've covered most of the stuff you need to
cover.<br>
<br>
On 8/3/2011 6:32 PM, Chip Bennett wrote:
<blockquote
cite="mid:CAPdLKqeRbe-RP0A35twH=LOpYJFNsjBE9JBVByPk3J+jOkz2vA@mail.gmail.com"
type="cite">I apologize for any brevity...
<div><br>
</div>
<div>1) Themes must *incorporate* all of that content, but are
given as much latitude as possible for design intent. If the
content types are incorporated *somehow*, and implemented
properly, then that's usually sufficient.</div>
<div><br>
</div>
<div>2) Themes are required to include .wp-caption,
.wp-caption-text, and .gallery-caption in style.css. If those
classes are left empty, we consider that a design decision. As
long as captions are displayed, and are minimally aesthetic,
that is acceptable.</div>
<div><br>
</div>
<div>Themes must support threaded comments.</div>
<div><br>
</div>
<div>3) That's a case-by-case determination. Generally speaking,
*replacing* core code should not be done; if a core method
exists, it should be used. Can you provide an example?</div>
<div><br>
</div>
<div>4) What sort of verification assistance are you looking for?
Automated tests can only go so far, and we're just about as far
as we can get with Theme Check, Log Deprecated Notices,
Debogger, and Debug Bar.</div>
<div><br>
</div>
<div>5) Differentiating between "unacceptable" and "nice to have"
is the reason that the Guidelines are rigidly defined using
*required* versus *recommended*. (I admit that the Theme Unit
Tests could be more clear. For the most part, though: if it's
listed in the Theme Unit Tests, it's *required*.)</div>
<div><br>
</div>
<div>Chip<br>
<br>
<div class="gmail_quote">On Wed, Aug 3, 2011 at 5:22 PM, Mario
Peshev <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mario@peshev.net">mario@peshev.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hello reviewers,
<div><br>
I'm rereading the unit test and theme review pages on a
regular basis in order to remember all the requirements
for easier lookup on the new themes. I have some questions
that I would be happy to share and get a feedback if
possible. They are somehow mentioned in both documents but
I find no hundred percent case that covers or states
straight.</div>
<div><br>
</div>
<div>1) What are the mandatory fields visible for a post in
single.php and page.php? According to the test cases and
demo content I presume title, author, date, content, tags
and categories lists, as well as parent-child relations
and paging are required. However Chipp made a remark that
parent-child relations visible in the post are not
required, I don't find any requirements for categories and
tags to be a necessary addition to the single.php, as well
as the author and the date. What is the rule of thumb
here?</div>
<div><br>
</div>
<div>2) Themes usually support image captions and threaded
comments. Is a theme not approved if image captions are
with standard formatting or threaded comments are not
indented?</div>
<div><br>
</div>
<div>3) When theme author has replaced some code such as
pagination or commenting with a custom code, is it
necessary a bad practice or it depends on the final
application?</div>
<div><br>
</div>
<div>4) Are there any good plugins for verification beyond
the three listed in the guidelines?</div>
<div><br>
</div>
<div>It's hard for me for some clauses to differ the
"unacceptable" and "good to have" when I can't strictly
read some theme review points as rules. <br>
<br>
Best regards,<br clear="all">
<br>
Mario Peshev<br>
freelance software developer/trainer<br>
<a moz-do-not-send="true"
href="http://www.linkedin.com/in/mpeshev"
target="_blank">http://www.linkedin.com/in/mpeshev</a><br>
<a moz-do-not-send="true" href="http://peshev.net/blog"
target="_blank">http://peshev.net/blog</a><br>
<br>
</div>
<br>
_______________________________________________<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 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>
</blockquote>
</div>
<br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
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>
</body>
</html>