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

Chip Bennett chip at chipbennett.net
Sat Oct 29 19:12:33 UTC 2011


I'd really like to move past the "blogging"/"non-blogging" consideration as
relevant to the discussion of special-use Themes. I think the impasse
between our opinions is that you appear to place far more
importance/relevance on "blogging" functionality than I do. Again: the
codebase is 99% the same between a given Theme with and without blogging
functionality. It is a trivial difference.

Regarding my my assertion that the primary difference between a "personal
blogging" Theme and a "business" Theme is front-end design rather than
underlying code/functionality: pretty much any "personal blogging" Theme
can, with only changing the CSS, be transformed into a "business" Theme (and
vice versa). What functional/code changes to the Theme do you envision as
contradictory to that assertion?

Chip

On Sat, Oct 29, 2011 at 2:00 PM, Kirk Wight <kwight at kwight.ca> wrote:

> Can this be done by parsing the tags listed in style.css? To me, they would
> serve double-duty: identifying features/elements of themes in the repo, and
> providing a context to Theme Check and the uploader of what to test for. For
> example, the current Theme Check and uploader rules would be the equivalent
> of the "blog" context, to be used against submitted themes with the "blog"
> tag. (I couldn't resist.)
>
> I disagree with Chip that it's design that differentiates types of themes -
> I think it's the developer's intended audience and functionality that
> differentiate, stated by the developer in the theme tags (ratings and
> downloads will decide how successful they are at it). The fact that so many
> of them have similar designs is a result of, not because of,
> their differentiation. To me, using front-end design to determine what
> constitutes certain types of themes is just constraining designers, and will
> start to fail as popular design continues to evolve and change.
>
> Either way, improving the Tag Filer system as Chip suggested above would be
> a great help to users, especially as we start to accept more themes beyond
> the traditional format (could the current Subject column just be turned in
> to a Category column?).
>
>
> On 29 October 2011 13:49, Edward Caissie <edward.caissie at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/ff77f37e/attachment.htm>


More information about the theme-reviewers mailing list