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

Mon Mar 19 19:00:53 UTC 2012

@Cais - a great reply there, kudos. Normally I'd agree with everything. The
only 'but' here is that for a theme to be a super-widespread template and
apply everywhere it should be so general that ends as a blank theme at the
very end. That's why we have so many skeletons submitted with no styling at
all (not to say 'ugly' though sometimes they are indeed) just to meet the
expectations easily. Themes could be more-niche alike and serve better
specific purposes and make more clients happier instead of having 1M+
customers in one of the largest market places out there.

@Chip, 2 notes here and I'll stop flooding and trolling here.

1) I think that we should ignore recommended and info as you suggested. We
should keep reviews straight to what is critical and required to get in.
The rest is for the user personal feedback which has nothing to do with the
submission but just for making a theme even better.

2) is to present some templates for theme documentation, readme file and
reviewer feedbacks. Having some blank files to use and some reviewer
template used by everyone would be great. I have one template built based
on Yulian and Emil's remarks and recommendations but everyone uses his own
style.

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 8:45 PM, Chip Bennett <chip at chipbennett.net> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/3d21a683/attachment-0001.htm>