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

Sat Oct 29 17:49:54 UTC 2011

It seems we are closing in on a potentially easy flag method ... much like
setting custom template name in the page template header block, could we be
looking at adding something to `front-page.php` that can be parsed and then
recognize the theme as a niche-Theme? This can be done solely in the upload
check / Theme-Check to start and further implemented into the WordPress
Administration Panels / WordPress.org as it gains momentum.

It's just another idea to add to the list, but follows from Chip's point:
"... because what differentiates a "business" Theme from a "personal" or
"blogging" Theme is not the presence or absence of blog-post functionality
support, but rather the *front-end design* of the Theme."

Cais.

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

> Not sure I agree with this:
>
> I guess my point is that by considering accepting "niche" themes, we are,
> in effect, considering accepting themes that do not support the blog
> use-case (Launch Effect doesn't even have a loop, let alone paginate_links).
>
>
> Maybe, and maybe not. A "landing page" is just ONE potential "niche" use
> case. What about the support-ticket system Theme? It could conceivably still
> have/use blog posts. And that doesn't even get into the myriad ideas I'm
> sure that clever Theme developers will come up with.
>
> But here's the thing:
>
> I think a lot of WordPress users and developers out there now just don't
> see a blog as a requisite part of a WordPress site. I think it would be
> great if a user could go to the repo, look at the tags and say, "hm, I don't
> need a blog, I'll just go with this GenericSimpleBiz theme", and get a theme
> that doesn't have unnecessary code.
>
>
> The amount of code that differentiates static-Page output from blog-post
> output is *trivial*. Off the top of my head, I'd say that 99% of the
> codebase is identical. Not using a blog isn't a separate *use case*, it's
> merely a *setting change*. There is really nothing special or "niche" about
> using a given WordPress Theme to display only static Pages versus using that
> Theme to display blog posts.
>
> While I see great benefit in eradicating the blogging-vs-CMS thinking
> regarding WordPress, I see no benefit to end users in hosting Themes in the
> repository for which the only extraordinary "feature" is that they don't
> support blog post output.
>
> What might be far more beneficial would be to improve the Tag Filter
> system, and allow tags for "Blogging", "Personal", "Business", etc. - or
> whatever, so that developers could indicate the target user audience for
> their Themes - because what differentiates a "business" Theme from a
> "personal" or "blogging" Theme is not the presence or absence of blog-post
> functionality support, but rather the *front-end design* of the Theme.
>
> Chip
>
>
> On Sat, Oct 29, 2011 at 11:55 AM, Kirk Wight <kwight at kwight.ca> wrote:
>
>> I guess my point is that by considering accepting "niche" themes, we are,
>> in effect, considering accepting themes that do not support the blog
>> use-case (Launch Effect doesn't even have a loop, let alone paginate_links).
>> I don't consider this a bad thing at all, it's awesome - they're all
>> WordPress themes. I'd love the theme repo to reflect that, with simple
>> placeholder and specialty themes right beside everything else; it just has
>> to be evident when browsing the repo (hence the Blog tag).
>>
>> I think a lot of WordPress users and developers out there now just don't
>> see a blog as a requisite part of a WordPress site. I think it would be
>> great if a user could go to the repo, look at the tags and say, "hm, I don't
>> need a blog, I'll just go with this GenericSimpleBiz theme", and get a theme
>> that doesn't have unnecessary code.
>>
>> Of course, I'm playing devil's advocate a bit here; I know it's not a
>> tonne more effort or a tonne more code to support blog functionality. I also
>> recognize that a pile more work would be required by Otto, theme reviewers
>> and lots of other busy people to accept and evaluate this much wider scope
>> of themes. I just really like what we're saying about WordPress: you can
>> have any sort of website you want with WordPress, and here are some themes
>> we stand behind that can help you do it.
>>
>> And yes, I totally agree with your frustration in the use of the term
>> "CMS"; whoever's responsible for spreading this "its-a-blog-or-a-CMS"
>> mentality should be sent to bed without dinner.
>>
>> On 29 October 2011 11:19, 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/8841d75b/attachment.htm>