[theme-reviewers] Submitting a One-Page Placeholder Theme

[Edward Caissie]

I see the "niche-Theme" request being sent to this mailing list to have a
reasonably compelling argument as to why it should be considered, that seems
rather straight forward.

What I am not still understanding is how these "niche-Themes", once one (or
two?) WPTRT Admins have approved it, will pass through the upload checks in
a generic versus specific fashion.

For the most part I see this a a go-forward experimental approach with more
than likely some tinkering required along the way until we can get a handle
on how best to manage this genre of themes. I still absolutely agree the
*end-users* deserve to see a new theme tag indicating these niche-Themes are
meant for special use as well ... perhaps not a show-stopper but it's very
close. I see one of the over-riding goals of the WPTRT as being: to improve
the UX for the end-user which this new tag could be.


Cais.


On Sat, Oct 29, 2011 at 12:32 PM, Chip Bennett <chip at chipbennett.net> wrote:

> One special/extraordinary use case, yes - but also, a use case that is
> demonstrably useful and/or unique/innovative.
>
> Landing-page Themes are obviously useful. A support-ticket-system Theme is
> IMHO both unique and innovative.
>
> I'd love to hear other ideas/examples of such "niche" Themes!
>
> Chip
>
>
> On Sat, Oct 29, 2011 at 11:18 AM, Angelo Bertolli <
> angelo.bertolli at gmail.com> wrote:
>
>> So what you're talking about is allowing some themes to cover only one use
>> case, whereas the themes currently cover all use cases, right?
>>
>>
>> On Sat, Oct 29, 2011 at 11:19 AM, Chip Bennett <chip at chipbennett.net>wrote:
>>
>>> I don't agree. A site that doesn't have a blog doesn't constitute a
>>> "niche"; rather, it is a use-case that is built-in to core. Using WordPress
>>> "as a CMS" (nb: I detest this phrase; WordPress IS a CMS, no matter *how* it
>>> is used - and it is almost always intended to mean "without a blog")
>>> requires nothing more than creating a static Page to serve as the Front
>>> Page, changing the "Front Page Displays" setting to "static page", assigning
>>> the appropriate static page, and then NOT assigning a posts page. Easy
>>> peasy.
>>>
>>>  We don't need special handling for this use-case. Every Theme in the
>>> repository should handle it without problem. By default,
>>> repository-hosted Themes are expected to handle this use case; that's why we
>>> have Guidelines related to display of post metadata and "no comments" type
>>> text on static pages.
>>>
>>> I see no practical reason for a publicly distributed Theme NOT to account
>>> for the blog use-case. If we've not adequately covered the non-blog use case
>>> in the Guidelines, we can always revisit them.
>>>
>>> As for the definition of "niche" Themes: they really do need to be an
>>> extraordinary use. At this point, it's probably a "know it when we see it"
>>> kind of thing. I think the "landing page" use case and the "ticket system"
>>> use case are good, instructive examples.
>>>
>>> Chip
>>>
>>> On Sat, Oct 29, 2011 at 9:42 AM, Kirk Wight <kwight at kwight.ca> wrote:
>>>
>>>> What distinguishes "niche" themes from "regular" themes is often one
>>>> thing: only partial or no implementation of blog functionality. As far as I
>>>> can tell, most of the checks from Theme Check and the uploader rely on the
>>>> theme being usable as a blog.
>>>>
>>>> This summer, we found out from the user survey that a lot of developers
>>>> use WordPress for sites that don't even have a blog component (just a "CMS",
>>>> for lack of a better term) . To me, niche themes are simply themes that, for
>>>> whatever reason, choose not to implement full blog functionality.
>>>>
>>>> We could add a tag filter under Features that is just "blog". If this
>>>> tag exists, the uploader and Theme Check plugins check according to the
>>>> current criteria. If not, a simpler context can be used (presence of
>>>> readme.txt, etc). Obviously this would require rewriting the uploader and
>>>> theme eval plugins to react conditionally, but it would seem simpler and
>>>> more elegant to me than getting in to theme slugs, white-listing specific
>>>> users, and trying to create specific tag filters for each non-standard
>>>> use-case.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20111029/d60eeaf6/attachment.htm>