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

Sat Oct 29 19:54:56 UTC 2011

A thought just occurred to me:
Isn't a landing page theme perhaps the wrong approach to begin with?
Oughtn't it be a plugin that directs all non-logged-in traffic to a
static landing page while logged-in users can develop the live site
and then, at the flip of a switch, the landing page status just *poof*
goes away?

(This doesn't have a bearing on the special purpose themes issue but
rather this one particular use case.)

On Sat, Oct 29, 2011 at 3:12 PM, Chip Bennett <chip at chipbennett.net> wrote:
> 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
>>
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>

-- 
-Doug