[theme-reviewers] Theme Review for blog and business (CMS) themes

[Chip Bennett]

Comments in-line (sorry, Cais!)

On Mon, Mar 19, 2012 at 11:59 AM, Mario Peshev <mario at peshev.net> wrote:

> Listing several comments from trac reviews and the theme review page:
>
> REQUIRED: Theme options must be added to the database via a single options
> array, rather than separately - I know that it is a good-to-have, but I
> wouldn't personally reject a theme for that reason.
>

As far as I'm concerned (speaking personally) this one is a no-brainer.
This is just a matter of good stewardship of users' resources. NOT doing it
this way, at this point, is little more than a sign of laziness.

>
> Recommended (highly) is the support of all add_theme_support features.
> Well, for some themes this might be obsolete. Let's take super minimalist -
> clean classic themes (no post thumbnails) or specifically business themes
> or anything else (no custom backgrounds, headers).
>

"Recommended" is only that: recommended. A Theme would never fail a review
for not implementing a recommended feature. To go even further: reviewers
should not even be *mentioning* a recommended feature in a review summary.
(Now, a recommended *implementation* is another matter. I think it is good
practice for reviewers to suggest best-practice implementations of certain
features.)

>
> Our theme test data advices us, as authors and/or reviewers, to test the
> site with very long titles, headings, anything that could break the layout.
> This is normally good-to-have and very hard-to-achieve. This leads to
> limited design creativity actions as reviewers keep declining theme
> submissions by testing with a blog title with 150 characters or the
> super-large-title-test-post that is in the test data.
>

Let's start with the overarching philosophy that drives these Theme Unit
Tests: these are publicly distributed Themes, used on sites over which the
Theme developer has no control of content. Thus, it is prudent to ensure
that Themes handle reasonable edge cases. As for the specifics: do you
suggest less-extreme edge cases for each of these tests?

>
> wp_link_pages and pagination hooks might not be used as well. I think that
> the pagination in WordPress with next/prev only is not useful and normally
> use custom or third-party solutions so having this as required doesn't make
> sense to me. Especially for a corporate/business site that doesn't even
> need news (pages only). SInce I've bought around 80 themes from ThemeForest
> for clients and friends and so, a percentage of them doesn't use news or
> blog.
>

A non-blog use of any Theme in the repository *already* won't show
previous/next links on Pages. I'm not sure what the issue is here. Again:
just because the developer envisions a Theme only to be used for a site
without a blog doesn't mean that, with a few almost-trivial changes, an end
user couldn't also use that same Theme for a site that does have a blog.

As for third-party implementations of navigation links: they should be
hooking into core functions. I could be wrong, but I'm pretty sure core
functions already cover just about every navigation case imaginable.

>
> The required CSS classes or HTML tag stylings are a common reason to
> reject a theme as well. .wp-caption, .wp-caption-text, .gallery-caption,
> .sticky, .bypostauthor are classes I add specifically for a theme before
> submission, never used in my demos or sites otherwise.
>

Even sites without a blog could conceivably still attach images to posts.
The only one of those CSS classes that is exclusively blog-related is
.sticky - and bear in mind: we don't actually require Theme developers to
*style* those classes. Rather, we just require that they *include* them, so
that they've at least *considered* whether their design should incorporate
a particular style for sticky posts, and/or for author comments.

>
> Some themes are rejected due to: 'this is not described in readme.txt'. We
> should probably define a template to be filled for every theme, for a
> standardization. In addition to that people won't google the markup styling
> for readme files, common thing for themes and plugins on WPORG.
>

The only things that should be *required* to be described in the Theme
documentation are limitations, design constraints, design assumptions, or
unique setup instructions for the Theme. And yes: if they apply, they DO
need to be documented, so that the end user can know HOW to use the Theme
as it's intended to be used.

>
> There are other remarks as well, but these are a few I just found out.
>

I'm not seeing anything here that would need any significant changes.

One thing I would like to see is for reviews to get more consistent in the
manner and content of information presented. I think it would help Theme
developers the most if the reviews simply listed the things that are
REQUIRED. I cringe a bit when I see reviews that include a long list of
RECOMMENDED/INFO observations that have no bearing on the ultimate approval
of the Theme. Perhaps the process would be easier for Theme developers if
the review summaries were a bit more condensed, with emphasis on what is
REQUIRED in order for the Theme to be approved. (I think that would
eliminate some of the points you listed above.)

Chip



>
>
> A quick offtopic, this is not working:
> http://themes.trac.wordpress.org/report/14 , outputs:
>
> *Trac detected an internal error:*
>
> KeyError: 'numrows'
>
>
> Mario Peshev
> Training and Consulting Services @ DevriX
> http://www.linkedin.com/in/mpeshev
> http://devrix.com
> http://peshev.net/blog
>
>
>
> On Mon, Mar 19, 2012 at 6:41 PM, Edward Caissie <edward.caissie at gmail.com>wrote:
>
>> I agree with all of Chip's point here ... especially the following
>> statement:
>>
>>
>> On Mon, Mar 19, 2012 at 12:36 PM, Chip Bennett <chip at chipbennett.net>wrote:
>>
>>> Ultimately, though: any discussion such as this one should include
>>> specific Guidelines that you want to see changed or removed. I'm not sure a
>>> wholesale change in philosophy is either plausible or prudent at this point.
>>
>>
>> As much as we are open to discussing the guidelines, it is much easier to
>> deal with specifics and review those than to take a run at the whole gamut
>> of what the guidelines entail.
>>
>>
>> Cais.
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
> _______________________________________________
> 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/20120319/d90d32e9/attachment-0001.htm>